[TLS] Requiring SNI for HTTPS

[Mark Nottingham <[e-mail]>]

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/