W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2016

RE: SNI vs Host: and a trailing dot

From: Mike Bishop <Michael.Bishop@microsoft.com>
Date: Wed, 16 Mar 2016 23:27:25 +0000
To: Mark Nottingham <mnot@mnot.net>, Daniel Stenberg <daniel@haxx.se>
CC: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <BL2PR03MB1905FF4E739AA23B28ED6473878A0@BL2PR03MB1905.namprd03.prod.outlook.com>
In fairness, RFC 6066 also says "If the server_name is established in the TLS session handshake, the client SHOULD NOT attempt to request a different server name at the application layer." HTTP.sys prior to Windows 10/Server 2016 enforced this by refusing (400) requests for other server names.

I'm not sure what our behavior is down level if the difference between the two is only a trailing dot. I'll ask.

-----Original Message-----
From: Mark Nottingham [mailto:mnot@mnot.net] 
Sent: Wednesday, March 16, 2016 4:02 PM
To: Daniel Stenberg <daniel@haxx.se>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: SNI vs Host: and a trailing dot

> On 16 Mar 2016, at 10:17 PM, Daniel Stenberg <daniel@haxx.se> wrote:
> Heya HTTP peeps!
> Input "HTTPS://example.com./". A URI using a hostname with a trailing dot. How to behave?
> 1. RFC 6066 section 3 says the hostname in SNI string should be sent "without a trailing dot"
> 2. RFC 7230 secion 5.4 says about Host: "MUST send a field-value for Host that is identical to that authority component" - which then would include the trailing dot.
> Following these specs, we should send different names in SNI vs Host when a trailing dot is used. I don't like that as I suspect HTTPS servers will use the SNI field to serve contents

They shouldn't be doing that (if indeed they do); SNI is only for selecting the certificate, not anything to do with what happens inside HTTP.


Mark Nottingham   https://www.mnot.net/
Received on Wednesday, 16 March 2016 23:27:55 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 22 March 2016 12:47:11 UTC