Will the adoption of this RFC prevent corporate MITM attacks like Zscaler TLS inspection?
RFC 9849. TLS Encrypted Client Hello
121–130 of 159 posts
Re: RFC 9849. TLS Encrypted Client Hello
#122TLS 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?
China and Russia started to block ESNI before Cloudflare stopped offering it so any argument that ESNI did not work is dubious
IME, ESNI worked for accessing _all_ websites using CF. AFAIK, ECH has never been offered for all websites using CF
ESNI was a bit simpler to use than ECH, e.g., when making HTTP requests with programs like openssl s_client, bssl client, etc. (I don't use popular browsers to make HTTP requests)
When CF ended the ESNI trial, there was nothing to take its place. The public was asked to wait for ECH
It has been roughly five years (correct me if wrong) without any replacement solution for plaintext SNI
ECH is available on a few test sites, e.g.,
But software support for ECH makes little practical difference for www users if major CDNs still don't support it
And as far as a solution that applies to CDNs other than CF, there has been no solution at all
Plaintext SNI is everywhere. It more or less defeats the stated purpose of "encrypted DNS"
Re: RFC 9849. TLS Encrypted Client Hello
#123TLS 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?
As far as I know, ESNI was pushed to a large number of websites in a very fast pace, and soon completely blocked by GFW. Then I didn't hear news about ESNI.
Re: RFC 9849. TLS Encrypted Client Hello
#124Earlier quoted context omitted.
> "we don't want IP's from Frankfurt showing up somewhere in Dubai" From a network perspective statements like that make no sense. IP addresses don't have any sort of physicality,
They have registration data. Someone could declare they don't want IPs registered to companies from Frankfurt with geofeeds in Frankfurt to be advertised in Dubai.
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 originates from. Only its AS path.
The DFZ contains all prefixes announced everywhere, for the internet is completely decentralized.
Re: RFC 9849. TLS Encrypted Client Hello
#125Earlier quoted context omitted.
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.
> 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?
Re: RFC 9849. TLS Encrypted Client Hello
#126Every time some security related protocol relies on DNS for its magic (looking at you, ACME), I lament the state of DNS providers. They all have different APIs, with different levels of security. Most at least offer some kind of REST API with API tokens for auth, which is relatively easy to set up. Many of those (not looking at any particular Germans..) however only offer a single API token across all DNS zones, whic…
[dead]
Re: RFC 9849. TLS Encrypted Client Hello
#127Earlier quoted context omitted.
How does ECH make it impossible for parents to control their children's access to computers? Sure they can't block sites at the router level, just like your ISP won't be able to block things at the ISP level, but you (the parent) have physical access to the devices in question, and can install client-side software to filter access to the internet. The only thing this makes impossible is the laziest, and easiest to by…
A lot of endpoint protection products rely on SNI sniffing. E.g. Apple's network extensions filters look at TLS handshakes.
Then they would drop the connection with esni
Re: RFC 9849. TLS Encrypted Client Hello
#128Will the adoption of this RFC prevent corporate MITM attacks like Zscaler TLS inspection?
Hopefully: yes
If the client (read: chrome) does support that (and prevent its desactivation), then zscaler and other shitty things are made even more useless than what they are today
Re: RFC 9849. TLS Encrypted Client Hello
#129Earlier quoted context omitted.
They have registration data. Someone could declare they don't want IPs registered to companies from Frankfurt with geofeeds in Frankfurt to be advertised in Dubai.
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.
Re: RFC 9849. TLS Encrypted Client Hello
#130Earlier quoted context omitted.
Only if the attacker has a valid certificate for the domain to complete the handshake with. Relying on HTTPS and SVCB records will probably allow a downgrade for some attackers, but if browsers roll out something akin to the HSTS preload list, then downgrade attacks become pretty difficult. DNSSEC can also protect against malicious SVCB/HTTPS records and the spec recommends DoT/DoH against local MitM attacks to preve…
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 transport is also a defense against DNS attacks by attackers on the local network, which is a common case where ClientHello and SNI encryption are desired. Moreover, as noted in the introduction, SNI encryption is less useful without encryption of DNS queries in transit.