Re: [TLS] ESNIKeys over complex

Ilari Liusvaara <ilariliusvaara@welho.com> Sat, 08 December 2018 19:03 UTC

Return-Path: <ilariliusvaara@welho.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 4D9F3130E6A for <tls@ietfa.amsl.com>; Sat, 8 Dec 2018 11:03:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
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 kjXP-N82fwpv for <tls@ietfa.amsl.com>; Sat, 8 Dec 2018 11:03:51 -0800 (PST)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A5C7130E4D for <tls@ietf.org>; Sat, 8 Dec 2018 11:03:50 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 170C045B6B; Sat, 8 Dec 2018 21:03:49 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id 7pDzzQrLJl9v; Sat, 8 Dec 2018 21:03:48 +0200 (EET)
Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 4572D2330; Sat, 8 Dec 2018 21:03:46 +0200 (EET)
Date: Sat, 8 Dec 2018 21:03:45 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: David Fifield <david@bamsoftware.com>
Cc: tls@ietf.org
Message-ID: <20181208190345.GA10225@LK-Perkele-VII>
References: <797cd94d-b5be-24fd-923c-53b614cbc2c5@cs.tcd.ie> <20181208163830.GA7470@LK-Perkele-VII> <20181208184256.y55g7q2xdcuzv2c5@bamsoftware.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20181208184256.y55g7q2xdcuzv2c5@bamsoftware.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/-iYgP_QmCp0FdaL7ArMx5i79J20>
Subject: Re: [TLS] ESNIKeys over complex
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: Sat, 08 Dec 2018 19:03:54 -0000

On Sat, Dec 08, 2018 at 11:42:56AM -0700, David Fifield wrote:
> On Sat, Dec 08, 2018 at 06:38:30PM +0200, Ilari Liusvaara wrote:
> > While thinking about the previous, I ran into some issues with the
> > split mode. Firstly, if the fronting server does not encrypt the
> > client_hello when transmitting it to backend server, passive attack
> > can match incoming connections with backend servers. This reduces
> > anonymity set to a single backend server (a lot smaller set).
> > 
> > And secondly, even if server encrypts the client_hello, but does not
> > use a tunnel to backend, if server does not have client hello replay
> > filtering (and such filtering is hard on typical fronting servers),
> > replay attacks and some very simple traffic analysis can discover the
> > backend server (again reducing the anonymity set by a lot).
> > 
> > This means that the fronting server should have an encrypted tunnel
> > with the backend server (and there is likely double encryption).
> 
> I see--you're thinking of an observer who can see "both sides" of a
> connection: the link between the Client and the Client-Facing Server,
> and the link between the Client-Facing Server and the Backend Server.
> I agree: such an observer could, through timing analysis, deanonymize
> client connections (i.e., tell which Backend Server the Client is
> accessing, as if it were accessing directly and not through the
> Client-Facing Server). I suppose to really defend against a global
> observer, you would need some kind of mixnet.

If the client hello is not encrypted to backend server, one does not
need timing analysis if one is on both sides: Things like key share
and client random allow much more robust correlation.

> It looks like a little bug in the draft. I've checked just now and I
> don't see that it says exactly *where* the observer is. I had assumed
> that the observer only sees the Client–Server link (in Shared Mode) or
> the link between Client and Client-Facing Server (in Split Mode).

I think there have actually been real world attacks where link from
client to CDN is encrypted, but link from CDN to backend is not,
and attacker attacked the CDN to backend link.

And those were active attacks, the attacks I am talking about are
passive-only (not as exciting, but more dangerous).

> I don't understand your point about replay and encrypting the Client
> Hello. An observer doesn't need to see the contents of the Client Hello
> to identify a Backend Server--the destination IP address is enough. I
> don't see what specific attack you have in mind using replay, but it
> seems to me that even an encrypted tunnel is insufficient. Unless the
> encrypted tunnel additionally obfuscates packet sizes and timing, an
> observer can correlate e.g. burst sizes and match incoming flows to
> outgoing flows, in the manner of website fingerprinting.

>From the destination IP address, one can only tell that _some_ client
is accessing the backend. One presumably wants to know _which_ client
is doing so (e.g. correlating the IP address of the client). Because
otherwise the client might actually be someone from juristiction that
is not friendly to you.

And yes, even with encrypted tunnel, traffic analysis can get
great amounts of data. It is just that if client hellos are replayable
and there is no tunnel, it is much easier for the attacker to
correlate connections on both sides (since attacker can then observe
new connections versus just some data exchange).



-Ilari