Hacker News Reader

Comment by remoteorbust | Hacker News Reader

Thanks for the heads up. I've made some proxy software that routes on SNI. If TLS1.3 drops SNI then I feel like that will accelerate ipv6 adoption because we're going to need a shitload more IP addresses.

View on HN

TLS 1.3 still has SNI. SNI still transmits server names in the clear, just like always. This enables e.g. blocking a specific hostname without blocking an entire CDN, particularly now that CDNs are trying to stop domain fronting.

Some people were working on encrypted SNI during TLS 1.3's development, so that TLS could encrypt server names sort of like how it encrypts all later traffic. Encrypted SNI didn't make it into TLS 1.3.

I'm not following the connection between how IPv6 would accelerate in the absence of SNI. Could you elaborate?

Without SNI the only way for a client to talk to this.example rather than that.example over TLS and thus HTTPS is to give this.example and that.example different IP addresses. There aren't enough addresses to plausibly do this in IPv4, but in IPv6 there are plenty (except in some unusual corner cases)

Indeed and I remember the bad old days of burning /24s for IP based virtual hosts in order to provide TLS. our current IPv4 exhaustion was the part I was missing. Cheers.

Sure. If you are a CDN right now you can host multiple customers on one ip. If you are using TLS there are 2 ways to do this:

1. Have a big SAN cert with lots of names.

2. Use SNI to select the correct certificate for that client and route to the correct customer config (and therefore correct origin)

If SNI didn't exist we'd be back to the bad old days of every TLS site requiring a dedicated IP. As ipv4 exhaustion has gotten worse this has gotten more expensive. However if we're using ipv6 then hosting N listeners for N ip addresses, each with their own dedicated cert, is much more scalable.

Reply on news.ycombinator.com