Simple solution to host multiple HTTPS sites on the same cloud server | Hacker News Reader

Simple solution to host multiple HTTPS sites on the same cloud server

brightbox.com

44 pointscomice29 comments

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.

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!

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

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.

This is somewhat of an artificial problem caused by how popular cloud server providers (e.g. EC2 and Brightbox) have chosen to implement their networking. There's no inherent problem with cloud servers. For example, Linode lets you have many public IP addresses associated with a server, just like a traditional server. But it also lets you move IP addresses around between servers in the same data center, so you still have the convenience of the cloud.

NAT-style floating IPs have other benefits though. Putting multiple IPs on a cloud server is a mistake imo (it makes them less cloud-like :) - it's not usually needed, and you lose the benefits of having the IPs at a different layer.

VirtualHosts on the same Apache setup can run different HTTPs certs as long as each host is listening on a separate IP address. So for at least some people facing this problem, the simplest solution may be upgrading to a standalone server with 5-10 assigned IP addresses.

Back in my teenage years I worked at Bluehost and they did this exact thing for their shared hosting platform. It was simple and worked well.

That's a nice solution, but it's specific to their platform. The title made me hope for a platform-abstract solution.

The same concept could be added to any "floating" IP style platform though, like Openstack or Amazon EC2. Shouldn't be hard to add it to Openstack at any rate!

But why would you? Normally a server can differentiate the src interface and dst ip.

because NAT-style floating IPs have many benefits. See my other comments for details!

>You can map multiple Cloud IPs to the same Cloud Server, but the server cannot differentiate between connections made to different Cloud IPs.

This may be the case for Brightbox, but in general a server can differentiate between connections to different IP's. This is how multiple SSL certificates have been supported on one server since forever.

It's the case for many "floating ip" style systems, like EC2 and Openstack too.

NAT-based floating IP style systems have some great benefits, in particular that the cloud server itself doesn't need to know anything about them. So you can move Cloud IPs between them without changing any configs, or doing anything particularly special on the servers themselves.

Adding multiple IPs to a cloud server adds quite a bit of complexity - makes it harder to just move the floating IPs between servers (because you have to maintain a mapping to each IP, which is different on each server) and it makes configuring the web server more complex too (because the IPs will be different on each server).

In the majority of use cases I've seen, you don't actually need multiple IP addresses on the same cloud server, so it's overkill to support them when port translation can solve the most common problem so neatly.

While a neat solution, I feel this is going the wrong way with things. One of the primary reasons to use the cloud is to get away from SPoF. This solution is simply putting lots of sites on a single instance, which is fine, but how does the port translation work across multiple instances? We ran into this problem recently while architecting a solution for our customers and we ended up using multiple ELB's to point to multiple EC2 instances. Sure at $20/mo its probably a slightly more expensive route, but it solved all the benefits of what is being promoted here. For those that don't realize ELB's can act as SSL endpoints. I believe RackSpace allows a similar such thing. It also means that no complex port/ssl configuration occurs on the web servers, they are actually much easier to deal.

Unlike Elastic IPs, Brightbox Cloud IPs can be mapped directly to load balancers, so you can avoid the SPoF that way (load balancers are highly-available, across zones): http://brightbox.com/#load_balancers

But we also have some other upcoming features for Cloud IPs that address this in another way :)

Ah, that is certainly helpful. I didn't realize that.

The SaaS application that I am building will have multiple customers pointing to a load-balancer(still deciding EBS vs other options) and I am still figuring out how to get the ssl part of it set up. I like your point on keeping ELBs as the SSL end point. I haven't been able to find a definite resource explaining this. Is there anything that can be shared?

The AWS documentation does a good job explaining the setup. As for multiple ELB's mapping to the same instances, I don't know if this is actually documented, it is just kinda known. It use to require configuration via API/CLI, but appears that the web console now even lets you do it.

http://docs.amazonwebservices.com/ElasticLoadBalancing/lates...

This is no rocket science, I've implemented it years ago on an EC2 cloud managed with Scalarium. I'd expect any self respecting sysadmin to come up with such a solution.

Be interested to know how you did this tbh. Pretty sure EC2 doesn't let you map multiple elastic IPs to an instance afaik?

I've also done something similar on EC2, with two different load balancers both forwarding to the same instance, but to different ports. Of course then you could also just handle the SSL on the ELB level, but sometimes it's handy to pass it all the way to your web servers.

I concur, how is this even HN worthy... Sysadmins and developers have been doing this for years and years

And why this is considered new or even relevant? Network admins have been doing this (and other approaches) for years.

OK, downvote reality.

Reply on news.ycombinator.com