In the wild, that's not true at all[0][1]. The corporate firewall at my employer actually wasn't able to block ECH until they updated it then it was able to block sites as usual.
0: https://community.fortinet.com/t5/FortiGate/Technical-Tip-Ho...
1: https://docs.broadcom.com/doc/symantec-ech-whitepaper (see page 8)
This is literally impossible. What your corp fw likely does is mitm outer SNI because your IT department installed your company CA in every client's trust store. So unless you do that at national level your only other option is to block ECH entirely.
Edit: actually totally possible but you need build quantum computer with sufficient cubits first =)
Last I heard, the QCbros were still trying to find the prime factors of 15.
(I remember using quantum algorithms to find prime factors 25 years or more ago, using the Quantum::Suppositions Perl module.)
I ready the FortiGate link and this is the gist:
The DNS filter setting on the FortiGate analyzes the DoH traffic and strips out the ECH parameters sent by the DNS server in the DoH response. If the client does not receive those parameters, it cannot encrypt the inner SNI, so it will send it in clear text.
I'm surprised that works. Doesn't TLS1.3 do the thing where it crosschecks (a hash of) the setup parameters after key-agreement to protect against exactly this kind of downgrade attack?
(My phone screen is too small to look through the RFCs right now.)
I think what you're describing is TLS1.3 Finished verification so that happens after DoH response during the actual handshake. Basically this works because ECH is fairly new and there's no HSTS-style "always use ECH for this site" configuration yet. And ofc this only works if you configured FortiGate as your DNS (corp network) or if it's doing MITM (though I'd expect browser would verify cert fingerprint for DoH connections as well).
Trying to downgrade or strip extensions from any TLS 1.3 connection will simply break the connection.