From Mozilla link above: Since publication of the ESNI draft specification at the IETF, 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.
IMO, SNI should only be added at the firewall (using HTTPS proxy, for example), so the network operator can monitor/filter which hosts are being accessed.
If you actually have a "HTTPS proxy" then the entire transaction is plaintext at that proxy, the operator can do whatever they want.
In particular they can choose whether they want to support protocol extensions like eSNI or ECH on either or both sides of the proxy.
If your idea is "But surely it should just pass through extensions it doesn't understand" what you've got there is nonsense, it isn't a "firewall" it's a dumpster fire. The extensions have meaning to the peers, if it tries to pass extensions through without understanding them it's now speaking gibberish to both sides.
