3 ms·

My understanding of an SSL handshake goes a bit like this... Everything after the https:// https:// is encrypted. Client does a DNS lookup on the host, but the

My understanding of an SSL handshake goes a bit like this... Everything after the https:// https:// is encrypted. Client does a DNS lookup on the host, but the host name in the request is encrypted. The path is encrypted. The get parameters are encrypted. Everything is encrypted to the server in the request. Everything coming back from the server is encrypted as well. Team SNI comes along and says, "But we don't really care about security! We want to host multiple domains on the same IP address! How will the server know where to direct the SSL request without the domains?" And so, in the name of reusing an IP address, security is now compromised for the domain. It is sent outside the SSL request, in the clear. Is that about right? SNI on TOR? Nice one.

cesarb 12y ago
It's not about "where to direct the SSL request". It's about selecting the correct server certificate. The handshake goes something like this: the client opens the connection and sends several parameters (in the clear). The server replies with its parameters (in the clear) and its certificate (in the clear, and it includes the domain name). Both sides exchange the key to be used (encrypted), switch to encrypted mode, and verify the handshake. Notice that, even without SNI, the hostname is already sent by the server, in the clear, within the certificate. That poses a chicken-and-egg dilemma: the hostname is sent to the server after the handshake is finished, but the server has to present the correct certificate before the handshake is finished. The solution was to send the hostname (and only the hostname) at the start of the handshake. It's no big deal because the certificate hostname is already visible in the next handshake step. For Tor, it's no big issue: it just manufactures a random hostname and presents it. Tor would have to do it (in the certificate) even without SNI. When using Tor, this does not compromise the domains requested by the browser, since they are sent directly to the exits within the triple-encrypted tunnel; only the chosen exits can see them.

cesarb 12y ago

It's not about "where to direct the SSL request". It's about selecting the correct server certificate. The handshake goes something like this: the client opens the connection and sends several parameters (in the clear). The server replies with its parameters (in the clear) and its certificate (in the clear, and it includes the domain name). Both sides exchange the key to be used (encrypted), switch to encrypted mode, and verify the handshake. Notice that, even without SNI, the hostname is already sent by the server, in the clear, within the certificate. That poses a chicken-and-egg dilemma: the hostname is sent to the server after the handshake is finished, but the server has to present the correct certificate before the handshake is finished. The solution was to send the hostname (and only the hostname) at the start of the handshake. It's no big deal because the certificate hostname is already visible in the next handshake step. For Tor, it's no big issue: it just manufactures a random hostname and presents it. Tor would have to do it (in the certificate) even without SNI. When using Tor, this does not compromise the domains requested by the browser, since they are sent directly to the exits within the triple-encrypted tunnel; only the chosen exits can see them.