SNI is the "server_name" extension in the ClientHello message, which is not encrypted. So no, looks like there are no changes to this in TLS 1.3.
Theoretically it could be possible to encrypt it (using DHE) before server validation occurs (i.e. before the server's RSA certificate is needed). However, it would rigorously change the protocol and I can imagine it would make some load balancing applications a lot more complicated as well.
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.
> 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.
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!
> 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.
Theoretically it could be possible to encrypt it (using DHE) before server validation occurs (i.e. before the server's RSA certificate is needed). However, it would rigorously change the protocol and I can imagine it would make some load balancing applications a lot more complicated as well.