2 ms·

> the current SNI implementation (sending hostname in plain text) is a problem 1. Even if you don't do SNI, the hostname is on the certificate that the server

> the current SNI implementation (sending hostname in plain text) is a problem 1. Even if you don't do SNI, the hostname is on the certificate that the server sends. 2. For most users, the domain name already leaks in the DNS request, does it not? That is, SNI provides no less security. 3. I have no idea what the status of WPAD is these days, but if you can convince a client to use a WPAD file, IIRC, you can leak all the domains they connect to, include HTTP(S) sites. 4. For any IP address that doesn't require SNI, even if the certificate didn't give away the site: the IP address is sent in the clear at the IP layer; it should be pretty easy for an adversary to build up a mapping from IP->DNS for the vast majority of popular domain names. Alternatively, the attacker could just form a connection to that IP and see what site responds. While it's certainly a privacy leak, it doesn't appear to me that the solution is as simple as turning off SNI.

jlgaddis 9y ago
> 2. For most users, the domain name already leaks in the DNS request, does it not? That is, SNI provides no less security. It does but, in many cases, that DNS request/response is not traversing the Internet. At $work (ISP), ~95% of our customer's DNS requests (and the associated responses) originate and terminate within our network [0]. They would not be visible to a passive attacker listening to, say, our upstream network links. > 4. For any IP address that doesn't require SNI, even if the certificate didn't give away the site: the IP address is sent in the clear at the IP layer; it should be pretty easy for an adversary to build up a mapping from IP->DNS for the vast majority of popular domain names. This is mitigated by the fact that most (public) web servers host more than one web site. While you may have hundreds of A RRs pointing towards a single IP address, there's usually only a single PTR RR for a given IP address (and the PTR often resolves to something like "www14.example.com", giving away no additional information about the sites it hosts). Just by listening passively, you could obviously determine that a user visited a web site hosted on 198.51.100.42. If there are 100 web sites hosted on that IP address, however, you know that the user visited one of them but not necessarily which one. > Alternatively, the attacker could just form a connection to that IP and see what site responds. I'm not sure if it still is but it used to be common practice (on servers hosting multiple sites) to configure a "default virtual host" that simply served up a blank page. This site would only be served up when connecting directly to the IP address (i.e., with a missing Host: header in the HTTP request) and would provide no useful information. In my experience, though, a web server hosting a single site is often configured to respond with that site whether the correct Host: header is sent or not. [0]: This is for customers who use our caching, recursive DNS servers. It obviously does not apply to those who use, e.g., Google's public DNS servers, or other DNS servers outside of our network.
blattimwind 9y ago
> 1. Even if you don't do SNI, the hostname is on the certificate that the server sends. Not necessarily, think about things like *.tumblr.com or *.blogspot.tld And while for example Cloudflare's free TLS certificates are not wildcard certificates, they bundle dozens of unrelated sites in a single certificate. The DNS remark still applies, since wildcards themselves can't be cached by a caching DNS server, only individual instances of a wildcard can be cached (as usual). However, with a caching DNS server there will likely be many fewer DNS requests that can be observed compared to HTTP requests.
- jgrahamc 9y ago
  > And while for example Cloudflare's free TLS certificates are not wildcard certificates That's incorrect. They are all wildcard.
wepple 9y ago
> 2. For most users, the domain name already leaks in the DNS request, does it not? That is, SNI provides no less security. This is true, although you can use something like dns-crypt to give you some degree of shielding. There are two additional benefits to it also: - your ISP can’t hijack non-existent domains - you can block IDNs like so: https://flawed.net.nz/2017/07/22/how-and-why-you-should-disable-internationalized-domains/ https://flawed.net.nz/2017/07/22/how-and-why-you-should-disa...
aplorbust 9y ago
"1. Even if you don't do SNI the hostname is on the certificate that the server sends." What if the certificate contains an IP address, instead of hostname(s)? This can alleviate reliance on (third-party controlled, e.g., ICANN) DNS. The blog hints at this reliance (i.e. unencrypted DNS) as an inherent weakness of HTTPS.

jlgaddis 9y ago

> 2. For most users, the domain name already leaks in the DNS request, does it not? That is, SNI provides no less security. It does but, in many cases, that DNS request/response is not traversing the Internet. At $work (ISP), ~95% of our customer's DNS requests (and the associated responses) originate and terminate within our network [0]. They would not be visible to a passive attacker listening to, say, our upstream network links. > 4. For any IP address that doesn't require SNI, even if the certificate didn't give away the site: the IP address is sent in the clear at the IP layer; it should be pretty easy for an adversary to build up a mapping from IP->DNS for the vast majority of popular domain names. This is mitigated by the fact that most (public) web servers host more than one web site. While you may have hundreds of A RRs pointing towards a single IP address, there's usually only a single PTR RR for a given IP address (and the PTR often resolves to something like "www14.example.com", giving away no additional information about the sites it hosts). Just by listening passively, you could obviously determine that a user visited a web site hosted on 198.51.100.42. If there are 100 web sites hosted on that IP address, however, you know that the user visited one of them but not necessarily which one. > Alternatively, the attacker could just form a connection to that IP and see what site responds. I'm not sure if it still is but it used to be common practice (on servers hosting multiple sites) to configure a "default virtual host" that simply served up a blank page. This site would only be served up when connecting directly to the IP address (i.e., with a missing Host: header in the HTTP request) and would provide no useful information. In my experience, though, a web server hosting a single site is often configured to respond with that site whether the correct Host: header is sent or not. [0]: This is for customers who use our caching, recursive DNS servers. It obviously does not apply to those who use, e.g., Google's public DNS servers, or other DNS servers outside of our network.

blattimwind 9y ago

> 1. Even if you don't do SNI, the hostname is on the certificate that the server sends. Not necessarily, think about things like *.tumblr.com or *.blogspot.tld And while for example Cloudflare's free TLS certificates are not wildcard certificates, they bundle dozens of unrelated sites in a single certificate. The DNS remark still applies, since wildcards themselves can't be cached by a caching DNS server, only individual instances of a wildcard can be cached (as usual). However, with a caching DNS server there will likely be many fewer DNS requests that can be observed compared to HTTP requests.

jgrahamc 9y ago
> And while for example Cloudflare's free TLS certificates are not wildcard certificates That's incorrect. They are all wildcard.

wepple 9y ago

> 2. For most users, the domain name already leaks in the DNS request, does it not? That is, SNI provides no less security. This is true, although you can use something like dns-crypt to give you some degree of shielding. There are two additional benefits to it also: - your ISP can’t hijack non-existent domains - you can block IDNs like so: https://flawed.net.nz/2017/07/22/how-and-why-you-should-disable-internationalized-domains/ https://flawed.net.nz/2017/07/22/how-and-why-you-should-disa...

aplorbust 9y ago

"1. Even if you don't do SNI the hostname is on the certificate that the server sends." What if the certificate contains an IP address, instead of hostname(s)? This can alleviate reliance on (third-party controlled, e.g., ICANN) DNS. The blog hints at this reliance (i.e. unencrypted DNS) as an inherent weakness of HTTPS.