Re: [TLS] Possible blocking of Encrypted SNI extension in China
David Fifield <david@bamsoftware.com> Tue, 11 August 2020 22:42 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 5DA533A0D6D for <tls@ietfa.amsl.com>; Tue, 11 Aug 2020 15:42:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, 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 8oE38Uk7PdpW for <tls@ietfa.amsl.com>; Tue, 11 Aug 2020 15:42:07 -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 C5E403A0D68 for <tls@ietf.org>; Tue, 11 Aug 2020 15:42:07 -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-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:To:From:Date:Sender: Reply-To:Cc: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=RMnK5AJQDuW2rxH/hts8SeOJLQTUqsRjNuP8Vr2ilOw=; b=hG7fm6iG29ABSqlaTT1pKo/Uwb Rzh2hyP6acAXPR0hQ+QxEmmW748+no2tqfartOOhqr4rEOD4FqkkcU7SBSyGVAEX1k83Oz/IFqoVA 4KzBWqztJNH3+Q070T7n0pXuAUKVtHegTBSLYtFuKtoC6q9NWLRwbwo52T3P4C4rVsjU=;
Date: Tue, 11 Aug 2020 16:42:03 -0600
From: David Fifield <david@bamsoftware.com>
To: tls@ietf.org
Message-ID: <20200811224203.qysncdptgiwfrvlu@bamsoftware.com>
Mail-Followup-To: tls@ietf.org
References: <67d52e25-71ed-4584-b2c3-6a71a6bdd346@www.fastmail.com> <1597119980162.55300@cs.auckland.ac.nz> <b32110f8-c9ba-e8db-f136-7cc60eba54e4@huitema.net> <1597123970590.77611@cs.auckland.ac.nz> <CAChr6SzzuyB7sxXJQ4gNJwa3iaQcC5jGPE3-sgfY_EkB7DoykA@mail.gmail.com> <1597125488037.97447@cs.auckland.ac.nz> <CAChr6SxLAJyweEDHL48-hT3X=d5E6jNrWZheOt+fSydpS=HhQw@mail.gmail.com> <c7e033d9-aa39-1293-2233-4ebb8d1502dc@huitema.net> <1597130085200.4129@cs.auckland.ac.nz> <CAChr6SypqD+J0LjJWxOQNQhXAvR7R4oLZQCKq_0PPbs+xjiSwg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAChr6SypqD+J0LjJWxOQNQhXAvR7R4oLZQCKq_0PPbs+xjiSwg@mail.gmail.com>
User-Agent: NeoMutt/20180716
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/rgftp-zDUeCZDSc6s56tG0K8XoA>
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: Tue, 11 Aug 2020 22:42:12 -0000
On Tue, Aug 11, 2020 at 01:38:50AM -0700, Rob Sayre wrote: > On Tue, Aug 11, 2020 at 12:14 AM Peter Gutmann <pgut001@cs.auckland.ac.nz> > > There was a paper that looked a traffic morphing published a year > or two ago that came to the same conclusion, to look like you're Skype or a > SIP VoIP call you need to actually be Skype or a SIP VoIP call. > > You could link it, perhaps. Peter is surely referring to the influential "The Parrot is Dead" paper from 2013, which found discrepancies in so-called "parrot" systems that superficially imitate some other cover protocol. The authors recommend not mere imitation, but tunnelling through a real implementation of the cover protocol (Section XI). "The Parrot is Dead: Observing Unobservable Network Communications" https://censorbib.nymity.ch/#Houmansadr2013b A point of clarification: "The Parrot is Dead" is not about "traffic morphing" in the restricted sense of Wright et al. (https://www.freehaven.net/anonbib/#morphing09), which is solely about shaping packets' sizes, not their contents nor the interpacket timing. "The Parrot is Dead" is rightly well-regarded, but one should not cite it without also mentioning some follow-on work, like "Seeing through Network-Protocol Obfuscation," which found many of the dead-parrot attacks impractical due to high false-positive rates or easy remediation. The authors proposed new detection attacks, optimizing for low false-positive rates and low cost of deployment, in terms of state and computation. "Seeing through Network-Protocol Obfuscation" https://censorbib.nymity.ch/#Wang2015a It is worth noting that, despite these papers' claims of easy detection of covert protocols, classification attacks of the type they propose are not really observed in practice. Available evidence indicates that network intermediaries, when they block, prefer to block using methods that are simpler and more robust, generally preferring a large number of false negatives to a small number of false positives. The following paper takes a contrarian view and proposes more realistic threat models based on the observed behavior of blockers: see the three "disconnects" between research and practice in Section I. "Towards Grounding Censorship Circumvention in Empiricism" https://censorbib.nymity.ch/#Tschantz2016a As an example, "Seeing through Network-Protocol Obfuscation" was published in 2015, but none of its proposed attacks (Figure 1) have come to pass, despite their ≈1.0 true-positive rates and ≈0.0 false-positive rates. obfs3 was defeated by active probing (https://censorbib.nymity.ch/#Ensafi2015b); even in China obfs4 is attacked by enumeration at the proxy distributor, not passive detection; and meek kept working until it was shut down by the CDNs, not the network blockers it was intended against. (FTE did not have enough users to make any strong statements about, I think.) Attempts to infer information about the contents of an encrypted network stream based on packet size and timing are usually filed under the term "website fingerprinting." You'll find many papers with that term in the title at https://www.freehaven.net/anonbib/. I am not as familiar with that field, but I understand that a common criticism of website fingerprinting research is that it may use unrealistic data or assumptions, such that it's not clear that the results generalize or can be effectively deployed. (There are echoes of this in Table 8 of "Seeing through Network-Protocol Obfuscation," which reports a large loss in accuracy when training and testing across corpora.) For a critical look at research earlier than 2014, see: "A Critical Evaluation of Website Fingerprinting Attacks" https://www.freehaven.net/anonbib/#ccs2014-critical With that said about website fingerprinting, on the topic of inference using packet sizes, timing, and other metadata, I have been impressed with this series of articles on inference against TLS and HTTPS, which I think avoid common missteps: "Enhanced telemetry for encrypted threat analytics" http://gen.lib.rus.ec/scimag/?q=10.1109%2FICNP.2016.7785325 "Deciphering Malware's use of TLS (without Decryption)" https://arxiv.org/abs/1607.01639 "Identifying Encrypted Malware Traffic with Contextual Flow Data" http://gen.lib.rus.ec/scimag/?q=10.1145%2F2996758.2996768 "Limitless HTTP in an HTTPS World: Inferring the Semantics of the HTTPS Protocol without Decryption" http://gen.lib.rus.ec/scimag/?q=10.1145%2F3292006.3300025 https://www.youtube.com/watch?v=pBVu9GEfE1I&t=80
- [TLS] Possible blocking of Encrypted SNI extensio… onoketa
- Re: [TLS] Possible blocking of Encrypted SNI exte… Christian Huitema
- Re: [TLS] Possible blocking of Encrypted SNI exte… David Fifield
- Re: [TLS] Possible blocking of Encrypted SNI exte… David Fifield
- Re: [TLS] Possible blocking of Encrypted SNI exte… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] Possible blocking of Encrypted SNI exte… Dmitry Belyavsky
- Re: [TLS] Possible blocking of Encrypted SNI exte… Peter Gutmann
- Re: [TLS] Possible blocking of Encrypted SNI exte… Christian Huitema
- Re: [TLS] Possible blocking of Encrypted SNI exte… Christopher Wood
- Re: [TLS] Possible blocking of Encrypted SNI exte… David Fifield
- Re: [TLS] Possible blocking of Encrypted SNI exte… Salz, Rich
- Re: [TLS] Possible blocking of Encrypted SNI exte… Peter Gutmann
- Re: [TLS] Possible blocking of Encrypted SNI exte… Christian Huitema
- Re: [TLS] Possible blocking of Encrypted SNI exte… Peter Gutmann
- Re: [TLS] Possible blocking of Encrypted SNI exte… Rob Sayre
- Re: [TLS] Possible blocking of Encrypted SNI exte… Peter Gutmann
- Re: [TLS] Possible blocking of Encrypted SNI exte… Rob Sayre
- Re: [TLS] Possible blocking of Encrypted SNI exte… Christian Huitema
- Re: [TLS] Possible blocking of Encrypted SNI exte… Rob Sayre
- Re: [TLS] Possible blocking of Encrypted SNI exte… Christian Huitema
- Re: [TLS] Possible blocking of Encrypted SNI exte… Peter Gutmann
- Re: [TLS] Possible blocking of Encrypted SNI exte… Rob Sayre
- Re: [TLS] Possible blocking of Encrypted SNI exte… David Fifield
- Re: [TLS] Possible blocking of Encrypted SNI exte… Nick Sullivan
- Re: [TLS] Possible blocking of Encrypted SNI exte… David Fifield
- Re: [TLS] Possible blocking of Encrypted SNI exte… Rob Sayre
- Re: [TLS] Possible blocking of Encrypted SNI exte… Peter Gutmann
- Re: [TLS] Possible blocking of Encrypted SNI exte… Rob Sayre
- Re: [TLS] Possible blocking of Encrypted SNI exte… Peter Gutmann
- Re: [TLS] Possible blocking of Encrypted SNI exte… Rob Sayre
- Re: [TLS] Possible blocking of Encrypted SNI exte… David Fifield
- Re: [TLS] Possible blocking of Encrypted SNI exte… David Fifield
- Re: [TLS] Possible blocking of Encrypted SNI exte… Carrick Bartle
- Re: [TLS] Possible blocking of Encrypted SNI exte… David Fifield