The SNI extension is a MUST in the TLS 1.3 standard. Of course this is not a law of physics, it's perfectly possible to implement a client which doesn't send this extension but the standard says to do this, so implementations which reject your connection for being non-standard might exist, might even become popular. You can reject connections that lack SNI even today if you want, it's just that the most popular web server software has the "default" behaviour you described, but that's not mandatory or unavoidable.

Anyway, it is unlikely that TLS 1.3 will be popular enough to reject TLS 1.2 connections in the next say, five years unless there's some monumental security problem that makes TLS 1.2 moot.

So if middleware can just snoop the SNI and filter (e.g. Wikipedia) on that, doesn't that negate any of the supposed privacy improvements of TLS 1.3? Other people in this thread seem to think that it provides more protection against MITM and snooping from middleware than did 1.2. How is that supposed to work?

There's a couple of things to keep in mind. First, all major browsers (and many other TLS clients too) have been using SNI for more than a decade now, so it's not so much that TLS 1.3 makes things worse, it just better reflects the implementation reality. Second, even in a hypothetical world without SNI, anyone watching the traffic would still see the IP the client is talking to. For a large percentage of web traffic, that IP address can easily be associated with exactly one domain, and for the rest - shared web hosts, things behind CDNs, etc. - you still have the response size to work with, which you can use to make a fairly good guess as to what the domain is.

Of course it's usually even simpler than that because you can just look at DNS lookups which overwhelmingly don't use transport-level encryption today.

I was told that DNS was the reason for keeping the SNI unencrypted. I.e., encrypting SNI is tricky and doesn't help if DNS reveals what you are doing anyway.

The DNS community is now trying to move to DNS over TLS. Once that is wide spread, there is hope that a future TLS version will encrypt SNI.

Note that if you do DH before sending the SNI then it requires an active attack to figure out the SNI. However that will make life very difficult for server-side proxies that try to route traffic based on SNI.

Encrypting SNI would come at a cost

TLS 1.3 provides 1RTT encryption by having clients speculate that the server is modern. The client opens by saying "OK, I assume you know how to do this key exchange and here are my parameters". If the server actually does _not_ know the flavour of key exchange proposed, it sends a retry message, explaining what it does know instead and we're immediately paying an extra round trip cost.

SNI travels in that first message from the client, but if we are to encrypt it with the DH key we can't send it until the client knows that key, which means we again pay an extra round trip.

You might think hold on, surely we can immediately start our transaction because we have the encryption keys now, so we're not paying an extra round trip. Nope, we mustn't start the transaction until we've seen the server's certificate, so we have to wait an entire extra round trip.

The best option if we want to really encrypt SNI is to have servers able to choose to go early, so you'd connect without SNI, and then after finishing DH the server could choose to either immediately send certificates (so it can't serve different sites this way) or ask for the encrypted SNI first. This would mean it's 1RTT for www.google.com and 2RTT for another-cat-blog.example because the latter is on a cheap bulk host. That's... not great.

A way forward that's resistant to attack but isn't full encryption would be use of hashing, the client specifies only a hash of the hostname, not the plain name, and the server matches this against its known list of possible names. A snooper sees the hash, and can try to guess what it means, but if they have no idea they're out of luck.

We can make the snooper's life hard either in the protocol design itself (e.g. send password-style salted & pessimised hashes, so both the server and snoopers must recalculate for each connection) or in our naming (e.g. name the members only web site zqdm-48gb.example.com, not members.example.com) but this is far less comprehensive than full encryption.

Under the assumption that DNS will move to TLS, a future TLS will have to incur this cost.

It is nice to have 1RTT, but if at the same time you are leaking SNI, people are not going to be happy.

I'm curious how this hashing would work out. My gut feeling is that some security researcher will have a nice presentation along the line of 'nice hash function you have, here's how to break it'.

Given certificate pinning, could a client just encrypt the SNI message using the pinned cert (i.e. the server's X.509 public key)? Anything that can decrypt that message is the thing we wanted to talk to. If it can't, well, a pinned-cert failure is uncommon enough to warrant an extra round-trip, even if the client wants to allow it.

There are a bunch of problems with this idea:

* It is common to pin a certificate for which you don't have the corresponding private key, and so you would not be able to decrypt the message. Examples: Pinning an intermediate from a CA you use, or their root, pinning a "backup" that you have on paper just in case but isn't live

* Pinning is a serious foot gun and a hostage risk (bad guys take over your site for one day, it seems normal but pins _their_ key, then they tell you to pay them $1M for the key or else, your users are locked out until you pay), so it is being deprecated for the public Web.

* Which key? The whole point of SNI is that we tell the remote server which site we're interested in, and then it chooses the keys and certificate accordingly. So with your approach the server must use trial-and-error to eliminate all the keys that don't work first, it barely matters what's actually inside the SNI message, if you can decrypt it then you've already found the right site...

> Anyway, it is unlikely that TLS 1.3 will be popular enough to reject TLS 1.2 connections in the next say

Sure, most servers won't be able to take advantage of this. But if your server is using TLS only to speak to your reverse-proxy over the public Internet (e.g. if you're operating a Cloudflare-protected site where the TLS is terminated at Cloudflare and then a separate TLS connection is made from Cloudflare to your backend), you might be able to take full advantage of this as soon as your reverse-proxy's client logic supports TLSv1.3.