[TLS] Requiring SNI for HTTPS

Mark Nottingham <mnot@mnot.net> Thu, 29 May 2014 04:13 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 BE3AD1A084F for <tls@ietfa.amsl.com>; Wed, 28 May 2014 21:13:06 -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 PBSNDeWH_Ohm for <tls@ietfa.amsl.com>; Wed, 28 May 2014 21:13:04 -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 784FE1A0859 for <tls@ietf.org>; Wed, 28 May 2014 21:13:04 -0700 (PDT)
Received: from mnot-mini.mnot.net (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 128F950A73 for <tls@ietf.org>; Thu, 29 May 2014 00:12:57 -0400 (EDT)
From: Mark Nottingham <mnot@mnot.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <B9A642C0-8535-4A92-B620-68BFDD9E2296@mnot.net>
Date: Thu, 29 May 2014 14:12:54 +1000
To: TLS Mailing List <tls@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/sBBPkCeJEA8RLqV3oduCLpdwX08
Subject: [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 04:13:06 -0000

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...

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.

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/