7 ms·

Maybe somebody more familiar with TLS can set me straight here, but I find it surprising that SNI still exists and there isn't much effort to replace it. To me

Maybe somebody more familiar with TLS can set me straight here, but I find it surprising that SNI still exists and there isn't much effort to replace it. To me it seems like an odd hole to punch into the encryption layer. Back when I was doing security research I wrote a TLS MITM and I distinctly remember thinking "wow thanks SNI this makes it so much easier".

Boulth 8y ago
There are efforts to encrypt it: https://tools.ietf.org/html/draft-ietf-tls-esni-01 https://tools.ietf.org/html/draft-ietf-tls-esni-01
- moderation 8y ago
  And https://blog.cloudflare.com/encrypted-sni/ https://blog.cloudflare.com/encrypted-sni/
  - seccess 8y ago
    Thanks for the links. Sounds like the main reason it hasn't been addressed is DNS, if the client is just going to make a DNS request before their TLS session, the host is effectively leaked anyway. Sadly DNSSEC wouldn't address this as it only provides integrity and not confidentiality.
    - tialaramex 8y ago
      All the D-PRIVE options fix this. A Firefox Nightly can be configured to do D-PRIVE (specifically DNS-over-HTTPS to Cloudflare) and do eSNI, and thus connect to a default configured Cloudflare site without any indication to other parties about which one... Some other cloud providers or CDNs have made interested noises, if those noises weren't just for the public record they might begin doing the exact same thing in short order, especially if the Firefox tests go well.
- infogulch 8y ago
  This is a step in the right direction but it's not perfect. The name of at least one domain that the responding server must host is still leaked. This can be a non issue if the same ip is hosting hundreds of domains (e.g. CloudFlare) or pointless if it's just hosting one site. I just had an idea that might be able to work around this though: 1. Create a new TLD: .ip. All *.ip domains are valid ip addresses (in some encoding, e.g. 740-125-138-139.ip, or anything else) and they always resolve to the ip address specified. 2. Automatically issue certificates for each host for each of the ips that they serve on. (Thank you Lets Encrypt) 3. Every new connection made can just use the ip-domain as the esni originating host, because you can know that every host is serving https://ownip.ip https://ownip.ip. This doesn't solve the fact that server ips are still fairly unique, and so a reverse dns might be enough to find the host, but it doesn't leak any more information than what the IP header already leaks, and it doesn't require leaning even more on increasingly centralized proxies like CloudFlare.
  - dsl 8y ago
    Certificates already support IP addresses. They just need to be public (i.e. not RFC1918 space) and for legacy browser compatibility the IP needs to be in the commonName and subjectAltName.
    - infogulch 8y ago
      Then I guess we just need Lets Encrypt to offer certificates for ips then. [0] [0]: https://community.letsencrypt.org/t/certificate-for-public-ip-without-domain-name/6082/91 https://community.letsencrypt.org/t/certificate-for-public-i...
    - stordoff 8y ago
      > (i.e. not RFC1918 space) Is this just a restriction on current CAs? I have a self-signed certificate on my router (more out of curiosity than any practical benefit), and it comes up fine on https://192.168.1.1/ https://192.168.1.1/
      - reaperhulk 8y ago
SquareWheel 8y ago
Worth keeping in mind that without SNI, we wouldn't have anywhere near the current level of HTTPS adoption either. It wasn't that long ago I had to sell clients on a separate IP address just to set up HTTPS. Let's Encrypt using SNI allowed me to secure everyone for free.

Boulth 8y ago

There are efforts to encrypt it: https://tools.ietf.org/html/draft-ietf-tls-esni-01 https://tools.ietf.org/html/draft-ietf-tls-esni-01

moderation 8y ago
And https://blog.cloudflare.com/encrypted-sni/ https://blog.cloudflare.com/encrypted-sni/
- seccess 8y ago
  Thanks for the links. Sounds like the main reason it hasn't been addressed is DNS, if the client is just going to make a DNS request before their TLS session, the host is effectively leaked anyway. Sadly DNSSEC wouldn't address this as it only provides integrity and not confidentiality.
  - tialaramex 8y ago
    All the D-PRIVE options fix this. A Firefox Nightly can be configured to do D-PRIVE (specifically DNS-over-HTTPS to Cloudflare) and do eSNI, and thus connect to a default configured Cloudflare site without any indication to other parties about which one... Some other cloud providers or CDNs have made interested noises, if those noises weren't just for the public record they might begin doing the exact same thing in short order, especially if the Firefox tests go well.
infogulch 8y ago
This is a step in the right direction but it's not perfect. The name of at least one domain that the responding server must host is still leaked. This can be a non issue if the same ip is hosting hundreds of domains (e.g. CloudFlare) or pointless if it's just hosting one site. I just had an idea that might be able to work around this though: 1. Create a new TLD: .ip. All *.ip domains are valid ip addresses (in some encoding, e.g. 740-125-138-139.ip, or anything else) and they always resolve to the ip address specified. 2. Automatically issue certificates for each host for each of the ips that they serve on. (Thank you Lets Encrypt) 3. Every new connection made can just use the ip-domain as the esni originating host, because you can know that every host is serving https://ownip.ip https://ownip.ip. This doesn't solve the fact that server ips are still fairly unique, and so a reverse dns might be enough to find the host, but it doesn't leak any more information than what the IP header already leaks, and it doesn't require leaning even more on increasingly centralized proxies like CloudFlare.
- dsl 8y ago
  Certificates already support IP addresses. They just need to be public (i.e. not RFC1918 space) and for legacy browser compatibility the IP needs to be in the commonName and subjectAltName.
  - infogulch 8y ago
    Then I guess we just need Lets Encrypt to offer certificates for ips then. [0] [0]: https://community.letsencrypt.org/t/certificate-for-public-ip-without-domain-name/6082/91 https://community.letsencrypt.org/t/certificate-for-public-i...
  - stordoff 8y ago
    > (i.e. not RFC1918 space) Is this just a restriction on current CAs? I have a self-signed certificate on my router (more out of curiosity than any practical benefit), and it comes up fine on https://192.168.1.1/ https://192.168.1.1/
    - reaperhulk 8y ago

SquareWheel 8y ago

Worth keeping in mind that without SNI, we wouldn't have anywhere near the current level of HTTPS adoption either. It wasn't that long ago I had to sell clients on a separate IP address just to set up HTTPS. Let's Encrypt using SNI allowed me to secure everyone for free.