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

131–140 of 159 posts

Re: RFC 9849. TLS Encrypted Client Hello

#131

Post by sgjohnson »

pocksuppet wrote: post #129
sgjohnson wrote: post #124

Earlier quoted context omitted.

It’s not how any of it works. How do you determine to whom an IP is even registered to? They get sub-leased all the time. The best you can do is check who has administrative control over the prefixes RIR info, but that doesn’t mean that anyone with control is the factual user of the IPs. You could check the IRR for the ASN and base it on that, but still. There's also no way to actually know _where_ an IP actually ori…

> How do you determine to whom an IP is even registered to? You check the RIR's records. > They get sub-leased all the time. With records updated. If not, any consequences from wrong information fall on the lessor and lessee. > There's also no way to actually know _where_ an IP actually originates from. Only its AS path. Ping time from different locations on their upstream AS gives a good guess.

> With records updated. If not, any consequences from wrong information fall on the lessor and lessee.

Not always + there are no consequences whatsoever.

Plenty of leasing services will just provide you with IRR & RPKI, without ever touching the actual records.

> Ping time from different locations on their upstream AS gives a good guess.

Upstream AS is meaningless if it's a T1 carrier. Ping AS6939. They are everywhere.

Re: RFC 9849. TLS Encrypted Client Hello

#132

Post by 1vuio0pswjnm7 »

One topic I have not seen discussed is why CDNs, one by one, stopped allowing "domain fronting" yet ECH, developed by people working at CDNs, essentially uses a similar tactic, i.e., two hostnames, only one of them actually needed for a successful HTTP request

In truth ECH sends three: Host header + real SNI + dummy SNI

Re: RFC 9849. TLS Encrypted Client Hello

#133

Post by sedatk »

I'm okay advertising ECH as a privacy enhancement, it is, but make no mistake, it will not prevent government tracking or censorship. Governments will request platforms to disable ECH or ask for other signals to be reported, and ban those who don't comply. You can't fight political issues solely with technology.

Re: RFC 9849. TLS Encrypted Client Hello

#134

Post by tialaramex »

ignoramous wrote: post #125
tialaramex wrote: post #72

Earlier quoted context omitted.

> Funnily enough, not setting the SNI and connecting the the origin IP, and then requesting the page worked fine. Such tricks, called "domain fronting" are why ECH exists. The problem is that although domain fronting is effective for the client it's a significant headache for the provider. Big providers involved, such as Cloudflare have always insisted that they want to provide this sort of censorship resisting capab…

> Such tricks, called "domain fronting" GP said "not setting SNI"... doing TLS handshake with IP certs don't (need to) set SNI?

That's true, usually with domain fronting you provide the (wrong) SNI. But the same strategy is happening here, you were supposed to provide SNI and you didn't to avoid some potential censorship but it's a headache for the provider

They won't have received a certificate for the IP as a name, it's relatively unusual to have those, the main users are things like DoH and DoT servers since their clients may not know the name of the server... historically if you connect to a TLS server without SNI it just picks a name and presents a certificate for that name - if there's a single name for the machine that definitely works, and if not well - domain fronting.

TLS 1.3 even specifies that you must always do SNI and shouldn't expect such tricks to work, because it's such a headache.

Re: RFC 9849. TLS Encrypted Client Hello

#135

Post by krackers »

MBCook wrote: post #104
RandyOrion wrote: post #96

TLS Encrypted Client Hello (ECH) standard is another attempt on encrypting plaintext Server Name Indication (SNI). It is very useful for circumventing SNI-based censorship, which is adopted for years by state-backed systems like the Great Firewall (GFW). The previous attempt of encrypting plaintext SNI is Encrypted Server Name Indication (ESNI), which didn't end well.

As someone hasn’t followed this, what was wrong with ESNI?

I was curious as well, https://blog.mozilla.org/security/2021/01/07/encrypted-clien... has some info

>analysis has shown that encrypting only the SNI extension provides incomplete protection. As just one example: during session resumption, the Pre-Shared Key extension could, legally, contain a cleartext copy of exactly the same server name that is encrypted by ESNI. The ESNI approach would require an encrypted variant of every extension with potential privacy implications, and even that exposes the set of extensions advertised. Lastly, real-world use of ESNI has exposed interoperability and deployment challenges that prevented it from being enabled at a wider scale.

Re: RFC 9849. TLS Encrypted Client Hello

#136

Post by tptacek »

jeroenhd wrote: post #130
tptacek wrote: post #110

Earlier quoted context omitted.

DNSSEC can't protect against an ECH downgrade. ECH attackers are all on-path, and selectively blocking lookups is damaging even if you can't forge them. DoH is the answer here, not record integrity.

DNSSEC alone is obviously useless because any attacker interested in SNI hostnames can just as easily monitor DNS traffic. However, DoH/DoT without record integrity is about as useful as self-signed HTTPS certificates. You need both for the system to work right in every case. To quote the spec: > Clearly, DNSSEC (if the client validates and hard fails) is a defense against this form of attack, but encrypted DNS trans…

I don't think this is true; I think this misunderstands the ECH threat model. You don't need record integrity to make ECH a strong defense against on-path ISP attackers; you just need to trust the resolver you're DoH'ing to.

Re: RFC 9849. TLS Encrypted Client Hello

#137

Post by octoberfranklin »

1vuio0pswjnm7 wrote: post #132

One topic I have not seen discussed is why CDNs, one by one, stopped allowing "domain fronting" yet ECH, developed by people working at CDNs, essentially uses a similar tactic, i.e., two hostnames, only one of them actually needed for a successful HTTP request In truth ECH sends three: Host header + real SNI + dummy SNI

It is unlikely that any browser will ever require ECH without a fallback to non-encrypted ClientHello.

If the CDNs come under pressure, they can stop allowing ECH, just like they stopped allowing domain fronting. Unlike fronting, they can do this selectively -- like, only if the client is in $COUNTRY and the hostname is one of XYZ.

Re: RFC 9849. TLS Encrypted Client Hello

#139

Post by Hizonner »

ndriscoll wrote: post #85
josefx wrote: post #83

Earlier quoted context omitted.

> "don't let kids use a computer until they're 18" Ideally you would lock them up in a padded room until then. There is a significant amount of shared real world space that isn't supervised and doesn't require any age verification to enter either.

Notably, explicitly adult spaces like bars and porn shops are not among them, and a significant amount of virtual space would also not require age verification for the same reason.

Like what? The AV maniacs apparently want to apply it to any and all "spaces" where you might actually communicate with anybody.

Re: RFC 9849. TLS Encrypted Client Hello

#140

Post by Hizonner »

CloakHQ wrote: post #47
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.

[flagged]

> 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.

Post reply on HN