Re: [TLS] Requiring SNI for HTTPS

Yoav Nir <ynir.ietf@gmail.com> Thu, 29 May 2014 05:14 UTC

Return-Path: <ynir.ietf@gmail.com>
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 CD19B1A070F for <tls@ietfa.amsl.com>; Wed, 28 May 2014 22:14:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 1giLXIw005cj for <tls@ietfa.amsl.com>; Wed, 28 May 2014 22:14:25 -0700 (PDT)
Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A84FC1A0329 for <tls@ietf.org>; Wed, 28 May 2014 22:14:24 -0700 (PDT)
Received: by mail-we0-f180.google.com with SMTP id q58so3500830wes.39 for <tls@ietf.org>; Wed, 28 May 2014 22:14:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5Bav6qyfo0aA0DQewXhwu014avox558pOyhmPPoPGwQ=; b=R0jDaa06szceYNx7D4yUvfToT5uX19ZVvlWNJBhIzzExGhssxpPbjLUieoZJBbONPE 4oxrpBej7GfX+bMSrzna9j+1FhxKnZcvpf1QkkM7IQb2nbTcxNMi/eWqbREHEPrB7lMo dJwJRfOhCdUYgFfjaOWYelreLBwLSgvJ0tJYPj6PkYOPJvLEMoDl7mAjXQmrjbgCNy4W COebt1aBTWR2ED/DGjmuuwn1JMEgYGyGkZIp+OzPnN+RqZb4pAdRiwHFEpAS5gt0eiD9 x7CZz4XZeNDgniqeYoPpc/aCodiDeCuuX0Oby8T0oJqagrYDKVhPB4eYIi3oe3TwSrPN kIfA==
X-Received: by 10.194.1.242 with SMTP id 18mr6843564wjp.22.1401340459817; Wed, 28 May 2014 22:14:19 -0700 (PDT)
Received: from [192.168.1.102] (bzq-84-109-50-18.red.bezeqint.net. [84.109.50.18]) by mx.google.com with ESMTPSA id vm8sm48752234wjc.27.2014.05.28.22.14.18 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 May 2014 22:14:19 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <B9A642C0-8535-4A92-B620-68BFDD9E2296@mnot.net>
Date: Thu, 29 May 2014 08:14:16 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <18C56F3F-180C-4515-8EF7-9C3546D401D6@gmail.com>
References: <B9A642C0-8535-4A92-B620-68BFDD9E2296@mnot.net>
To: Mark Nottingham <mnot@mnot.net>
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/w43zP_SO6_djbi47fSFHoqT0AWs
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 05:14:27 -0000

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.

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

> 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/
> 
> 
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls