Hacker News Reader

Comment by jgrahamc | Hacker News Reader

All this is doing is having multiple IP addresses for that server. The fact that it's done through port translation is mostly irrelevant. It isn't getting round the fundamental problem that without SNI (which is out because of WinXP) there's still a one IP address/one host:port restriction.

View on HN

> without SNI (which is out because of WinXP)

More specifically: IE on XP. IIRC Firefox and Chrome support SNI when running on XP and I would guess Opera does too.

Obviously you would still risk alienating some of your market, but if "try another browser" won't offend that part of your target audience that use XP+IE too much you could consider SNI. Unfortunately if a significant part of your market is corporate users this simply isn't an option and won't be for a while as many of them are locked to XP+IE by their IT setup.

More specifically: IE on XP.

No, SNI is fully broken on all platforms. I tried it for a while, save yourself the headache.

It fails intermittently on all browsers (including latest Firefox and chrome) under various conditions. These failures usually manifest as "Certificate does not match"-warnings for the user.

I have not fully understood all scenarios, but a few seem to be: Keep-alive connection to vhost A, then browser tries connection to vhost B. Loadbalancer doing funny things. Intermediate proxies doing funny things. General implementation bugs (I've seen the cert-warning even on a freshly booted chrome for no obvious reason).

And let's not get started on mobile browers... (hint: the built-in browser may actually seem fine but the http-library in your app still fails intermittently, older androids [widely deployed] have no SNI support at all)

Do yourself a favor and either switch to a wildcard cert or stick with separate IPs.

I've not implemented SNI myself yet as a chunk of our clients fall in the "stoneage" category, running XP+IE8 or in at least one case XP+IE6.

I'll take your warnings as things to thoroughly test if I ever need to try implement it.

You are right in noting that mobile platforms apparently don't support it well at all.

Really IPv6 is the answer, but for out clients at least that is even more "future magic" then running a decent browser...

Yes, but it does it without actually needing to configure additional IPs on that server. Which means your cloud servers can be identically configured, which means you can move Cloud IPs between them with ease, and you can clone them with ease.

Basically, putting multiple IPs on cloud servers negates the flexibility of floating IPs. Special configuration on cloud servers should be kept to a minimum imo!

It's not just IE/XP which is the problem, library support for SNI is still pretty poor, which is an issue if you're running REST services.

SNI is backwards compatible with sites that are not using it, so this is really an asymmetric problem.

If you are writing your REST service with a library that doesn't support SNI then you just fall back to the old one SSL certificate per IP:port. When a browser comes in presenting the SNI option it just gets ignored and life goes on.

I think you've got the point I was trying to make the wrong way round. If I set up half a dozen REST services with SSL on a single IP, clients which don't support SNI will experience problems. Last time I checked, libwww in Perl, urllib in Python (until 3.2) and the WebClient library in C# all didn't support SNI.

Reply on news.ycombinator.com