Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
mrex@sap.com (Martin Rex) Wed, 13 November 2013 00:29 UTC
Return-Path: <mrex@sap.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 B3AB521E8122 for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 16:29:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.035
X-Spam-Level:
X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
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 H4DvQ5cJY+kr for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 16:29:25 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 2B68A21E80F8 for <tls@ietf.org>; Tue, 12 Nov 2013 16:29:25 -0800 (PST)
Received: from mail06.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id rAD0TNX3006685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 13 Nov 2013 01:29:23 +0100 (MET)
In-Reply-To: <5EA9A50C-4AD0-43F6-B11D-2967C8CC0333@iki.fi>
To: Juho Vähä-Herttua <juhovh@iki.fi>
Date: Wed, 13 Nov 2013 01:29:23 +0100
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="ISO-8859-1"
Message-Id: <20131113002923.829C71AA84@ld9781.wdf.sap.corp>
From: mrex@sap.com
X-SAP: out
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
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, 13 Nov 2013 00:29:29 -0000
Juho Vähä-Herttua wrote: > > 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. The number of servers that require SNI seems to be somewhere between marginal and negligible. SChannel in Windows XP doesn't support SNI, and the global market share of Windows XP is still significant: http://www.netmarketshare.com/operating-system-market-share.aspx?qprid=10&qpcustomd=0 (and may be the reason why MSIE 8 is still the most common version in use) Sometimes, IT departments even deploy Windows 7 in a fashion that even Win7 MSIE/SChannel will not send SNI. I'm sure they would be swamped with support calls if that would cause noticable usability issues. > > > 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. There are currently two other activities in the IETF with respect to the server certificate: DANE, where the Server cert (hash) ends up in DNS(SEC), and Certificate Transparency, where the Server's certificate ends up on a signed public record. And what about the Server certificate revocation checking through OCSP? I assume that the primary reason for the NSA/GCHQ and spooky friends to "collect it all" is the prevalent lack of "crypto hygiene" in pretty much all network protocols and in common user behaviour, except for some stuff that is run entirely through TOR. You're leaking the information, that you're trying to hide here with great effort, in so many other places, that they're going to laugh at you. They may not be able to (or not care for) connecting the dots between terrorist plots, but they likely can and do connect the dots between IP addresses and hostnames of servers for stuff that doesn't go through TOR. -Martin
- Re: [TLS] Final nail in the coffin for cleartext … Martin Rex
- Re: [TLS] Final nail in the coffin for cleartext … Martin Rex
- [TLS] Final nail in the coffin for cleartext SNI/… Ralf Skyper Kaiser
- Re: [TLS] Final nail in the coffin for cleartext … Watson Ladd
- Re: [TLS] Final nail in the coffin for cleartext … Ralf Skyper Kaiser
- Re: [TLS] Final nail in the coffin for cleartext … Yoav Nir
- Re: [TLS] Final nail in the coffin for cleartext … Salz, Rich
- Re: [TLS] Final nail in the coffin for cleartext … Ryan Hurst
- Re: [TLS] Final nail in the coffin for cleartext … Martin Rex
- Re: [TLS] Final nail in the coffin for cleartext … Daniel Kahn Gillmor
- Re: [TLS] Final nail in the coffin for cleartext … Ralf Skyper Kaiser
- Re: [TLS] Final nail in the coffin for cleartext … Yoav Nir
- Re: [TLS] Final nail in the coffin for cleartext … Yoav Nir
- Re: [TLS] Final nail in the coffin for cleartext … Seth David Schoen
- Re: [TLS] Final nail in the coffin for cleartext … Ralf Skyper Kaiser
- Re: [TLS] Final nail in the coffin for cleartext … Watson Ladd
- Re: [TLS] Final nail in the coffin for cleartext … Salz, Rich
- Re: [TLS] Final nail in the coffin for cleartext … Yoav Nir
- Re: [TLS] Final nail in the coffin for cleartext … Martin Rex
- Re: [TLS] Final nail in the coffin for cleartext … Ralf Skyper Kaiser
- Re: [TLS] Final nail in the coffin for cleartext … Michael D'Errico
- Re: [TLS] Final nail in the coffin for cleartext … Jacob Appelbaum
- Re: [TLS] Final nail in the coffin for cleartext … Ralf Skyper Kaiser
- Re: [TLS] Final nail in the coffin for cleartext … Michael D'Errico
- Re: [TLS] Final nail in the coffin for cleartext … Ralf Skyper Kaiser
- Re: [TLS] Final nail in the coffin for cleartext … Martin Rex
- Re: [TLS] Final nail in the coffin for cleartext … Sean Leonard
- Re: [TLS] Final nail in the coffin for cleartext … Ralf Skyper Kaiser
- Re: [TLS] Final nail in the coffin for cleartext … Juho Vähä-Herttua
- Re: [TLS] Final nail in the coffin for cleartext … Yoav Nir
- Re: [TLS] Final nail in the coffin for cleartext … Ralf Skyper Kaiser
- Re: [TLS] Final nail in the coffin for cleartext … Phillip Hallam-Baker
- Re: [TLS] Final nail in the coffin for cleartext … Daniel Kahn Gillmor
- Re: [TLS] Final nail in the coffin for cleartext … Ralf Skyper Kaiser
- Re: [TLS] Final nail in the coffin for cleartext … Martin Rex
- Re: [TLS] Final nail in the coffin for cleartext … Daniel Kahn Gillmor
- Re: [TLS] Final nail in the coffin for cleartext … Juho Vähä-Herttua
- Re: [TLS] Final nail in the coffin for cleartext … Ralf Skyper Kaiser
- Re: [TLS] Final nail in the coffin for cleartext … Yoav Nir
- Re: [TLS] Final nail in the coffin for cleartext … Martin Rex
- Re: [TLS] Final nail in the coffin for cleartext … Martin Rex
- Re: [TLS] Final nail in the coffin for cleartext … Ralf Skyper Kaiser
- Re: [TLS] Final nail in the coffin for cleartext … Bodo Moeller
- Re: [TLS] Final nail in the coffin for cleartext … Marsh Ray
- Re: [TLS] Final nail in the coffin for cleartext … Ralf Skyper Kaiser
- Re: [TLS] Final nail in the coffin for cleartext … Geoffrey Keating