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

David Fifield <david@bamsoftware.com> Mon, 10 August 2020 16:19 UTC

Return-Path: <david@bamsoftware.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09C1C3A07F2 for <tls@ietfa.amsl.com>; Mon, 10 Aug 2020 09:19:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.089
X-Spam-Level:
X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_TVD_FUZZY_SECURITIES=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bamsoftware.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjLsLgRXnDPh for <tls@ietfa.amsl.com>; Mon, 10 Aug 2020 09:19:38 -0700 (PDT)
Received: from melchior.bamsoftware.com (melchior.bamsoftware.com [IPv6:2600:3c00:e000:128:de39:20ee:9704:752d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85B883A046E for <tls@ietf.org>; Mon, 10 Aug 2020 09:19:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bamsoftware.com; s=mail; h=In-Reply-To:Content-Type:MIME-Version:References :Message-ID:Subject:To:From:Date:Sender:Reply-To:Cc:Content-Transfer-Encoding :Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=FgTjeddARZNEbrzFIOiKhuINlVnRhQU+sEA+uclFq24=; b=ClX4CThKTwmP4TmGdjzwKMXVSB blVG7vz3Aw8/5AoZlPY7acGC7ElREWONwiQ3d8x9vhzYyblSiRhTRfu0y0p0orqoFMYOyW6FYdpz9 neiCh/y2cUK+2XK+x1fZ+QlRVkllT17dRAVjO+d3aXIgQ1YGBVcGtRztlpy/ogI/FhJk=;
Date: Mon, 10 Aug 2020 10:19:32 -0600
From: David Fifield <david@bamsoftware.com>
To: tls@ietf.org
Message-ID: <20200810161932.rxokshqs2xx2jxin@bamsoftware.com>
Mail-Followup-To: tls@ietf.org
References: <uGJxvVQRPcgn2GZKsKuuVN4SyTe7EOiV3iEK3Cq3Izo0ZstAh1LxEzMKrDZ_0VTrLqeYXQb4k1Qy5uJmEy04zNgngoHBONhVZnvddYYybt8=@iyouport.org> <71e4d18d-9ad8-fd72-729c-db5a0cf7593b@huitema.net> <20200809153526.vf5zlongieoswb22@bamsoftware.com> <1597030308337.61220@cs.auckland.ac.nz> <8d18ea7c-8f10-1901-38b1-5e1b62d54eec@huitema.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <8d18ea7c-8f10-1901-38b1-5e1b62d54eec@huitema.net>
User-Agent: NeoMutt/20180716
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/pdLJtN4O9rbtZicQD0lW8PUltZo>
Subject: Re: [TLS] Possible blocking of Encrypted SNI extension in China
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Aug 2020 16:19:43 -0000

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.