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. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
