- cross-posted to:
- [email protected]
- cross-posted to:
- [email protected]
You must log in or register to comment.
Interesting… I need to revisit the handshake and learn how this fits in. Some will probably be disappointed with “Mozilla is actively working with Cloudflare” but bringing the issue into focus seems good.
What does this buy you privacy-wise? In other words what risk is unencrypted hello? I’m not clear on
As just one example: during session resumption, the Pre-Shared Key extension could, legally, contain a cleartext copy of exactly the same server name that is encrypted by ESNI. The ESNI approach would require an encrypted variant of every extension with potential privacy implications, and even that exposes the set of extensions advertised.
What does this buy you privacy-wise? In other words what risk is unencrypted hello? I’m not clear on
When connecting to a https server that serves multiple domains, the server needs to know what certificate to send you. SNI (Server Name Indication) that tells the server which certificate you are expecting in the first TLS packet sent. This is not encrypted (since it happens in the Client Hello), which means that it can be used for tracking or censorship. There are workarounds like Domain Fronting but it doesn’t conform to the Specs and is not usable on the web.
ESNI (which will become ECH as explained here) will encrypt the Client Hello, to ensure that the SNI can’t be read. The encryption public key will be stored in DNS, so you also need DNS over HTTPS (or DNS over TLS) to ensure that the domain you are connecting is private. This is important for cloudflare since their entire service is pretty much a reverse proxy for tons of domains, which means that ECH will greatly improve the privacy of services behind this kinds of reverse proxies.
thanks, much better. also good news on cloudflare.
