5 ms·

> Another feature we omit is the Server Name Indication (SNI) extension, which allows a single server to run TLS handshakes on behalf of multiple domains, using

> Another feature we omit is the Server Name Indication (SNI) extension, which allows a single server to run TLS handshakes on behalf of multiple domains, using multiple public keys. I don't understand how you can seriously use TLS and privacy in the same headline whilst actively ignoring the mess that is SNI...

nfoz 7y ago
Could you elaborate? What's the problem with SNI? (I haven't dived deep into these protocols)
- mschuster91 7y ago
  SNI exposes the target domain to everyone with sniffing capabilities - including everyone on your private/corp network as well as all involved ISPs.
  - gruez 7y ago
    That's an non issue because the target domain is in certificate that the server sends back. This happens with or without SNI.
    - toast0 7y ago
      In TLS 1.3, the certificate is now sent encrypted with an ephemeral key. A given IP can serve differwnt certificates depending on SNI, so if SNI can become unsniffable, determining the certificate based on observing traffic to the server as well as generating traffic would be much harder for shared IPs anyway.
dagenix 7y ago
If you connect to a website behind a CDN hosting many websites, a passive observer can tell that you connected to the CDN, but has no idea which website you requested (let's pretend that they can't use a length fingerprinting attack). However, unless the CDN supports domain fronting, which most don't, you have to use SNI to tell the CDN which website you want so you can get the right cert. As SNI is unencrypted, a passive observer now knows what website you are talking to. Privacy defeated. If you connect to a website not behind a CDN, you probably don't have to use SNI, but, the website is revealed by doing a simple reverse DNS query. Privacy defeated. Unencrypted SNI doesn't hurt privacy when compared to the status quo. Encrypted SNI will boost privacy. But until then, TLS is basically the best you can do for privacy, outside of using some more exotic service.
- 3xblah 7y ago
  "If you connect to a website not behind a CDN, you probably don't have to use SNI, but, the website is revealed by doing a simple reverse DNS query." As an example, I tried a reverse DNS query for the IP address of matrixssl.org. All I got was a subdomain at gandi.net. Reverse DNS was originally intended for troubleshooting. It is not required for websites (cf. email) and not everyone bothers to set it up. That is one group of websites where we have to do more work to get the names that are using the remote IP address and figure out which one the user asked for. In fact, DNS is not required for a functional website. IP address of course works fine. That is another group of websites where we have to do additional work to figure out what is at the remote IP address. We do not know what the user sent in her HTTP headers. By comparison, SNI makes the process of invading user privacy easy and reliable, less work. The user is required to send a name, and to send that name in the clear.
  - gruez 7y ago
    >As an example, I tried a reverse DNS query for the IP address of matrixssl.org. All I got was a subdomain at gandi.net. While the gp is wrong in saying that it's as simple as a reverse DNS lookup, his general idea is correct. It's trivial to crawl the internet to find all the ip -> domain mappings for all public domains. It's even easier if the attacker is an ISP because they can log DNS queries/responses.
    - 3xblah 7y ago
      If the parent comment is suggesting it is no easier with SNI, then I disagree. Not all domains are "public" and not all users send their DNS queries to ISPs or third party DNS providers. There are alternative sources for IP to domain mappings for TLS-enabled websites besides reverse DNS, crawling the entire internet is not necessary, but sniffing SNI is easier and more reliable than relying on DNS.
- cortesoft 7y ago
  Not for all CDNs. Some provide dedicated VIPs which don't require SNI. Of course, an adversary can then figure out who you are connecting to based on the IP.

nfoz 7y ago

Could you elaborate? What's the problem with SNI? (I haven't dived deep into these protocols)

mschuster91 7y ago
SNI exposes the target domain to everyone with sniffing capabilities - including everyone on your private/corp network as well as all involved ISPs.
- gruez 7y ago
  That's an non issue because the target domain is in certificate that the server sends back. This happens with or without SNI.
  - toast0 7y ago
    In TLS 1.3, the certificate is now sent encrypted with an ephemeral key. A given IP can serve differwnt certificates depending on SNI, so if SNI can become unsniffable, determining the certificate based on observing traffic to the server as well as generating traffic would be much harder for shared IPs anyway.

dagenix 7y ago

If you connect to a website behind a CDN hosting many websites, a passive observer can tell that you connected to the CDN, but has no idea which website you requested (let's pretend that they can't use a length fingerprinting attack). However, unless the CDN supports domain fronting, which most don't, you have to use SNI to tell the CDN which website you want so you can get the right cert. As SNI is unencrypted, a passive observer now knows what website you are talking to. Privacy defeated. If you connect to a website not behind a CDN, you probably don't have to use SNI, but, the website is revealed by doing a simple reverse DNS query. Privacy defeated. Unencrypted SNI doesn't hurt privacy when compared to the status quo. Encrypted SNI will boost privacy. But until then, TLS is basically the best you can do for privacy, outside of using some more exotic service.

3xblah 7y ago
"If you connect to a website not behind a CDN, you probably don't have to use SNI, but, the website is revealed by doing a simple reverse DNS query." As an example, I tried a reverse DNS query for the IP address of matrixssl.org. All I got was a subdomain at gandi.net. Reverse DNS was originally intended for troubleshooting. It is not required for websites (cf. email) and not everyone bothers to set it up. That is one group of websites where we have to do more work to get the names that are using the remote IP address and figure out which one the user asked for. In fact, DNS is not required for a functional website. IP address of course works fine. That is another group of websites where we have to do additional work to figure out what is at the remote IP address. We do not know what the user sent in her HTTP headers. By comparison, SNI makes the process of invading user privacy easy and reliable, less work. The user is required to send a name, and to send that name in the clear.
- gruez 7y ago
  >As an example, I tried a reverse DNS query for the IP address of matrixssl.org. All I got was a subdomain at gandi.net. While the gp is wrong in saying that it's as simple as a reverse DNS lookup, his general idea is correct. It's trivial to crawl the internet to find all the ip -> domain mappings for all public domains. It's even easier if the attacker is an ISP because they can log DNS queries/responses.
  - 3xblah 7y ago
    If the parent comment is suggesting it is no easier with SNI, then I disagree. Not all domains are "public" and not all users send their DNS queries to ISPs or third party DNS providers. There are alternative sources for IP to domain mappings for TLS-enabled websites besides reverse DNS, crawling the entire internet is not necessary, but sniffing SNI is easier and more reliable than relying on DNS.
cortesoft 7y ago
Not for all CDNs. Some provide dedicated VIPs which don't require SNI. Of course, an adversary can then figure out who you are connecting to based on the IP.