

Simple solution to host multiple HTTPS sites on the same cloud server - comice
http://brightbox.com/blog/2012/04/18/port-translation/

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

~~~
dspillett
_> 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.

~~~
moe
_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.

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

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

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

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

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

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

~~~
comice
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!

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

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

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

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

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

~~~
comice
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 :)

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

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

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

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

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

~~~
mobiplayer
OK, downvote reality.

