Re: [TLS] Requiring SNI for HTTPS

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