Hacker News Reader

Comment by clinta | Hacker News Reader

And even if you use encrypted DNS, the domain is still in the clear via SNI. There's an RFC for encrypting SNI, but that's not here yet.

View on HN

Encrypted SNI seems to be tailor made for this situation. The public portion of the request SNI would just be s3.amazonaws.com but the ESNI extension has the full subdomain name. That (+encrypted dns) solves the privacy issue, while still enabling all the new features and improvements they have planned.

Does encrypted SNI solve the issues that AWS are trying to solve by removing path-style S3 requests? Namely, removing the complexity and single-point-of-failure of having one domain, and making it possible for subdomains to have varying allowed cipher settings? I don't know how encrypted SNI will work, but it surely it must choose the cipher before it sends the domain, so it ought to rule out one of the reasons for the change?

According to https://tools.ietf.org/html/draft-ietf-tls-esni-03 ESNI parameters (e.g. public key) are queried via DNS. In the above case, the browser queries a TXT record for _esni.tiananmen-square-facts.s3.amazonaws.com, in addition to A and/or AAAA records for tiananmen-square-facts.s3.amazonaws.com. It then uses the public and other parameters to encrypt the SNI.

So it simply shifts the problem to DNS. To keep requests confidential from sniffers on your LAN or somewhere along the path, you're expected to use something like DoH.

Aren’t TLS certificates also sent in plaintext?

No longer since TLS 1.3

Reply on news.ycombinator.com