Although I do like the comment at the bottom that states the problem as disabling SNI not encrypting it. Encrypting SNI/ClientHello is over complicated, which is why ESNI was flawed and (allegedly) why Cloudflare disabled it. The solution to the plaintext SNI problem is to not send SNI (I don't send it unless necessary)

There is an alternative non-TLS method of encrypting traffic, per packet, that allows hosting multiple websites on the same IP. I use it in the homelab. It proves that TLS and SNI is not the only way

There's also a popular archive of www content that does not require SNI. It's older and larger than Cloudflare

The problem with software like Firefox is that it automatically sends SNI to every website no matter if SNI is required or not. The superuser thread mentions a Firefox add-on that no longer works. If Firefox is open source then why not just edit the code and recompile

Clearly, Mozilla is not going to provide a solution. It would rather add support for ESNI and then ECH as opposed to giving users an option to diable sending SNI

Mozilla is pro-surveillance advertising, Cloudflare is pro-surveillance advertising

Fortunately, not every HTTPS website is hosted on a shared IP, not every HTTPS website requires SNI. And popular web browsers derived from Mozilla and Google are not the only user agents

A couple of ways to not send SNI

1. Use an SSL client, e.g., openssl s_client, bssl client, etc.

2. Use a local forward proxy, e.g., stunnel, haproxy, etc.

Even if Cloudflare enables ECH across all the websites it controls, and we have been waiting for years, there is still the issue of SSL termination by Cloudflare. For many of those sites, all the TLS traffic, not just the SNI, is available as plaintext to Cloudflare and to whomever Cloudflare, a US corporation, may or must share it with