IETF Logo Mail Archive

Re: [TLS] "Encrypted" SNI

Christian Huitema <huitema@huitema.net> Wed, 10 May 2017 21:51 UTC

Return-Path: <huitema@huitema.net>
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 EAE631292CE for <tls@ietfa.amsl.com>; Wed, 10 May 2017 14:51:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.099
X-Spam-Level:
X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 R92tBTsef5E7 for <tls@ietfa.amsl.com>; Wed, 10 May 2017 14:51:05 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FA4E1292C5 for <tls@ietf.org>; Wed, 10 May 2017 14:51:05 -0700 (PDT)
Received: from xsmtp24.mail2web.com ([168.144.250.190] helo=xsmtp04.mail2web.com) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from <huitema@huitema.net>) id 1d8ZVe-0006Ye-Ol for tls@ietf.org; Wed, 10 May 2017 23:51:03 +0200
Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1d8ZVZ-0006vf-Iw for tls@ietf.org; Wed, 10 May 2017 17:50:58 -0400
Received: (qmail 17763 invoked from network); 10 May 2017 21:50:51 -0000
Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.151.78]) (envelope-sender <huitema@huitema.net>) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for <tls@ietf.org>; 10 May 2017 21:50:51 -0000
To: Roland Zink <roland@zinks.de>, tls@ietf.org
References: <3768598.32hupQ9b2b@pintsize.usersys.redhat.com> <a6029246-46f6-d698-983f-b668d70e2780@zinks.de>
From: Christian Huitema <huitema@huitema.net>
Message-ID: <1be2b15e-2e96-89f4-fe72-7f35a03ae99b@huitema.net>
Date: Wed, 10 May 2017 14:50:50 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <a6029246-46f6-d698-983f-b668d70e2780@zinks.de>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: 168.144.250.190
X-SpamExperts-Domain: xsmtpout.mail2web.com
X-SpamExperts-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-SpamExperts-Outgoing-Class: unsure
X-SpamExperts-Outgoing-Evidence: Combined (0.16)
X-Recommended-Action: accept
X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49Nd7AN7sevoJn7jQtAGeOfdTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXpsm1bsvpS6/5av0CXYg4TrRcOb18WfxGyg6Om6u4YYm4Rd89++QihjXUN6 t2+7VS45hjoyEb9Oq0NWpyO3vrfYvxyiiU8VkSVtodr6VFoM0T3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSBCDRZgQnFYkq0SOLrmvxpF3TFgIfDMShmlQFqCr5hA8xAXSGwpLGc/Znuh3MoIpK0TQjVng+I 4j5NH+PNTw0CHLbRF0J+AL6gRRwFcty0/RGJ+cv73CChOPjKA0/DVd83mzKXD5o/Ia+BqyQ7Q0nt IZ2PVtMHd8bHCmdzlxzVIEgwyGTHIAoNFX+jcW7DGmdE6eBVl9/A6GtGi+mfMSANmgQ9/T0zHbtC pLbhgZ6Z/Qhqxiuap5uKiBpffUsHYsfmrbtbs8GJuRKR6hnrta1usy6F/SOWlhnS7qkS/mOkSgD5 8bDUIriOSOQTK7vaz2jBsjp0rjSY76LAIHA6cW4Oa67s2SuN2OBHS35xAp92lJI/So36ili1tgrL sQ8JMBxgxdwDV/LdQk4Dnvnv/o4ZpIN8Tfe43vaXKX/yihCEqxIlRZaHuAWSnHeK3PdSA6Q+2n/k rhIYlNMbfS0wdTtG+6JGvz6FazW2uq9LM3++XT4UhuDAoR32cV4eNY9hrm4n
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/PxDE05WxL2ixMPuvOAfmjL-TTTc>
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: Wed, 10 May 2017 21:51:07 -0000


On 5/10/2017 2:40 PM, Roland Zink wrote:
> The SNI extension is optional, so you don't have to send the literal
> value. Indeed quite some number of apps do not send it. Browsers
> currently can't know if the SNI is required by the origin servers and
> usually send this, but there could be some signal to not send it. One
> example could be a HTTP header to tell the browser that SNI should be
> send and if it isn't present then no SNI is send. Unfortunately this
> would break current sites but still it can be done the other way
> around e.g. send a header to not send SNI.

Yes. But this is only possible when each service has a separate IP
address. The privacy gain occurs precisely when several services share
the same address, but that's exactly when the SNI is required. If the
SNI was somehow encrypted, adversaries would not be able to use it to
find which service the user is connecting to.

-- Christian Huitema

v2.23.0 | Report a Bug | By Email