Re: [TLS] Possible blocking of Encrypted SNI extension in China

[David Fifield <[e-mail]>]

On Wed, Aug 12, 2020 at 06:51:48AM +0000, Peter Gutmann wrote:
> David Fifield <[e-mail]> writes:
> 
> >Peter is surely referring to the influential "The Parrot is Dead" paper from
> >2013
> 
> Yep, that was it, thanks (at least one person catalogues their reading by the
> looks of it :-).  Thanks for the ref to the followup, can't remember seeing
> that, but doesn't that just reinforce the Parrot paper?

Both papers are about detection, but I would not call one a
reinforcement of the other. Section 4 of "Seeing through
Network-Protocol Obfuscation", "Semantics-based attacks," finds problems
in the attacks proposed by "The Parrot is Dead". The authors design new
styles of attack (Section 5, "Entropy-based attacks", and Section 6,
"ML-based attacks") and apply them to deployed covert communications
systems. But of these systems, only one (FTE) is a "parrot" or mimicry
system (see the trichotomy of categories under "Network protocol
obfuscation" in Section 2). obfs3 and obfs4 are randomizing protocols,
not designed to resemble any particular cover protocol, and meek uses
exactly the tunnelling approach advocated in "The Parrot is Dead,"
sending its requests via a headless Firefox for the sake of a proper TLS
fingerprint (Section 5.1 of https://censorbib.nymity.ch/#Fifield2015a).
The results do not really support the thesis that tunnelling is
essential or necessarily more resistant to blocking, though it remains a
good rule of thumb. Both tunnelling-based and non-tunnelling-based
systems are widely used today, with success in practice.

> The "Grounding Censorship Circumvention in Empiricism" paper is an important
> one too, you need to look at what the attackers are doing otherwise you'll end
> up throwing a ton of crypto at something that makes no difference.  In
> particular in reference to a question someone else asked about ECH and TLS
> 1.3, since it's not defending against anything the censors are doing I can't
> see what its presence or absence would do.  Something like ECH seems like
> classic inside-out design, "here is our cool piece of crypto trickery, and
> whatever it happens to defend against is the threat".

Rob is correct. Blocking on the basis of plaintext SNI is common and
extensively empirically documented. It would be unusual, these days, for
a firewall to support DNS, IP address, and HTTP keyword blocking,
without also supporting SNI blocking. A few examples:
https://ooni.org/post/2020-tls-blocking-india/
	We recorded SNI-based blocking on both Bharti Airtel and
	Reliance Jio.
https://ooni.org/post/2020-iran-sni-blocking/
	To evaluate this methodology, we ran experiments in Iran because
	we know that Iran implements SNI based blocking.
https://censorbib.nymity.ch/#Chai2019a Section 4.2
	We detect that 21,446 sites are under SNI filtering in China.
	One interesting observation is that only 70 websites are
	exclusively censored by SNI filtering. In other words, SNI
	filtering is almost always used in a combination with other
	censorship techniques.
https://ooni.org/post/2019-egypt-blocks-bbc-and-alhurra/
	This is quite a strong indication of the presence of some form
	of Deep Packet Inspection (DPI) technology that is aware of TLS
	and which is most likely fingerprinting the SNI field of the TLS
	handshake.
https://censorbib.nymity.ch/#VanderSloot2018a Section 6.4
	Unfortunately, SNI places the domain name in clear-text in the
	first message sent by the client to the server, making it easy
	to detect when a client is connecting to a particular site from
	only the first message in a TLS handshake. We find that networks
	do interfere based on this first message alone.

But you don't have to take anyone's word for it, at least in the case of
the Great Firewall; this is another aspect that's easy to test from
outside. Start a packet capture on port 443 and send a ClientHello,
containing an SNI field known to be blocked, to a responsive HTTPS host
in China. You will immediately receive three RST packets, which are not
sent by the remote server but are injected by the firewall.

$ openssl s_client -connect www.tsinghua.edu.cn:443 -servername www.facebook.com

10:03:30.857872 IP localhost.60084 > www.tsinghua.edu.cn.https: Flags [S], seq 864764526, win 64240, options [mss 1460,sackOK,TS val 2739496015 ecr 0,nop,wscale 7], length 0
10:03:31.188496 IP www.tsinghua.edu.cn.https > localhost.60084: Flags [S.], seq 4063746934, ack 864764527, win 2105, options [mss 1460,nop,wscale 2,sackOK,TS val 202217658 ecr 2739496015], length 0
10:03:31.188555 IP localhost.60084 > www.tsinghua.edu.cn.https: Flags [.], ack 1, win 502, options [nop,nop,TS val 2739496346 ecr 202217658], length 0
10:03:31.189003 IP localhost.60084 > www.tsinghua.edu.cn.https: Flags [P.], seq 1:319, ack 1, win 502, options [nop,nop,TS val 2739496346 ecr 202217658], length 318
10:03:31.508859 IP www.tsinghua.edu.cn.https > localhost.60084: Flags [R.], seq 1, ack 319, win 995, length 0
10:03:31.508907 IP www.tsinghua.edu.cn.https > localhost.60084: Flags [R.], seq 1, ack 319, win 995, length 0
10:03:31.510050 IP www.tsinghua.edu.cn.https > localhost.60084: Flags [R.], seq 1, ack 319, win 995, length 0