Hacker News Reader

This is sorta it. SNI is the only unecrypted part that leaks the server hostname. CN/SAN blocking usually has a middlebox that decrypts the connections so there is nothing to be done here.

If somebody can MitM your encrypted connection to both server and DNS, encrypted SNI stops working to my understanding.

View on HN

Encrypted SNI is about protecting you from people who aren't in your list of trusted CAs.

If someone is in your trusted CA list, why do you want protection from them? If you want protection from them, remove them from your list of trusted CAs.

IIRC after ServerHello the cert was given to client in clear text.

This changed in TLS 1.3. The server cert is now encrypted.

That's cool. Is it possible to force google.com use TLS1.3?

If you insist upon talking TLS 1.3 draft 23, which is the last substantive change before the draft went to the RFC queue, google.com is perfectly happy to talk TLS 1.3 draft 23.

TLS 1.3 has downgrade detection, so if a middlebox tries to downgrade you (e.g. to TLS 1.2) without proxying the entire connection the TLS 1.3 implementation in your client will spot that and reject the connection.

Proxying is possible (including with a downgrade) if you trust the proxy. So, don't.

If you have a recent-ish version of Chrome or Firefox you are already using all this.

No more.

Reply on news.ycombinator.com