Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RFC 9849. TLS Encrypted Client Hello

rfc-editor.org

Post reply on HN
Print view View original

31–40 of 159 posts

Re: RFC 9849. TLS Encrypted Client Hello

#31

Post by tialaramex »

jeroenhd wrote: post #17

Something that puzzles me about ECH: > In verifying the client-facing server certificate, the client MUST interpret the public name as a DNS-based reference identity [RFC9525]. Clients that incorporate DNS names and IP addresses into the same syntax (e.g. Section 7.4 of [RFC3986] and [WHATWG-IPV4]) MUST reject names that would be interpreted as IPv4 addresses. Aside from apparently not considering the existence of IP…

IPv6 addresses aren't confusable with a DNS name in these syntaxes AFAIU so it's not that they didn't consider IPv6 but that it's not relevant to the issue.

Yes, "Don't stand out" technologies like ECH aren't useful if you inherently stand out anyway. They're intended to make broad surveillance and similar undirected attacks less effective, they aren't magic invisibility cloaks and won't protect you if you're a singular target.

Re: RFC 9849. TLS Encrypted Client Hello

#32

Post by szmarczak »

jeroenhd wrote: post #24
philipallstar wrote: post #19

Earlier quoted context omitted.

I think it's saying that you can't make the name look like an IP address; i.e. if the syntax were www.google.com[142.250.117.139] (I'm making this syntax up) you couldn't put 142.250.117.139[142.250.117.139].

The syntax being referred to includes some obscure, outdated addressing formats (IPv4 addresses represented as two or three number groups in dotted notation rather than the normal 4). However, "DNS-based reference identity [RFC9525]" seems to explicitly disallow IP-based certificates by requiring a DNS name. I can only interpret the sentence I quoted as written to say "make sure you never ever accidentally validate a…

I don't think your interpretation is right. If it were,

> Clients that incorporate DNS names and IP addresses into the same syntax

They wouldn't mention the IP addresses at all. Also, notice the word "and".

Re: RFC 9849. TLS Encrypted Client Hello

#33

Post by szmarczak »

hzwanip wrote: post #30
szmarczak wrote: post #28

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.

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.

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

#34

Post by arch-choot »

ignoramous wrote: post #18
arch-choot wrote: post #12

Glad that it's published, I'd been following it since ESNI draft days. Was pretty useful back when I was in India since Jio randomly blocked websites, and cloudflare adopted the ESNI draft on its servers as did Firefox client side which made their SNI based blocking easy to bypass. There was a period where I think both disabled ESNI support as work was made on ECH, which now is pretty far along. I was even able to se…

> Was pretty useful back when I was in India since Jio randomly blocked websites With Jio, you don't really need ECH at all. The blocks are mostly rudimentary and bypassed with encrypted DNS (DoH / DoT / DNSCrypt) and Firefox (which fragments the TLS ClientHello packets into two). Also: https://news.ycombinator.com/item?id=34232190

Should've added this was back in like 2018 or so. Setting up DoH was harder than enabling SNI, and from my testing back then they were hard filtering on SNI (e.g. I used OpenSSL CLI to set the SNI to `pornhub.com` and connect to "known good" IPs, it'd still get reset).

Funnily enough, not setting the SNI and connecting the the origin IP, and then requesting the page worked fine.

Re: RFC 9849. TLS Encrypted Client Hello

#35

Post by maxloh »

arch-choot wrote: post #12

Glad that it's published, I'd been following it since ESNI draft days. Was pretty useful back when I was in India since Jio randomly blocked websites, and cloudflare adopted the ESNI draft on its servers as did Firefox client side which made their SNI based blocking easy to bypass. There was a period where I think both disabled ESNI support as work was made on ECH, which now is pretty far along. I was even able to se…

Why didn't the Indian government block traffics based on IP instead? That would make it much harder to bypass.

Re: RFC 9849. TLS Encrypted Client Hello

#36

Post by hzwanip »

szmarczak wrote: post #33
hzwanip wrote: post #30

Earlier quoted context omitted.

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.

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?

How would you (an arbitrary web server) fingerprint a TLS connection if the Client Hello is encrypted?

Re: RFC 9849. TLS Encrypted Client Hello

#37

Post by arch-choot »

jeroenhd wrote: post #17

Something that puzzles me about ECH: > In verifying the client-facing server certificate, the client MUST interpret the public name as a DNS-based reference identity [RFC9525]. Clients that incorporate DNS names and IP addresses into the same syntax (e.g. Section 7.4 of [RFC3986] and [WHATWG-IPV4]) MUST reject names that would be interpreted as IPv4 addresses. Aside from apparently not considering the existence of IP…

\> This makes the spec entirely meaningless for small servers and basically requires shifting hosting to shared hosts/massive CDNs to provide any protection against SNI snooping.

Actually you can setup ECH on your server, and configure the public_name to be something like `cloudflare-ech.com` , so clients would indeed use that in the OuterSNI, connect to you, without you needing to use CF. And middleboxes might think they are indeed connecting to CF (though CF publishes their IP ranges so this could be checked elsewhere).

Re: RFC 9849. TLS Encrypted Client Hello

#38

Post by maxloh »

szmarczak wrote: post #28
CloakHQ wrote: post #25

[flagged]

It doesn't prevent fingerprinting, stop spreading misinformation. It only prevents your ISP from knowing what website you're connecting to.

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

#39

Post by arch-choot »

maxloh wrote: post #35
arch-choot wrote: post #12

Glad that it's published, I'd been following it since ESNI draft days. Was pretty useful back when I was in India since Jio randomly blocked websites, and cloudflare adopted the ESNI draft on its servers as did Firefox client side which made their SNI based blocking easy to bypass. There was a period where I think both disabled ESNI support as work was made on ECH, which now is pretty far along. I was even able to se…

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 services behind a CDN it could lead to other websites being blocked, though of course sometimes this is ignored. See also: https://blog.cloudflare.com/consequences-of-ip-blocking/

Re: RFC 9849. TLS Encrypted Client Hello

#40

Post by conradludgate »

hzwanip wrote: post #36
szmarczak wrote: post #33

Earlier quoted context omitted.

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?

How would you (an arbitrary web server) fingerprint a TLS connection if the Client Hello is encrypted?

The website owner (or cloudflare in this case) has the keys to decrypt the client hello. That's necessary for routing information.
Post reply on HN