IETF Logo Mail Archive

Re: [TLS] Encrypted SNI

Toerless Eckert <tte@cs.fau.de> Fri, 02 June 2017 10:31 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
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 520D4129503; Fri, 2 Jun 2017 03:31:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] 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 2oxjp29sQJH5; Fri, 2 Jun 2017 03:31:56 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E727012EB0F; Fri, 2 Jun 2017 03:31:55 -0700 (PDT)
Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id B8C9758C4B0; Fri, 2 Jun 2017 12:31:51 +0200 (CEST)
Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id A3757B0C18F; Fri, 2 Jun 2017 12:31:51 +0200 (CEST)
Date: Fri, 02 Jun 2017 12:31:51 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Richard Barnes <rlb@ipv.sx>
Cc: "<tls@ietf.org>" <tls@ietf.org>, Benoit Claise <bclaise@cisco.com>, "ops-dir@ietf.org" <ops-dir@ietf.org>, "ops-ads@ietf.org" <ops-ads@ietf.org>, "sec-ads@ietf.org" <sec-ads@ietf.org>, ops-chairs@ietf.org
Message-ID: <20170602103151.GC12522@faui40p.informatik.uni-erlangen.de>
References: <CAHbuEH4Bwr13T-cBFvLmUmn6KRzuNf1su6VTeJguyssk6S2z3g@mail.gmail.com> <4d2f195a-c61b-4abb-9b33-bc36773775cd@cisco.com> <20170602084300.GB12522@faui40p.informatik.uni-erlangen.de> <CAL02cgS+eym_=TNupJo0f0qAFgZc14rXNfO=VdGzRX28jXVqkQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAL02cgS+eym_=TNupJo0f0qAFgZc14rXNfO=VdGzRX28jXVqkQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/4dHhELlb9ritMMtokplMO-shq9I>
Subject: Re: [TLS] Encrypted SNI
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 02 Jun 2017 10:31:58 -0000

On Fri, Jun 02, 2017 at 01:16:01PM +0300, Richard Barnes wrote:
> Operators trying to do this by inspecting TLS (and not decrypting) are
> going to have a bad time anyway.  With HTTP/2 connection coalescing, even
> if they can see the certificate, the actual HTTP request could be for any
> name in the certificate.  So there's nothing really gained by exposing the
> certificate.

If a web service hoster does not provide any useful demultiplexer then it can of course not
expect not to get blacklisted across services. Is it not already common practice to assign
separate certificates to separate "web customers" ?

--Toerless

> --Richard
> 
> 
> 
> > As soon as the IP address used to host a web-service runs
> > multiple web-services (domain-names), this is today done by inspecting the
> > TLS 1.2 server certificate
> > or SNI.
> >
> > Web hosters whose services do share IP addresses across domain name should
> > be very interested to
> > ensure such inspection works, because else a single misbehaving
> > web-service they host will easily
> > cause all their web-services to be blacklisted by any of the varied
> > organizations that create
> > blacklists: because blacklisting can then only be applied on a per-IP
> > address.
> >
> > Of course, IPv6 could make this need somewhat obsolete because there
> > should be no reason to
> > share IPv6 addresses across domain-names, but i am not aware what todays
> > common practice are with IPv6
> > in this respect.
> >
> > Cheers
> >     Toerless
> >
> > On Thu, Jun 01, 2017 at 04:38:46PM +0200, Benoit Claise wrote:
> > > Dear all,
> > >
> > > You should be aware that the TLS list is debating encrypting SNI so
> > > that the host name cannot be seen from TLS sessions.
> > > https://www.ietf.org/mail-archive/web/tls/current/msg23251.htm
> > >
> > > If you're aware of valid (valid in the IETF-sense) operational
> > > practices that require the host name visible, we should enter the
> > > debate.
> > >
> > > Regards, Benoit
> >
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> >

-- 
---
tte@cs.fau.de

v2.23.0 | Report a Bug | By Email