Unfortunately for our ecommerce site this just isn't the at all an option. 3 months ago we analysed our traffic and found that 12% of our desktop traffic didn't support it (Win XP) and about 8% of our mobile traffic didn't support it (Android older than 4.0). I'm not losing 10% of my revenue just so I don't need to get a couple extra IPs from AWS. And even better, AWS doesn't actually charge me for the IPs. Once IPs are priced in line with their scarcity, I'll start caring. Today when I can get them for free? Not worth it.

If you're having to support devices that old then I'd be more worried about how you're going to take payment details on your e-commerce website over a "secure" connection that would fail most PCI DSS vulnerability scans.

The security of TLS has come a long long way since XP and so has research into breaking XP-era ciphers.

Deprecation of old stuff is going incredibly slowly even in rich countries (to the intense frustration of a lot of security teams). Check out the incredible true story, told over years on cabfpub, of the attempt to get rid of SHA-1 in TLS authentication. Notably, the attacks that led to experts' recommendation to move away from SHA-1 immediately were published back in 2005. Meanwhile, Microsoft's "effective date of the SHA-1 deprecation" is tomorrow (!), February 14, 2017.

https://social.technet.microsoft.com/wiki/contents/articles/...

(Let's have a party!)

Figuring out how people are going to get upgraded when problems of some sort are discovered (including software vulnerabilities, not just cryptographic protocol issues) is a major security challenge of our day, maybe the biggest information security problem overall in the world.

Hang on. What percent is XP, and what percent is IE on XP? Those are not numbers that should be conflated.

The vast majority of our users still on XP use IE. To the point that we conflate the numbers entirely. Most of those users are 50 year old women who have leftover computers handed down from relatives. They almost as a rule, don't install Chrome or Firefox on them, they just use what is currently on it.

(author here) I would have loved to have SNI work. I wrote this article in response to having profound struggles making it work. My iPhone 7's Safari was routinely failing to connect to sites other browsers claimed were fine, when relying on SNI.

The day i swapped over to IP-based connections, the problem resolved itself immediately. If there is something i am missing i would love to know what it is.

It must have been something else. Even Safari on iOS has supported SNI since iOS 4.0 (2010).

The only thing I've had SNI fail under (so far) had been Netscape Navigator 3.0 and at that point, does it really matter?

IE on Win XP. Or at least anything using the built in crypto stuff. I think firefox will still use it's own. Not sure about chrome.

You might be talking about HTTP 1.1 Host header which allows vhosts for plaintext HTTP servers. SNI allows this to happen with TLS (HTTPS, etc.) servers.

You might be able to get useful debugging information with tcpdump or wireshark because SNI itself is sent in the clear (prior to the TLS cryptographic key exchange). You could see if the server is doing something different from other servers, or the browser is doing something different from other browsers.

I have been using precisely Nginx to serve multiple HTTPS domains with certificates from Let's Encrypt since the first few weeks after it came out, so I am not sure why you think it's strictly necessary to assign them separate IP addresses. Generally speaking, there is nothing wrong with that, and it is indeed a somewhat cleaner solution, but it is definitely doable with SNI if one configures their web server appropriately.

Check out the IMHO best TLS SNI test website out there (https://sni.velox.ch/) and the Qualys SSL Labs server test (https://www.ssllabs.com/ssltest/). They may give you a staring point to find out what exactly went wrong with SNI. And the documentation of Nginx, of course.

Can you get to https://sni.velox.ch/ from your phone? What are the first few lines?

In particular, I'm curious if this is a misconfiguration on the server end, or a misconfiguration on the client end. Certain VPNs or malware can break SNI.

Never had any SNI issues with Safari. Could it be the mobile network provider (which tends to insert things like NATed IPv6 that can cause weirdness), or did it also fail over wifi?

older version of wget and Java also doesn't support SNI, for example used in API https callbacks, or Android apps. One trick I use it to load that site (or the most important) first in nginx, because those that doesn't support SNI will use that certificate.

Another option, if you don't need encryption, is to allow http.

Could you be having issues with ipv6?

Plenty of reason to not use SNI. First off - not everything is a web browser. While browser support for SNI is pretty good these days, other clients are far behind. That random app that connects to your web API has to also support SNI, which means some old PHP library somewhere has to as well. Good luck.

That and a surprising number of "regular" clients still seem to have issues with SNI. My numbers are quite dated, but even as recent as 3 years ago it was something like dropping 10% of traffic for a high traffic site I did A/B testing with. I'm guessing the number was even higher, but the client requested we immediately stop the test once it became apparent it was a major reachability issue affecting revenue.

That is if you don't care about supporting windows xp users, I certainly don't.

And it's not just XP, it's IE on XP, meaning IE 8 or older. SNI works on the most recent Firefox & Chrome for XP.

There's enough IPv6