Re:Against privacy defeatism: why browsers can still stop fi...
by tialaramex on Friday June 29, 2018 @10:26PM
(#17429180)
In TLS 1.2 (what a good browser and site uses today) the Server Name Indication sent from your client is plaintext, as is the certificate sent back by the server and the choices made by both sides during key agreement.
In TLS 1.3 (not yet officially published as a standard but basically finished and already drafts are used by Firefox, Chrome, and Cloudflare) only SNI remains plaintext.
So yes, the FQDN you're connecting to will still be revealed, but an adversary can't trust it, unlike the certificate itself, you could be lying if the remote server lets you.
If you scroll back a few days HN discussed the Internet Draft about SNI encryption (it's a problem statement rather than a proposed solution) so they want it, it's just not clear how it could be done (there are lots of bad / ineffective options)
In TLS 1.3 (not yet officially published as a standard but basically finished and already drafts are used by Firefox, Chrome, and Cloudflare) only SNI remains plaintext.
So yes, the FQDN you're connecting to will still be revealed, but an adversary can't trust it, unlike the certificate itself, you could be lying if the remote server lets you.
If you scroll back a few days HN discussed the Internet Draft about SNI encryption (it's a problem statement rather than a proposed solution) so they want it, it's just not clear how it could be done (there are lots of bad / ineffective options)