Re: [TLS] Requiring SNI for HTTPS

Mark Nottingham <mnot@mnot.net> Thu, 29 May 2014 07:27 UTC

Return-Path: <mnot@mnot.net>
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 6FED51A0382 for <tls@ietfa.amsl.com>; Thu, 29 May 2014 00:27:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level:
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 kcDn7mX2rJlK for <tls@ietfa.amsl.com>; Thu, 29 May 2014 00:27:26 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41F2B1A01B2 for <tls@ietf.org>; Thu, 29 May 2014 00:27:26 -0700 (PDT)
Received: from [192.168.1.55] (unknown [118.209.96.192]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 26687509B5; Thu, 29 May 2014 03:27:19 -0400 (EDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <18C56F3F-180C-4515-8EF7-9C3546D401D6@gmail.com>
Date: Thu, 29 May 2014 17:27:15 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <273FB7B4-7E16-424A-8975-92C39E6D4FEB@mnot.net>
References: <B9A642C0-8535-4A92-B620-68BFDD9E2296@mnot.net> <18C56F3F-180C-4515-8EF7-9C3546D401D6@gmail.com>
To: Yoav Nir <ynir.ietf@gmail.com>
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/nhVnDw9phQnh3CmFAtKpNcrx410
Cc: TLS Mailing List <tls@ietf.org>
Subject: Re: [TLS] Requiring SNI for HTTPS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 29 May 2014 07:27:28 -0000

On 29 May 2014, at 3:14 pm, Yoav Nir <ynir.ietf@gmail.com> wrote:

> Hi Mark
> 
> On May 29, 2014, at 7:12 AM, Mark Nottingham <mnot@mnot.net> wrote:
> 
>> Hey TLS WG,
>> 
>> Recently, I migrated two of the Web sites that I host to TLS-only, using the same IP address (and thus using SNI).
>> 
>> The details are here:
>> https://www.mnot.net/blog/2014/05/09/if_you_can_read_this_youre_sniing
>> 
>> When doing so, I decided to require SNI, returning an error when it isn't presented. This seemed like the logical thing to do; after all, if the client doesn't present SNI, it might be presented with www.mnot.net's cert when the browser thinks it's going to redbot.org, and the user gets a cert error dialog. I don't want to contribute to training them to click through those…
> 
> Reading up to this, I thought that the client was sending a ClientHello without SNI, and the server was closing the connection with an alert and/or a RST.  But reading on, you talk about HTTP codes. If you’re getting to the stage where you’re sending HTTP codes to the client, you are way past any warning screens about mismatched domain names. If the user was going to click through, she’d already done so.

Right. But, if they click through and get a site, they're rewarded for clicking through, which makes it easier for them to click through next time.

As a server, my choices are roughly:

a) Serve content based upon the Host header only
b) Serve content if the Host header matches SNI information *or* the "default" cert if SNI isn't sent; otherwise serve error content
c) RST if no SNI
d) Serve error content if the user doesn't present SNI.

(a) means that a client that doesn't send SNI will possibly get cert errors and possibly click through them to be rewarded with the content they want. I don't want to do that.

(b) seems reasonable, but so far, I can't get Apache to do this reliably.

(c) is way unfriendly, and doesn't change user behaviour; it just makes them think something is wrong with the site.

(d) is the extreme approach that I've currently taken; it requires SNI and explains why to those that click through.



> Anyway, a couple of questions for your collective wisdom.
>> 
>> 1) For HTTPS, is it reasonable for rejecting SNI-less requests to be the default when the server actually uses SNI to dispatch to the correct origin? (This may be a better question for WEBSEC or elsewhere, but I thought I'd ask here first). Right now in Apache, you have to go pretty far out of your way to get this behaviour.
> 
> SNI is an extension. As of now, it’s not mandatory. It might be in TLS 1.3, but it’s not mandatory now. So what you are describing is rejecting clients that are standards compliant. That said, I don’t think you’re providing a government service with requirements for accessibility, so if you’re fine with rejecting that user with IE on XP or Safari on 10.4, it’s your choice.  It’s probably less than 15% of browsers (based on 20% being XP and IE being more popular there than on other platforms)

Yep, I went into this knowing that.

As for non-browser clients, the interesting thing that I saw was that many of the search engine spiders still don't emit SNI; the blog entry has more details.


> 
>> 2) When rejecting an SNI-less request, Apache currently generates a 403 Forbidden. However, I actually suspect that a 400 Bad Request (or a new status code) would be more appropriate, since 400 is also used when Host isn't available, and this is directly analogous. 
>> 
>> See also the Apache bug I raised about this: <https://issues.apache.org/bugzilla/show_bug.cgi?id=56508>. In particular, I don't see how sites can reasonably start requiring SNI until server-side software makes it easier to serve an error document explaining what's happening to users that don't emit it.
>> 
>> Any thoughts?
>> 
>> Cheers,
>> 
>> 
>> --
>> Mark Nottingham   https://www.mnot.net/
>> 

--
Mark Nottingham   https://www.mnot.net/