Hacker News Reader

Comment by tialaramex | Hacker News Reader

Under TLS 1.3 the Server Name Indication extension becomes mandatory, so your client will automatically, in plain text, transmit the full DNS name of whatever server it wants to talk to

[SNI is there to make "virtual hosting" possible for HTTPS, which is why you can get working SSL on a cheap bulk host without paying them extra for a dedicated IP address]

So, a middlebox might choose to drop connections based on the name your client sends (and of course it could also choose to drop them based on the destination IP address, the amount of traffic you've sent recently, or the phase of the moon). But the certificate itself is now always encrypted, so the middlebox can't snoop that without acting as a proxy.

It sounds as though you've (perhaps against your will) accepted the proxy, so in that case all bets are off anyway, a proxy can do whatever it likes, if you don't want that don't trust proxies.

View on HN

> your client will automatically, in plain text, transmit the full DNS name of whatever server it wants to talk to

AIUI, it's slightly better than this, because you only actually need to send the name of some domain that the server can serve, not necessarily the one you actually want to talk to. If the domain is on Cloudfront, App Engine, Heroku, etc, that means you can choose one of a billion innocuous sites to use for SNI, before connecting to the one you actually want.

This is called 'domain fronting':

https://www.bamsoftware.com/papers/fronting/

I can't quite work out the trust algebra of this, though. You don't have any cryptographic guarantee that you're connecting to the right site. But you can be sure that you're connecting to whichever server hosts the site whose name you're taking in vain. But if that server was able to serve your site all along, because it had its private key, did you ever really have any guarantee?

Probably won't help for wikipedia, though, as they're not behind a CDN.

Wikipedia summary of domain fronting: https://en.wikipedia.org/wiki/Domain_fronting

But browsers don't do this, and don't have any channel to look up these DNS mappings.

> Under TLS 1.3 the Server Name Indication extension becomes mandatory

Is the client allowed to not send an SNI? If not, does this mean that HTTPS servers will no longer have a "default" HTTPS virtual host if accepting only TLSv1.3 connections?

If you don't get to know anything about the backend at an IP until you've essentially proven you have a shared secret (the domain name), this could be a bad time for the folks who try to scan IP address space for HTTPS sites (e.g. the DDoSers who want to de-anonymize Cloudflare-protected backends in order to attack them directly.)

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.

> 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.

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...

> SNI is there to make "virtual hosting" possible for HTTPS, which is why you can get working SSL on a cheap bulk host without paying them extra for a dedicated IP address]

At least for those that are stuck on IPv4, which is unfortunately a majority.

IPv6 without SNI won't really fix the censorship issue anyway. If you're not using a shared host with SNI The proxy can just query the host at the IP address you're attempting to access and see what it responds with, since that IP will only be serving one domain.

Well, it is not a proxy but biggest ISP of Turkey.

Reply on news.ycombinator.com