search

net4people / bbs

Forum for discussing Internet censorship circumvention
3.49k stars 82 forks source link

On the Importance of Encrypted-SNI (ESNI) to Censorship Circumvention (FOCI 19) #10

Open wkrp opened 5 years ago

wkrp commented 5 years ago

On the Importance of Encrypted-SNI (ESNI) to Censorship Circumvention Zimo Chai, Amirhossein Ghafari, Amir Houmansadr https://censorbib.nymity.ch/#Chai2019a https://www.usenix.org/conference/foci19/presentation/chai

The TLS server name indication (SNI) field reveals the destination server name of a TLS connection, and therefore may be used by censors for destination-based filtering. Censors increasingly turn to SNI filtering, because the increase in encrypted protocols such as TLS are obsoleting traditional detection techniques like keyword filtering. ESNI aims to encrypt the SNI field and remove it as a means of traffic classification. This paper measures censorship in China to estimate the possible effectiveness of ESNI to unblock existing sites, measures the current extent of ESNI deployment, and tests for blocking of ESNI itself in multiple countries.

The authors estimated a bound on the number of existing, censored web sites that could potentially be unblocked by ESNI. They tested each domain in an Alexa top 1 million list for censorship of three kinds: DNS-based, IP-based, and SNI-based. They had one VPS in China and one VPS in the USA. For DNS-based blocking, they did outside-in DNS requests (from the USA VPS to the China VPS) and looked for an injected DNS response. For IP-based blocking, they did inside-out port scans to ports 80 and 443 and compared the results to a USA control scan. For SNI-based blocking, they send outside-in ClientHello probes and looked for injected RST packets. Of the 24,210 domains blocked by either DNS poisoning or SNI filtering, 16,928 are additionally blocked by IP address, so ESNI would not help to unblock them, assuming that they stay at their present hosting. The other 7,282 domains that are blocked only by DNS poisoning, SNI filtering, or both, have the potential to be unblocked by ESNI, assuming that their IP address cannot easily be blocked. Because ESNI presupposes secure DNS, here I'm assuming that ESNI defeats both SNI filtering and DNS poisoning.

They measured the number of ESNI-supporting web sites among their Alexa top 1 million by checking a special Cloudflare-only debugging page, /cdn-cgi/trace. Their assumption is that only Cloudflare-hosted sites may support ESNI; their technique would have missed ESNI sites that are not on Cloudflare, as well as Cloudflare-hosted sites that do not have the debugging page active, for whatever reason. After making a list of Cloudflare sites by looking for the debugging page, they tested each for ESNI support using an ESNI-enabled Firefox, configured to use https://1.1.1.1/ as a DNS-over-HTTPS resolver. 10.9% of the 1 million sites had a Cloudflare debugging page; of that fraction, almost all supported ESNI. 66 of the domains blocked by SNI filtering in China currently support ESNI, and are presumably accessible if ESNI is used.

Finally, they checked for existing censorship of ESNI itself, in 14 countries (13 VPS, 1 VPN). They used an ESNI-enabled Firefox to browse around 100K ESNI-supporting sites, and also did DNS TXT queries for ESNIKeys, which is one of the steps in using ESNI. They did not find blocking of ESNI anywhere, not even in South Korea, where there were rumors that it had taken place in June 2019.

Other tidbits: In the outside-in SNI filtering tests, naked packets containing a forbidden SNI did not trigger injection; they had to be preceded by a TCP three-way handshake in order to be detected. After detection, new SYN packets triggered an injected SYN/ACK with bad sequence numbers; other kinds of packets triggered an injected RST. OCSP messages may leak the destination domain despite ESNI:

The authors have published their tools and data at http://traces.cs.umass.edu/index.php/Network.

ValdikSS commented 5 years ago

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:

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.

wkrp commented 5 years ago

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).