Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

Jacob Appelbaum <> Wed, 02 December 2015 15:38 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A788E1A9127 for <>; Wed, 2 Dec 2015 07:38:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vO3HrpfG9_CV for <>; Wed, 2 Dec 2015 07:38:54 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3A1AA1A90D0 for <>; Wed, 2 Dec 2015 07:38:54 -0800 (PST)
Received: by igl9 with SMTP id 9so112995362igl.0 for <>; Wed, 02 Dec 2015 07:38:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=byZI68KNnKZkJ4B/lQ5kBtrpwW1jVmBcvN+dxWP8tB0=; b=O9pLSeKxi1JsxnC1SW/Mc2RruK8qcI+9MXHdJdGeFuFgTB43C4lcT7vIXuVdl6snLF GZ2alGs24EAQNcyO5PJsdBlS6qxf1NyIR+lXygMid7bSiaodDXRRzpyXNeJb1ZWpiGY4 jaIDBt7tGdWZVwiS7itKGQZDKmNfpw/VIrLCvqbXK3HeoxlznYfgV9j9GajjNoiQZiRq 87KudOK+18y3rHWdORTCGdR9wfaDgKLFM6a1Eb8W8FkrqSlIdm2zPbtKPn3H1KFc5fcQ BCU4U4hiFEHFELmGel0M6GnxxxzTTi9hcDIt2BfiMQlfbzekKDC6rgcnfsd2gxTBypf1 nGrA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=byZI68KNnKZkJ4B/lQ5kBtrpwW1jVmBcvN+dxWP8tB0=; b=bJ/xpmWXI2OGMfPgu3impO4tzY3cSCmLEdkSyt2iSNXfdLkgehf33BK1/qrg/Wu5iq 1qAcHuvgTsvEimRkcOvhUwf+HqqDUPI8HqrgPgIaWNzcaQwwI5VaXmV1B8onMLmlnqal o2S9P/22cNsZw9VLyUJ2G7ESA/eTLJsmWD7q04w0mLPVmQuUYsoBzHdsK1mmlFnbK2Hk e2cMfazw3ddM1h1c+COhpyxTkQI47rBUFJzk63dASR6tdUgz9AAAIn/6B3fcso3f2Ofl quy10Y9F7H2PG5Zlq1oFOX6WZYfkK6xmboGz78TQM+StbivGFVkF6w0PgGra2HJPHkzE Dfng==
X-Gm-Message-State: ALoCoQl09PoC7N+yXhSynM0Ykv/p51+U5o18FI3PwOsVzZTlbDDE3+oYB3SAZ2wh7O/Yo6BaOmBK
MIME-Version: 1.0
X-Received: by with SMTP id vu9mr4438727igb.89.1449070733568; Wed, 02 Dec 2015 07:38:53 -0800 (PST)
Received: by with HTTP; Wed, 2 Dec 2015 07:38:53 -0800 (PST)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
Date: Wed, 02 Dec 2015 15:38:53 +0000
Message-ID: <>
From: Jacob Appelbaum <>
To: Mike Copley <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 02 Dec 2015 15:38:55 -0000

On 12/2/15, Mike Copley <> wrote:
> On 2/12/2015, at 1:38 pm, Yoav Nir <> wrote:
>>> On 2 Dec 2015, at 2:59 PM, Jacob Appelbaum <> wrote:
>>>> These are corporate
>>>> firewalls. When it comes to filtering HTTPS connections, firewalls have
>>>> three ways to classify the connection:
>>>> 1. Look at the SYN and SYN-ACK packets. Make decisions by IP addresses.
>>>> 2. #1, and additionally follow the stream looking for certain patterns.
>>>> 3. Full “TLS proxy”.
>>>> Whether they are relevant stakeholders or not is to me the same question
>>>> as
>>>> whether the network administrator in a corporate environment is a
>>>> relevant
>>>> stakeholder. We just make the middlebox that they deploy.
>>> That is a kind of goal post shifting but seeminly weirdly not
>>> relevant, if I understand. If it won't trouble the middle box, it
>>> doesn't sound like the network administrator will have troubles.
>>> It will however reduce off-path reassembly to technique #1 from above
>>> and #2 will be partially eliminated and #3 isn't an option for that
>>> attacker anyway.
>>> We are working on solutions to #1, TLS 1.3 should reduce and if
>>> possible, eliminate #2, and #3 is something that should require
>>> consent of the user in question. Without consent, TLS 1.3 should hard
>>> fail closed as a security measure.
>> A TLS proxy requires user consent (or at least device administrator
>> consent) with TLS 1.2. TLS 1.3 does not change that.
> With SNI it’s possible to operate a transparent TLS proxy without the users
> consent. The proxy only has visibility of the SNI hostname - no user data
> (source: the company I work develops routers with such a proxy).

Yes, we use that for a pluggable transport ( ) to bypass
such proxies - connect to, use http header to route to, and so on.

> It’s quite
> useful in hotspot/public wifi environments where making policy decisions
> based on hostname is more than sufficient, and explicit user configuration
> of proxy settings is a non-starter.

That is an attack in my book and public hotspots that do MITM are also
a problem that we need to solve. It is partially solved with WISPr
XML, I think. Though everything in this space is awful because it
breaks everything by default while a system thinks it is online.

> As long as the SNI data is still
> available in the clear, encrypting subsequent headers won't impact the
> ability for our particular proxy to operate, as it’s just a generic TCP
> relay agent at that point.

I hope that we'll hide the SNI data by default and I understand that a
discussion about encrypted SNI is currently scheduled for some point
in the future.

> With all that being said, I think the concerns about length hiding are
> better addressed through other means rather than header encryption. Not sure
> if this is the right place to consider, but would DTLS 1.3(?) be able to
> encrypt headers and still handle packet loss and re-ordering? If DTLS needs
> cleartext headers, would it be better to advise one approach for both
> protocols?

I'm pretty sure that encryption is the only way to "hide"  the data we
want to hide...

All the best,