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