Earlier quoted context omitted.
It doesn't prevent fingerprinting, stop spreading misinformation. It only prevents your ISP from knowing what website you're connecting to.
[flagged]
Why would Clownflare ever see traffic to sites not on Clownflare?
RFC 9849. TLS Encrypted Client Hello
51–60 of 159 posts
Re: RFC 9849. TLS Encrypted Client Hello
#52Earlier quoted context omitted.
It doesn't prevent fingerprinting, stop spreading misinformation. It only prevents your ISP from knowing what website you're connecting to.
[flagged]
> 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
#53Earlier quoted context omitted.
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.
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.
SNI is unencrypted, so your ISP can see it. ECH encrypts it.
Re: RFC 9849. TLS Encrypted Client Hello
#54Will this have an impact on Loadbalancers? Like does one have to do client side load balancing like in gRPC?
If your load balanced doesn't support ECH, don't tell clients to use ECH.
Re: RFC 9849. TLS Encrypted Client Hello
#55Earlier quoted context omitted.
[flagged]
Why would Clownflare ever see traffic to sites not on Clownflare?
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
#56Earlier quoted context omitted.
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.
SNI is unencrypted, so your ISP can see it. ECH encrypts it.
How does this relate to my comment?
Re: RFC 9849. TLS Encrypted Client Hello
#57Earlier quoted context omitted.
Why didn't the Indian government block traffics based on IP instead? That would make it much harder to bypass.
If i'm not mistaken its because IPs are actually much easier to rotate than domains. E.g. all the users will remember `example.com` , underlying it doesn't matter what IP it resolves to. If the IP gets "burned" , then the providers can rotate to a new IP (if their provider allows). Vs. telling your users to use a new domain `example.org` , fake websites etc. Also sensible ISPs usually don't block IPs since for servic…
That's why you have a strictly legal domain that enables a convoluted redirect with plausible deniability (not 302)
It'll still eventually stick, but a lot slower
Re: RFC 9849. TLS Encrypted Client Hello
#58Earlier quoted context omitted.
Thanks for the writeup, Ivan, I am a great fan of your work! Now we need to get Qualys to cap SSL Labs ratings at B for servers that don't support ECH. Also those that don't have HSTS and HSTS Preload while we're at it.
Thanks! Sadly, SSL Labs doesn't appear to be actively maintained. I've noticed increasing gaps in its coverage and inspection quality. I left quite a while ago (2016) and can't influence its grading any more, sadly.
Is there a well-maintained alternative to SSL Labs you can recommend?
Re: RFC 9849. TLS Encrypted Client Hello
#59Earlier quoted context omitted.
Thanks! Sadly, SSL Labs doesn't appear to be actively maintained. I've noticed increasing gaps in its coverage and inspection quality. I left quite a while ago (2016) and can't influence its grading any more, sadly.
Is there a well-maintained alternative to SSL Labs you can recommend?
Yes, there is! After I left SSL Labs, I built Hardenize, which was an attempt to go wider and handle more of network configuration, not just TLS and PKI. It covers a range of standards, from DNS, over email, TLS and PKI, and application security.
Although Hardenize was a commercial product (it was acquired in 2022 by another company, Red Sift), it has a public report that's always been free. For example:
https://www.hardenize.com/report/feistyduck.com
The CSP inspection in Hardenize could use a refresh, but the TLS and PKI aspects are well maintained [at the time of writing].
Re: RFC 9849. TLS Encrypted Client Hello
#60ECH is great from a privacy perspective, but I’m curious how well this will actually work in practice.every time the web encrypts more metadata there’s pushback from middleboxes and network operators.