News for hackers. Stuff that matters.
Re:RFC 9849. TLS Encrypted Client Hello by szmarczak on Wednesday March 04, 2026 @05:37AM (#47245624)
It doesn't prevent fingerprinting, stop spreading misinformation. It only prevents your ISP from knowing what website you're connecting to.
Re:RFC 9849. TLS Encrypted Client Hello by CloakHQ on Wednesday March 04, 2026 @06:25AM (#47245991)
fair point, I should have been more precise. the server (Cloudflare in this case) still decrypts the inner ClientHello and can fingerprint it - jannesan and jeroenhd are right about that.

the part that changes is passive fingerprinting from third parties - network middleboxes, ISPs, DPI systems that have historically been able to read ClientHello parameters in transit and build behavioral profiles. that layer goes away. for bot detection specifically that matters less since detection happens at the server, so your correction stands for that use case.

the Cloudflare paradox I was gesturing at is maybe better framed as: for sites NOT on Cloudflare, ECH makes it harder for Cloudflare (as a network observer) to do pre-connection fingerprinting. but for their own CDN customers, they decrypt it anyway so nothing changes for them. the conflict is more theoretical than practical for their current product.

Re:RFC 9849. TLS Encrypted Client Hello by szmarczak on Wednesday March 04, 2026 @06:54AM (#47246192)
> the part that changes is passive fingerprinting from third parties

That's exactly what I said:

> It only prevents your ISP from knowing what website you're connecting to.

Re:RFC 9849. TLS Encrypted Client Hello by gzread on Wednesday March 04, 2026 @06:53AM (#47246187)
Why would Clownflare ever see traffic to sites not on Clownflare?
Re:RFC 9849. TLS Encrypted Client Hello by szmarczak on Wednesday March 04, 2026 @06:56AM (#47246216)
They do routing. Even if you're connecting to a non Cloudflare server, the traffic may still be routed through their servers.

Why would they want to peek traffic? Most likely for statistics (most frequently visited websites etc).

Re:RFC 9849. TLS Encrypted Client Hello by gzread on Wednesday March 04, 2026 @07:24AM (#47246480)
Can you give an example of a BGP route or traceroute to a site not on Clownflare that was routed through Clownflare?
Re:RFC 9849. TLS Encrypted Client Hello by szmarczak on Wednesday March 04, 2026 @08:33AM (#47247168)
It depends on the origin and the destination. Their Magic Transit service explicitly allow this, and I assume they have agreements with other AS in case something goes wrong on either side (it often does). You'd have to directly ask them to know specifically but I don't think they would answer since that's proprietary information.
Re:RFC 9849. TLS Encrypted Client Hello by Hizonner on Wednesday March 04, 2026 @05:31PM (#47254901)
> the part that changes is passive fingerprinting from third parties - network middleboxes, ISPs, DPI systems

Right. Things that should never have been allowed to exist to begin with. Working as designed.

Re:RFC 9849. TLS Encrypted Client Hello by maxloh on Wednesday March 04, 2026 @06:01AM (#47245827)
Since most ISPs also maintain their own DNS resolver, they could always reverse lookup the IP address AFAIK.
Re:RFC 9849. TLS Encrypted Client Hello by progbits on Wednesday March 04, 2026 @06:20AM (#47245956)
The whole idea behind ECH is one IP hosts tons of sites (eg. CDN) so you have no idea which one it is.

Also reverse lookup has nothing to do with hosting own DNS resolver.

Re:RFC 9849. TLS Encrypted Client Hello by szmarczak on Wednesday March 04, 2026 @06:46AM (#47246130)
What you're describing is a SNI, not ECH. Those two serve very different purposes.

> Also reverse lookup has nothing to do with hosting own DNS resolver.

It has everything to do with that. Had you used two brain cells, you would've known that they can memorize the IP address and the domain name, and if you connect to that IP in a short period of time, most likely you visited that domain name.

Re:RFC 9849. TLS Encrypted Client Hello by gzread on Wednesday March 04, 2026 @06:54AM (#47246193)
SNI is unencrypted, so your ISP can see it. ECH encrypts it.
Re:RFC 9849. TLS Encrypted Client Hello by szmarczak on Wednesday March 04, 2026 @06:59AM (#47246247)
How does this relate to my comment?
Re:RFC 9849. TLS Encrypted Client Hello by szmarczak on Wednesday March 04, 2026 @06:15AM (#47245919)
True. ECH is useless if you're using plain DNS. DNS over TLS or HTTPS is the way to go.
Re:RFC 9849. TLS Encrypted Client Hello by hzwanip on Wednesday March 04, 2026 @05:48AM (#47245712)
What OP wrote seems correct:

> ECH basically kills TLS fingerprinting as a bot detection signal

They are not talking about fingerprinting in general. Please elaborate how else TLS fingerprinting can be done.

Re:RFC 9849. TLS Encrypted Client Hello by szmarczak on Wednesday March 04, 2026 @05:56AM (#47245773)
I am talking about TLS fingerprinting, not JS fingerprinting.

> Please elaborate how else TLS fingerprinting can be done.

By doing everything as it is right now?

Re:RFC 9849. TLS Encrypted Client Hello by hzwanip on Wednesday March 04, 2026 @05:59AM (#47245805)
How would you (an arbitrary web server) fingerprint a TLS connection if the Client Hello is encrypted?
Re:RFC 9849. TLS Encrypted Client Hello by szmarczak on Wednesday March 04, 2026 @06:10AM (#47245893)
By decrypting it? I don't think you know how TLS, or E2E works in general. ISP doesn't perform the fingerprinting, the server does.
Re:RFC 9849. TLS Encrypted Client Hello by hzwanip on Wednesday March 04, 2026 @06:15AM (#47245920)
Of course! My bad, thanks for engaging.
Re:RFC 9849. TLS Encrypted Client Hello by conradludgate on Wednesday March 04, 2026 @06:07AM (#47245873)
The website owner (or cloudflare in this case) has the keys to decrypt the client hello. That's necessary for routing information.
Re:RFC 9849. TLS Encrypted Client Hello by hzwanip on Wednesday March 04, 2026 @06:09AM (#47245884)
You're right, sorry! I got confused myself.