Re: [TLS] About encrypting SNI - Traffic Analysis Attacks?

mrex@sap.com (Martin Rex) Wed, 14 May 2014 02:20 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51FBD1A01F9 for <tls@ietfa.amsl.com>; Tue, 13 May 2014 19:20:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.653
X-Spam-Level:
X-Spam-Status: No, score=-4.653 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 iPTLaNhLkM4L for <tls@ietfa.amsl.com>; Tue, 13 May 2014 19:20:21 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id F00491A01E8 for <tls@ietf.org>; Tue, 13 May 2014 19:20:20 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s4E2K7Q4003488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 May 2014 04:20:07 +0200 (MEST)
In-Reply-To: <53728B78.30306@cs.tcd.ie>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Date: Wed, 14 May 2014 04:20:07 +0200
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20140514022007.5C7FD1AD07@ld9781.wdf.sap.corp>
From: mrex@sap.com
X-SAP: out
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/GYk94oKRVttAA3ZhWfn8xC7UNYE
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] About encrypting SNI - Traffic Analysis Attacks?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
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: <http://www.ietf.org/mail-archive/web/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: Wed, 14 May 2014 02:20:23 -0000

Stephen Farrell wrote:
> 
> One other thought, maybe more optimistic: could it be that
> there might be ways to protect things like SNI used for
> routing the 2nd and later times you visit a web site, even
> if TLS had to put the DNS name in clear (or close-to) first
> time around?

The latter looks like a contradiction to SNI being used for routing
to me.  When SNI is used for routing, then it MUST be present
on the initial ClientHello on every new connection, or routing
(to other than the default credential) will be impossible.
It doesn't really matter whether that routing is physical
(to a different backend server) or just logical (to a different
server credential on the same host.

The session_id that is normally used for the abbreviated handshake
is no suitable substitute here.  These sessions may expire quickly
and randomly (like depending on server load and cache contention),
within a few minutes, and the session cache is not necessarily
shared among TLS clients or among TLS servers involved in the
communication.

E.g. a while ago I observed an unfavorable behaviour of a browser on
a platform after an OS minor version upgrade with respect to browser
plugins.  The OS upgrade seems to have seperated the browser's TLS session
cache from the TLS session cache used by the plugins, and the plugins
were not prepared to do their own promptin "server cert warning--do you want
to continue anyway",  but instead just silently failed (resulting in
a blank/white area where the plugin should have rendered the contents).


Hiding the server hostname by encrypting SNI looks extremely silly for
anything that operates like a web browser.  Those beasts spill
HTTP-Referers all over the place, keep bookmarks, keep histories,
keep cookies and do lots of other stuff to spread hostnames from URLs
all over the place.

The hostname horse has left the barn 25 years ago.  Closing the barn
door today is going to be futile.  IF you have anything to hide,
then you MUST ensure, that it is not vitally dependend on the
hostname of the server remaining secret.


I do not believe that it would be a good idea to create the
provably false impression that TLS is a panacea and hiding of SNI
would provide any security or any privacy benefit vaguely similar
to characteristics that TOR tries to provide -- because it doesn't,
and can't.



-Martin