SNI is used to allow the frontend gateway to select the correct certificate; it should be harder to block if the frontend gateway instead had a single certificate with all the domains it proxied (obviating the need for SNI).

Of course, that means the gateway must terminate the TLS connection for every site (and therefore be able to read its contents), whereas with SNI it could redirect the TLS connection itself to the appropriate server, while being unable to spy on it.

In practice what happened before SNI is that every SSL/TLS site used a dedicated IP, which makes it quite easy to block.

I meant something more like encrypted SNI in TLS 1.3[1], but that has covering as an explicit design goal, so I guess that answers my question.

Still, it's a matter of politics, and not of technology. Google here chooses to stop covering for Telegram/Signal, even if the technology allows it.

[1]: https://www.ietf.org/proceedings/94/slides/slides-94-tls-8.p...

If you could remove the common name/url from the clear text portion of the packet, that would make filtering the web site more difficult. Some enterprise firewalls/filters look at the CN to match against a ratings database in lieu of DPI-SSL/MITM. Ex: https://itzecurity.blogspot.com/2014/05/configuring-fortios-...

I suspect if encrypted SNI became popular, you would find them censored via one means or another. I imagine state operators have the resources to scan all domains, connect to them to identify their content and just blacklist their IPs (along with any innocent domains hosted on the same IP).

I could also see state operators mandating the plaintext SNI (by dropping non-SNI TLS), and operating a transparent TLS proxy based on that SNI with their own DNS lookup (so you would have to provide a legit, resolvable hostname in the plaintext SNI).