Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3

Juho Vähä-Herttua <juhovh@iki.fi> Tue, 12 November 2013 19:57 UTC

Return-Path: <juhovh@iki.fi>
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 BF10B21F9F21 for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 11:57:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.903
X-Spam-Level:
X-Spam-Status: No, score=-0.903 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8nrMItv6dcXm for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 11:57:18 -0800 (PST)
Received: from smtp.surffi.net (stardust.surffi.net [82.116.225.142]) by ietfa.amsl.com (Postfix) with ESMTP id 0B38021F9EED for <tls@ietf.org>; Tue, 12 Nov 2013 11:57:17 -0800 (PST)
Received: from mail.visino.fi (N243-201.surffi.net [80.247.243.201]) by smtp.surffi.net (Postfix) with ESMTP id 336495A1FC; Tue, 12 Nov 2013 21:58:49 +0200 (EET)
Received: from [192.168.1.149] (N248-45.surffi.net [80.247.248.45]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: juhovh) by mail.visino.fi (Postfix) with ESMTPSA id 6B0513FA3B; Tue, 12 Nov 2013 21:57:15 +0200 (EET)
References: <20131112183359.34A6C1AA80@ld9781.wdf.sap.corp>
Mime-Version: 1.0 (1.0)
In-Reply-To: <20131112183359.34A6C1AA80@ld9781.wdf.sap.corp>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <5EA9A50C-4AD0-43F6-B11D-2967C8CC0333@iki.fi>
X-Mailer: iPhone Mail (11B511)
From: Juho Vähä-Herttua <juhovh@iki.fi>
Date: Tue, 12 Nov 2013 21:57:04 +0200
To: "mrex@sap.com" <mrex@sap.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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: <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: Tue, 12 Nov 2013 19:57:25 -0000

> On 12.11.2013, at 20.33, mrex@sap.com (Martin Rex) wrote:
> 
> Juho Vähä-Herttua wrote:
>> 
>> What makes me sad is
>> the knowledge that SNI is leaking the hostname and makes those
>> connections trivial to block, even though I haven't come across
>> SNI based blocking yet.
> 
> There is _no_ requirement for the TLS client to send SNI at all.

Of course not, but many servers require it in practice.

> In the normal mode of operation of TLS, the server name that the client
> announces through SNI is the name that the client will match against
> the server's certificate.  So blocking based on the names in the
> server's certificate would work for current SSLv3->TLSv1.2, even
> when the client does not send SNI.

That is true, I assumed if there's a common shared secret for encrypting SNI in place, it could also be used for encrypting the certificate.

> One of the problems with making a "solution" part of the official
> standard is that, if anything, the tools in use by the relevant authorities
> will be able to deal with the "standard" at the time when it becomes usable
> in the installed base (if that happens at all).

I guess the question is about how transparently they can do that. If a TLS handshake fails halfway is a bit different than failing after ClientHello. Failing after ClientHello can be interpreted as server simply not accepting the parameters.

> Homegrown/unofficial workarounds tend to work better and longer.

Naturally, but it's not impossible to make official protocols secure enough to at least detect eavesdropping, even if it would be impossible to prevent.

However, I don't see how encrypting SNI and certificate would be possible without an extra round-trip, and that might be too expensive even considering the benefits. The current 4-way handshake combined with 3-way handshake of TCP is already a bit much. So I'm not completely supporting the encryption, even though it would be a really nice option if it was widely supported.


Juho