3 ms·

>Therefore, since Tor tries to mimick common browsers and servers, it must always send a SNI extension. Right, and since all browsers have no problem with plai

>Therefore, since Tor tries to mimick common browsers and servers, it must always send a SNI extension. Right, and since all browsers have no problem with plaintext http, TOR should be okay with it too. You know, to mimic traffic and stuff. That's the most BS excuse I've ever heard. Sending the domain in the clear on TOR is completely inexcusable. But then, so is having JS enabled by default. Run, do not walk, RUN away from TOR.

tedks 12y ago
Actually, Tor has pluggable transports that mimic HTTP as well, though obviously the traffic is encrypted and then stenographed into HTTPish shape. Take your FUD elsewhere.
cesarb 12y ago
The data Tor exchanges are fixed-size encrypted packets. If Tor used plaintext http, these encrypted packets would be visible, making it trivially distinguishable from a common browser or server. The TLS layer hides that difference; due to the TLS encryption, there's no difference between an HTML document, encrypted Tor packets, or a picture of a pony. Therefore, to mimic browser traffic, Tor has to use TLS. I believe you might be a bit confused with respect to what's in the SNI extension; the domain sent in the clear on Tor connections is not the domain requested by the browser, it is a completely unrelated randomly-generated domain name. Also, even without SNI the same can be found on the opposite direction: the certificate sent in the response also has a randomly-generated domain name.
- slopoque 12y ago
  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.

tedks 12y ago

Actually, Tor has pluggable transports that mimic HTTP as well, though obviously the traffic is encrypted and then stenographed into HTTPish shape. Take your FUD elsewhere.

cesarb 12y ago

The data Tor exchanges are fixed-size encrypted packets. If Tor used plaintext http, these encrypted packets would be visible, making it trivially distinguishable from a common browser or server. The TLS layer hides that difference; due to the TLS encryption, there's no difference between an HTML document, encrypted Tor packets, or a picture of a pony. Therefore, to mimic browser traffic, Tor has to use TLS. I believe you might be a bit confused with respect to what's in the SNI extension; the domain sent in the clear on Tor connections is not the domain requested by the browser, it is a completely unrelated randomly-generated domain name. Also, even without SNI the same can be found on the opposite direction: the certificate sent in the response also has a randomly-generated domain name.

slopoque 12y ago
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.