Hacker News Reader

Comment by ctz | Hacker News Reader

This article is unfortunately inaccurate. TLS1.3 does not include encrypted SNI. Encrypted SNI is still being worked on by the TLS working group, and isn't in a deployable state.

View on HN

I believe this article is talking about domain fronting, not the use of encrypted SNI. With domain fronting, you connect to one service, say, amazon.com and put amazon.com in the SNI field. However, once you have a secure connection, you then tell Amazon that you really want to talk to some other website and Amazon routes the connection appropriately. To an outside observer, however, it just looks like you are talking to amazon.com and the only thing that can be done to stop this would be to block all the servers that handle that site.

All the big sites have recently prevented domain fronting.

They are too scared of their main website being blocked at ISP's just because your small site uses their servers as a domain front.

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.

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