Just enabling ECH doesn't stop this, firewalls can see it and mangle the data to force a downgrade because most servers need to support older protocols. It's more accurate to say that once sites only support ECH, then they'll be forced to stop downgrading or deal with angry users.
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.
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 =)
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.
So basically they mess with DoH ECH config and trigger fallback behavior in the clients. I don't think any browsers do this yet but I think this loophole is not gonna last.
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).