4 ms·
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.
by clinta 7y ago
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.
- chaitanya 7y agoAren’t TLS certificates also sent in plaintext?
- sorz 7y agoNo longer since TLS 1.3
- infogulch 7y agoEncrypted 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.
- kalleboo 7y agoDoes 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?
- wahern 7y agoAccording to https://tools.ietf.org/html/draft-ietf-tls-esni-03 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.