3 ms·

TLSv1.2 traffic contains the hostname of the site you're connecting to, and the list of ciphers. This can be fingerprinted to identify your browser, and the ser

TLSv1.2 traffic contains the hostname of the site you're connecting to, and the list of ciphers. This can be fingerprinted to identify your browser, and the server-side software. [1] TLSv1.3 on the other hand sometimes encrypts the hostname (eSNI) and most of the TLS handshake, so there's much less data to fingerprint. It's not as widely supported, but support is growing... [1] https://engineering.salesforce.com/tls-fingerprinting-with-ja3-and-ja3s-247362855967 https://engineering.salesforce.com/tls-fingerprinting-with-j... //Edited to clarify that eSNI isn't default behaviour of 1.3

Aissen 5y ago
ECH (the new name of eSNI) is not even out of draft status yet, so it's misleading to put it on the same level as TLS 1.3 (although you did say it was not as widely supported, it's an understatement).
elithrar 5y ago
> TLSv1.3 on the other hand encrypts the hostname (eSNI) eSNI is not the default behavior, and has few deployments at scale. TLSv1.3 transmits SNI in the clear. eSNI is being replaced with ECH[1], but in many cases, there is a 1:1 relation between the IP address and the site being served. ESNI and ECH are only one layer of obfuscation - a middleman (such as an ISP) could still snoop your DNS (unless DoH/DoT) and/or correlate the IP addresses you connect to against the hostname(s) presented on that server. Attackers already do that today with nmap - scan publicly addressable ranges on port 443 and see what names are on the certificate presented by the server. [1]: https://blog.cloudflare.com/encrypted-client-hello/ https://blog.cloudflare.com/encrypted-client-hello/
- tialaramex 5y ago
  Right. The actual improvement from TLS 1.2 to TLS 1.3 in this respect is that in TLS 1.2 the certificate was in the clear. Encrypted Client Hello isn't finished. I would say the basic idea is settled, but there are plenty of technical nits and it might be next year before they have a final document. Eventually the idea is that ECH will be GREASEd by always sending ECH data, if the client knows it is supported it will use ECH and if not then it will fill out the ECH data with random nonsense. Since it's encrypted, an adversary can't easily distinguish one from the other and a site which doesn't offer ECH will ignore the nonsense anyway. The idea of probing servers on port 443 works well enough for dozens of popular sites with dedicated servers, but much less well for the long tail. A bulk host won't give you a list of every customer just because you hit port 443 on each server and pled ignorance, you'll get a generic "Under construction" page and no information.
gruez 5y ago
>TLSv1.3 on the other hand encrypts the hostname (eSNI) and most of the TLS handshake That's supported in supported in tls 1.3, but actual deployment/usage is spotty (it's an extension, not mandatory). AFAIK it also requires your DNS to cooperate, since that's how it gets the keys for the initial handshake.

Aissen 5y ago

ECH (the new name of eSNI) is not even out of draft status yet, so it's misleading to put it on the same level as TLS 1.3 (although you did say it was not as widely supported, it's an understatement).

elithrar 5y ago

> TLSv1.3 on the other hand encrypts the hostname (eSNI) eSNI is not the default behavior, and has few deployments at scale. TLSv1.3 transmits SNI in the clear. eSNI is being replaced with ECH[1], but in many cases, there is a 1:1 relation between the IP address and the site being served. ESNI and ECH are only one layer of obfuscation - a middleman (such as an ISP) could still snoop your DNS (unless DoH/DoT) and/or correlate the IP addresses you connect to against the hostname(s) presented on that server. Attackers already do that today with nmap - scan publicly addressable ranges on port 443 and see what names are on the certificate presented by the server. [1]: https://blog.cloudflare.com/encrypted-client-hello/ https://blog.cloudflare.com/encrypted-client-hello/

tialaramex 5y ago
Right. The actual improvement from TLS 1.2 to TLS 1.3 in this respect is that in TLS 1.2 the certificate was in the clear. Encrypted Client Hello isn't finished. I would say the basic idea is settled, but there are plenty of technical nits and it might be next year before they have a final document. Eventually the idea is that ECH will be GREASEd by always sending ECH data, if the client knows it is supported it will use ECH and if not then it will fill out the ECH data with random nonsense. Since it's encrypted, an adversary can't easily distinguish one from the other and a site which doesn't offer ECH will ignore the nonsense anyway. The idea of probing servers on port 443 works well enough for dozens of popular sites with dedicated servers, but much less well for the long tail. A bulk host won't give you a list of every customer just because you hit port 443 on each server and pled ignorance, you'll get a generic "Under construction" page and no information.

gruez 5y ago

>TLSv1.3 on the other hand encrypts the hostname (eSNI) and most of the TLS handshake That's supported in supported in tls 1.3, but actual deployment/usage is spotty (it's an extension, not mandatory). AFAIK it also requires your DNS to cooperate, since that's how it gets the keys for the initial handshake.