IETF Logo Mail Archive

[TLS] Possible blocking of Encrypted SNI extension in China

onoketa <onoketa@iyouport.org> Thu, 30 July 2020 15:46 UTC

Return-Path: <onoketa@iyouport.org>
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 AFB0B3A0A9E for <tls@ietfa.amsl.com>; Thu, 30 Jul 2020 08:46:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iyouport.org
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 nvr5_5XeQ1o7 for <tls@ietfa.amsl.com>; Thu, 30 Jul 2020 08:45:59 -0700 (PDT)
Received: from mail-40134.protonmail.ch (mail-40134.protonmail.ch [185.70.40.134]) (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 965713A0AB0 for <tls@ietf.org>; Thu, 30 Jul 2020 08:45:59 -0700 (PDT)
Date: Thu, 30 Jul 2020 15:45:48 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iyouport.org; s=protonmail; t=1596123957; bh=fxdL1smBW4pT2rcPfPxhk4esCe1B9za6eZox3ubfVNA=; h=Date:To:From:Reply-To:Subject:From; b=N4JPdmHnQNmbCJj4Hj5d8768g5tvR00UjDYx/bo+wW5NtioDfZB9aVljkCdVyOrH5 biUDoggXksiuOm7T1nVDGz2ETQT9YgQQYacz1ThpiqgOPVw9IN38WuGRXsYt22AVgo Pc2f7w2fHqNWjaK+8Sf37YL87hEXVwZ8tvW9PAEA=
To: "tls@ietf.org" <tls@ietf.org>
From: onoketa <onoketa@iyouport.org>
Reply-To: onoketa <onoketa@iyouport.org>
Message-ID: <uGJxvVQRPcgn2GZKsKuuVN4SyTe7EOiV3iEK3Cq3Izo0ZstAh1LxEzMKrDZ_0VTrLqeYXQb4k1Qy5uJmEy04zNgngoHBONhVZnvddYYybt8=@iyouport.org>
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha256"; boundary="---------------------40de9e46b8694b32d32718bc06e6aadf"; charset="utf-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/YzT5LjLJ_6WWhdnU2wVsKNKR6_I>
Subject: [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: Thu, 30 Jul 2020 16:26:37 -0000

Hi,

The Great Firewall of China may have identified and blocked Cloudflare's ESNI implementation.

I have found that when using a TLS client hello with ESNI extension to connect to servers behind Cloudflare's CDN, the connection will be cut off after the whole TLS handshake is done. And then that IP address will be blocked at the TCP level for several minutes.

onoketa

v2.27.8 | Report a Bug | By Email | System Status