[AndyMcConachie]

I don't think this is possible. I can have different TLS configs for each vhost I set up on a single HTTP instance. And until the SNI is sent the server has no way of knowing which vhost to use.

Also SNI needs to match the hostname specified in the X.509 part of the cert. Certs are issued based on DNS names which need to correspond to SNI.

I'm not sure how much hiding the SNI would get you in terms of privacy. You could always just look at the destination IP address of the packet.

[quesera]

> I'm not sure how much hiding the SNI would get you in terms of privacy. You could always just look at the destination IP address of the packet.

Destination IP will be the same for all sites on the server, SNI tells you exactly which site was asked for. Not meaning to be pedantic, sometimes the distinction isn't clear.

But in order to encrypt the SNI name, you'd first need to verify a certificate tied to a bare IP address. You'd also need to trust DNS completely. RTT would inflate significantly.

The CA system is a mess, but DNS is worse. Tying certs to bare IPs would create a deployment nightmare as well.

SNI is imperfect, but it is a big improvement over the previous status quo, which was single-IP per https host, which obviously did nothing to obscure the site hostname either.

[jimktrains2]

> But in order to encrypt the SNI name, you'd first need to verify a certificate tied to a bare IP address.

Why wouldn't a DH exchange be enough?

[quesera]

You're right, DH might be enough, depending on goals.

The DH exchange would be MITMable, but not passively collectable. TLS is (ideally) neither, so DH wouldn't provide an equal level of privacy.

Still, it would be a beneficial extension of the protocol. At the cost of an additional TCP RT.

[jimktrains2]

Right, however, the MITM attack would also come at the cost of causing the rest of the connection to fail. You could also do fun stuff like sending the sha256-mac of the hostname using the DH key as the MAC key. There are lots of fun ideas!

[mook]

> You could always just look at the destination IP address of the packet.

For CDN services like cloudflare I'd imagine that it would make more of an impact, since in that case an IP address could potentially match many host names. Of course that has its own downsides - most notably the fact that you'd need to trust them with the server's private key.