Subject: [TLS] Requiring SNI for HTTPS

From: Mark Nottingham <[email-masked]>
Date: Thu, 29 May 2014 14:12:54 +1000

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/

---

From: Yoav Nir <[email-masked]>
Date: Thu, 29 May 2014 08:14:16 +0300

Hi Mark

On May 29, 2014, at 7:12 AM, Mark Nottingham <[email-masked]> wrote:

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

> 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 el…

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)

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: David Holmes <[email-masked]>
Date: Thu, 29 May 2014 05:33:02 +0000

Do you have any visibility into what percentage of visitors are now getting blocked? Either because they don't have TLS or because they don't present SNI? Or both?

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Mark Nottingham
Sent: Wednesday, May 28, 2014 9:13 PM
To: TLS Mailing List
Subject: [TLS] Requiring SNI for HTTPS

Hey TLS WG,

The details are here:

Any thoughts?

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 29 May 2014 17:27:15 +1000

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

Right. But, if they click through and get a site, they're rewarded for clicking through, which makes it easier for them to click through next time.

As a server, my choices are roughly:

a) Serve content based upon the Host header only
b) Serve content if the Host header matches SNI information *or* the "default" cert if SNI isn't sent; otherwise serve error content
c) RST if no SNI
d) Serve error content if the user doesn't present SNI.

(a) means that a client that doesn't send SNI will possibly get cert errors and possibly click through them to be rewarded with the content they want. I don't want to do that.

(b) seems reasonable, but so far, I can't get Apache to do this reliably.

(c) is way unfriendly, and doesn't change user behaviour; it just makes them think something is wrong with the site.

(d) is the extreme approach that I've currently taken; it requires SNI and explains why to those that click through.

> 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 do…

Yep, I went into this knowing that.

As for non-browser clients, the interesting thing that I saw was that many of the search engine spiders still don't emit SNI; the blog entry has more details.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 29 May 2014 17:49:18 +1000

It'd dependent upon who's going to my (relatively small) Web sites, of course, but at the moment (~ three weeks of logs, IP/user-agent tuple identifies unique client):

* For mnot.net, about 5% of clients don't present SNI (out of ~73,000 total)
* For redbot.org, only 11% of clients *do* present SNI (out of ~46,000 total)

I think the latter is because of the nature of redbot.org; it tends to draw abusive bots :-/

No sure way to determine how many visitors can't visit because of requirements for TLS (I don't allow SSLv2 or v3,and follow the BetterCrypto.org rec's for ciphersuites), but the logs are about as bit as before...

The blog entry I mentioned lists some of the more interesting non-browser UAs that don't support SNI.

Cheers,