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

[David Fifield <[e-mail]>]

On Sun, Aug 09, 2020 at 11:15:25PM -0700, Christian Huitema wrote:
> 
> On 8/9/2020 8:31 PM, Peter Gutmann wrote:
> > >From the writeups I've seen, what they're blocking is TLS 1.3, not ESNI.
> 
> Please check David Fitfield's message above in the thread. The research
> that he quoted is quite specific, "The ESNI detector only matches the
> ESNI encrypted_server_name extension 0xffce (draft-ietf-tls-esni-00
> through -06), not the ECH extensions encrypted_client_hello 0xff02,
> ech_nonce 0xff03, outer_extension 0xff04 (draft-ietf-tls-esni-07)."

That's right. The block is specifically against ESNI, not all TLS 1.3.
There is still a minor open question on the issue of ECH extensions
specifically (0xff02, 0xff03, 0xff04). When we tested ECH, we did not
try syntactically well-formed extension values, which proved to be
necessary in the case of ESNI, since the GFW's detector has at least a
rudimentary TLS parser. This leaves open the possibility that a
ClientHello with well-formed ECH extensions would also trigger a block:
https://github.com/net4people/bbs/issues/43#issuecomment-670794117

TLS 1.3 without SNI, ESNI, ECH	not blocked
TLS 1.3 with SNI only		not blocked
TLS 1.3 with ESNI only		blocked
TLS 1.3 with ECH only		still uncertain

The vast majority, I'm sure, of today's TLS 1.3 connections are
unaffected by the GFW's new block, because they do not use ESNI.
(Personally, I argue that it is *because* ESNI is not yet widely used
that it can be effectively blocked now.)

The bidirectional nature of the GFW makes it easy to test blocking
hypotheses, following the instructions at
https://mailarchive.ietf.org/arch/msg/tls/Dae-cukKMqfzmTT4Ksh1Bzlx7ws/.
One can try the 64-byte payload given there, or modify it to remove the
0xffce marker. To capture your own genuine ESNI ClientHello, use
Firefox 68 or later and change these settings in about:config:
	network.security.esni.enabled=true
	network.trr.mode=3
	network.trr.uri=https://mozilla.cloudflare-dns.com/dns-query
	network.trr.bootstrapAddress=104.16.249.249
Then visit an ESNI-capable web site. A convenient choice is
https://www.cloudflare.com/cdn-cgi/trace because it has a
"sni=encrypted" or "sni=plaintext" diagnostic.