RE: SNI vs Host: and a trailing dot

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.

Cheers,

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

Received on Wednesday, 16 March 2016 23:27:55 UTC