3 ms·

I wonder if that means AWS, Google, etc oppose measures like encrypted SNI, since it's more likely to get their entire IP range banned by authoritarian governme

I wonder if that means AWS, Google, etc oppose measures like encrypted SNI, since it's more likely to get their entire IP range banned by authoritarian governments.

toast0 9y ago
They are more likely to oppose encrypted SNI on the grounds it's not really possible. How do you encrypt SNI for cold start? For a future connection, I could see how, but at that point you may as well simply do a resumption.
- tialaramex 9y ago
  https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/ https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encrypti... ... is the current state of work on this problem. It's true that encryption (within the desirable parameters discussed in that ID) costs us a round trip, but it might be worth it for most of us most of the time. Keep in mind the TLS you're using today for most sites has 2RTT setup, and we put up with that (if you have a modern browser and go to some major sites you end up using TLS 1.3 draft 23 and thus 1RTT)
  - toast0 9y ago
    Modern browsers (send ALPN) to sites with decent TLS 1.2 stacks (respond to ALPN, even if it's just to say http/1.1) get a 1RTT handshake on TLS 1.2 with TLS false start. TLS 1.3 is nice, but it's not required to get 1RTT. The doc you sent is titled SNI encryption, but is really about tunneling a client hello through a proxy, and provides for the proxy to not send its own server hello, but only send the origin server's server hello. That's interesting, and should be useful for domain fronting and as a general purpose TLS proxy with fewer layers, but it's not really encrypted SNI.
    - tialaramex 9y ago
      In TLS False Start the client sends encrypted data to an unknown remote party. It hopes they're the intended recipient, but it won't actually know until it gets a reassuring Finished message which is too late. Now, if it isn't really the intended recipient the remote party doesn't have all the keys it should have. So cross fingers they can't decrypt the data they've been sent. But this is... less than ideal. It's a high price to pay for performance. In TLS 1.3 that 1RTT completes the handshake so as the client we know who we're taking to. That SNI draft is the result of interested parties coming up with a list of desirable properties for SNI encryption. If you have a better idea that satisfies those properties you absolutely should propose it.
      - toast0 9y ago
        I don't have a better idea, I don't think it's possible. When a server has multiple identities to choose from, and the client has not previously communicated with (and has no no out of band information), as far as I can tell, either the SNI has to be in plain text, or it could be encrypted with an untrusted DHE key (which only eliminates passive detection). Way upthread, bscphil wondered if [big companies] will oppose encrypted SNI to avoid having their IP ranges banned, but their business reasons don't really flow into a decision not to do impossible things.

I wonder if that means AWS, Google, etc oppose measures like encrypted SNI, since it's more likely to get their entire IP range banned by authoritarian governments.

toast0 9y ago

They are more likely to oppose encrypted SNI on the grounds it's not really possible. How do you encrypt SNI for cold start? For a future connection, I could see how, but at that point you may as well simply do a resumption.

tialaramex 9y ago
https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/ https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encrypti... ... is the current state of work on this problem. It's true that encryption (within the desirable parameters discussed in that ID) costs us a round trip, but it might be worth it for most of us most of the time. Keep in mind the TLS you're using today for most sites has 2RTT setup, and we put up with that (if you have a modern browser and go to some major sites you end up using TLS 1.3 draft 23 and thus 1RTT)
- toast0 9y ago
  Modern browsers (send ALPN) to sites with decent TLS 1.2 stacks (respond to ALPN, even if it's just to say http/1.1) get a 1RTT handshake on TLS 1.2 with TLS false start. TLS 1.3 is nice, but it's not required to get 1RTT. The doc you sent is titled SNI encryption, but is really about tunneling a client hello through a proxy, and provides for the proxy to not send its own server hello, but only send the origin server's server hello. That's interesting, and should be useful for domain fronting and as a general purpose TLS proxy with fewer layers, but it's not really encrypted SNI.
  - tialaramex 9y ago
    In TLS False Start the client sends encrypted data to an unknown remote party. It hopes they're the intended recipient, but it won't actually know until it gets a reassuring Finished message which is too late. Now, if it isn't really the intended recipient the remote party doesn't have all the keys it should have. So cross fingers they can't decrypt the data they've been sent. But this is... less than ideal. It's a high price to pay for performance. In TLS 1.3 that 1RTT completes the handshake so as the client we know who we're taking to. That SNI draft is the result of interested parties coming up with a list of desirable properties for SNI encryption. If you have a better idea that satisfies those properties you absolutely should propose it.
    - toast0 9y ago
      I don't have a better idea, I don't think it's possible. When a server has multiple identities to choose from, and the client has not previously communicated with (and has no no out of band information), as far as I can tell, either the SNI has to be in plain text, or it could be encrypted with an untrusted DHE key (which only eliminates passive detection). Way upthread, bscphil wondered if [big companies] will oppose encrypted SNI to avoid having their IP ranges banned, but their business reasons don't really flow into a decision not to do impossible things.