4 ms·

As a user, I will continue to favour websites that do not use shared hosting. They do not require SNI. SNI is an interesting experiment. One could argue it b

As a user, I will continue to favour websites that do not use shared hosting. They do not require SNI. SNI is an interesting experiment. One could argue it benefits users because it has made it less expensive for websites to provide TLS, and therefore there has been more use of TLS, however at the same time it takes users a step back in terms of privacy. Before SNI, SSL/TLS websites never leaked hostnames. Even a user who is using "encrypted DNS" (not the DNScurve kind) or who is not even using DNS at all (she already has the server IP address) ends up leaking hostnames when she accesses websites requiring SNI. That's all of Cloudflare and many other hosting providers/CDNs. The whole exercise makes it trvially easy to track the usage habits of users by sniffing the plaintext TLS setup traffic. Whatever was gained by using SNI to achieve virtual hosting for TLS must be offset by the amount of user privacy sacraficed. Not surprising one of the sponsors of this draft is an enormous user of SNI in its hosting business. ESNI is a noble idea however it is riddled with complexity. As a user concerned about leaking hostnames, nothing beats a good old-fashioned TLS website on a decicated IP addresss. There are still plenty of those around.

terom 6y ago
If each dedicated IP address is associated with a single hostname/certificate, then wouldn't it be relatively straightforward to map connections to a specific IP address back to a known hostname? You can probably just probe the IP on port 443 and look at the certificate subject to characterize that traffic. Might work for very obscure sites, but not anything commonly used.
- pwdisswordfish2 6y ago
  Of course. I have seen this argument before. When we say "relatively straightforward" what is this relative to? SNI did not make possible what was previously impossible. It made something that was always possible much easier and more reliable by creating a new method -- sniffing ClientHello. There is no such thing as "absolute" privacy on the internet, (IMO). There never was and there will never be. HOwever if our threat model is marketers/advertisers, the dichotomy, if we choose to view the issue that way, is "easier/more difficult" (on a mass scale) not "possible/impossible". Is it easier to passively sniff ClientHello from network traffic on a mass scale then to connect to 443 on a massive number of computers (or rely on someone else to do it)? Or is it more difficult? One method generates zero traffic and requires relatively less computing resources. The other method generates an inordinate amount of traffic, enough to trigger complaints from internet provider, and requires more significant resources. Today, we have both methods available. Before SNI, the additional, easier method did not exist. However, to be fair, I think there could be an argument regarding websites now using TLS with SNI because of the cost reduction of shared TLS hosting that previously were only only using TCP. Before they started using TLS, arguably hostnames could be sniffed from HTTP headers. Whether pulling hostnames from HTTP Host headers is easier on a mass scale than sniffing ClientHello packets, and whether anyone would do that for marketing/advertising purposes, is for the reader to decide.

terom 6y ago

If each dedicated IP address is associated with a single hostname/certificate, then wouldn't it be relatively straightforward to map connections to a specific IP address back to a known hostname? You can probably just probe the IP on port 443 and look at the certificate subject to characterize that traffic. Might work for very obscure sites, but not anything commonly used.

pwdisswordfish2 6y ago
Of course. I have seen this argument before. When we say "relatively straightforward" what is this relative to? SNI did not make possible what was previously impossible. It made something that was always possible much easier and more reliable by creating a new method -- sniffing ClientHello. There is no such thing as "absolute" privacy on the internet, (IMO). There never was and there will never be. HOwever if our threat model is marketers/advertisers, the dichotomy, if we choose to view the issue that way, is "easier/more difficult" (on a mass scale) not "possible/impossible". Is it easier to passively sniff ClientHello from network traffic on a mass scale then to connect to 443 on a massive number of computers (or rely on someone else to do it)? Or is it more difficult? One method generates zero traffic and requires relatively less computing resources. The other method generates an inordinate amount of traffic, enough to trigger complaints from internet provider, and requires more significant resources. Today, we have both methods available. Before SNI, the additional, easier method did not exist. However, to be fair, I think there could be an argument regarding websites now using TLS with SNI because of the cost reduction of shared TLS hosting that previously were only only using TCP. Before they started using TLS, arguably hostnames could be sniffed from HTTP headers. Whether pulling hostnames from HTTP Host headers is easier on a mass scale than sniffing ClientHello packets, and whether anyone would do that for marketing/advertising purposes, is for the reader to decide.