On the Importance of Encrypted-SNI (ESNI) to Censorship Circumvention (FOCI 19) about bbs HOT 2 OPEN

What happens with usual SNI: DPI detects request to the IP address listed in the registry (even type=domain has a list of IP addresses). DPI detects SNI, checks that it's not in the registry, determines that the user tries to access non-blocked website and allows the connection.

What happens with ESNI: DPI detects request to the IP address listed in the registry. DPI does not detect any SNI in TLS ClientHello packet and rejects the connection.

I think you're right that ESNI, used to access ordinary web sites, does not always increase availability. ESNI only forces the censor into a choice of "block all or block none" for each IP address, where before it could selectively "block some." The decision is not always in our favor; surely in some cases the choice will be "block all" and formerly unblocked sites will become blocked. Just like when wikipedia.org went all-HTTPS and the GFW could no longer selectively block single articles, and blocked the whole domain instead.

But using ESNI in a browser to directly browse web sites is just one application. There's another important application, which is building proxies. We host a proxy on an IP address the censor is unwilling to block, and connect to that proxy using ESNI to hide its identity. Then we can access blocked sites through the proxy, rather than connecting to their IP address directly. In a hypothetical future, browsers start using ESNI by default ⇒ censor cannot easily use presence of ESNI / absence of plaintext SNI as a blocking signal ⇒ we can use ESNI to access a proxy on an IP address that is not otherwise blocked.

In the domain fronting world, there's an analogy with CacheBrowser/CDNReaper and meek. CacheBrowser and CDNReaper do not use proxies; you can only use them to access sites co-hosted on a CDN, and you access the CDN edge server directly, domain-fronting your requests to hide which specific site you're accessing. meek uses a proxy hosted on the CDN, which imposes an additional layer of overhead, but from that proxy you can access any site, whether it's on the same CDN or a different CDN, or not on a CDN at all.

I have hopes, too, that browsers will implement ESNI when accessing plain old HTTP proxies over HTTPS. That would be great because then users would not need any additional client-side software, only a line of configuration. On the deployment side, it would require finding co-hosting for the proxy that permits a standard HTTP proxy to run (instead of the custom tunneling protocol used in meek).

from bbs.

In Russia, we have lots of ISPs (thousands), each of them have different hardware and implement different blocking methods.
Usually, ESNI makes things worse in terms of website availability for ISPs with DPI.
Russia has a Registry of Blocked Websites, every entry in which includes:

• Type of blocking: default (usually used for exact HTTP URIs), domain, ip
• Domain name
• IP address/addresses
• Some other non-technical information, like the reason for blocking and the organization which added this item to the list

Example: say we have blockedwebsite.com HTTPS website which is blocked by domain name (type=domain), and is hosted on Cloudflare. Other (not blocked) website notblocked.com share the same IP address on Cloudflare.

The person wants to access notblocked.com.

What happens with usual SNI: DPI detects request to the IP address listed in the registry (even type=domain has a list of IP addresses). DPI detects SNI, checks that it's not in the registry, determines that the user tries to access non-blocked website and allows the connection.

What happens with ESNI: DPI detects request to the IP address listed in the registry. DPI does not detect any SNI in TLS ClientHello packet and rejects the connection.

from bbs.