Subject: Apache SSL redundancy

From: "Yu, Ming" <[email-masked]>
Date: Thu, 24 Jan 2002 17:34:45 -0500

Does anyone have information about how to build redundant apache web site
with SSL?

Thanks 

- Ming Yu

______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl)                   www.modssl.org
User Support Mailing List                      [email-masked]
Automated List Manager                            [email-masked]

---

From: Thierry Coopman <[email-masked]>
Date: Fri, 25 Jan 2002 14:41:46 +0100

Hi,

I'm trying to do this. The main problem is HTTPS session IDs I guess. This
makes load-balancing a bit more complicated since you need to forward every
request to the same server that has the sessionID. This is doable with Linux
LVS, your firewall or with HW load-balancing kit.

Now, what ahppens on a failure?
- The server(s) that still exist can take over the ip address of the failing
server
- The LoadBalancing system detects it and doesn't use the machine any more.

On the SSL side, since the server that fails over doesn't have the SSL
session, the browser connecting to it fails to communicate.

I'm not sure if it is safe to use the same cert for every machine, or that
it is a requirement to have the same cert on every machine.

Verisign requires you to ask for a different certificate for every server
(with a different OU) in a cluster. (I think this is just a commercial
reason, not a technical reason, but I'm not sure)

It is possible to sync the session cache over different hosts with things
like Splash <http://anoncvs.aldigital.co.uk/splash/> but I haven't found an
implementation with mod_ssl (only Apache-SSL)

I would be gratefull if someone has a clean solution or if there is someone
with experience on trying to accomplish this.

---

From: Jeffrey Burgoyne <[email-masked]>
Date: Fri, 25 Jan 2002 08:48:03 -0500 (EST)

A more expensive solution would be using a hardware based SSL switch up
front like the Nortel Alteon series.

Jeff

---

From: Mads Toftum <[email-masked]>
Date: Fri, 25 Jan 2002 15:05:21 +0100

> LVS, your firewall or with HW load-balancing kit.
Well, RR DNS would also be an option as a low cost solution. Either way you
should be more or less ok, because most load balancers will direct one client
to the same server as long as that server is up. Anyway, most browsers will
end an SSL session after a couple of minutes (MSIE)

> session, the browser connecting to it fails to communicate.
That shouldn't be the case - if the session is either unavailable or has
expired on the server side, then the server and client will just negotiate
a new session.

> it is a requirement to have the same cert on every machine.
The only way it would be unsafe is because it is on more servers.

> reason, not a technical reason, but I'm not sure)
Not technical reason whatsoever.

> implementation with mod_ssl (only Apache-SSL)
IIRC mod_ssl has vendor hooks for the session cache, which should make reusing
Splash fairly simple (I haven't looked at Splash for a long time)

> with experience on trying to accomplish this.
I'm not really convinced that it is worth the extra effort.

vh

Mads Toftum
-- 
With a rubber duck, one's never alone.
              -- "The Hitchhiker's Guide to the Galaxy"
______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl)                   www.modssl.org
User Support Mailing List                      [email-masked]
Automated List Manager                            [email-masked]

---

From: Balázs Nagy <[email-masked]>
Date: Fri, 25 Jan 2002 08:41:32 -0700

> On Fri, Jan 25, 2002 at 02:41:46PM +0100, Thierry Coopman wrote:

[snip]

> expired on the server side, then the server and client will just negotiate

The problem is not that much the SSL session (as it can be renegotiated),
but the 'business logic' session. Say you are in the middle of a transaction,
like Credit Card auth, and the server fails, you need to make sure, that
the transaction either:
- rolls back entirely, or
- is passed on the the next server that gets the connection.

You can achieve that by using databases (clusters if you can afford it) 
or EJBs (Enterprise Java Beans) that have their own mechanism (using
database persistence and other goodies) to ensure transaction integrity.

[snip]

---

From: Glen Mehn <[email-masked]>
Date: Fri, 25 Jan 2002 11:24:17 -0800

comments intertwined:

> LVS, your firewall or with HW load-balancing kit.

works just fine: LVS, foundry serverirons, cisco directors, bigIP, , others I'm sure...
 
> - The LoadBalancing system detects it and doesn't use the machine any more.

indeed. 

> session, the browser connecting to it fails to communicate.

no, the key gets renegociated

> it is a requirement to have the same cert on every machine.
 
it depends. I've got a couple fo clusters of machines. Where state on teh server side (app server) doesn't matter, IIRC you can use the same SSL cert signed, as the machine doesn't really matter. However, I think that you may get bouncing SSL sessions between servers. Where you need state you'll want different certs for each machine.

> reason, not a technical reason, but I'm not sure)

nah, they just want more of your money, and then when you have a problem, they'll make you pay to ignore you (IMHO)

> implementation with mod_ssl (only Apache-SSL)

hrm... dunno.

> with experience on trying to accomplish this.
 
another caveat that i've found to be problematic is when going from http to https (or the other way round) you can lose state as you go from one machien to the other. The load balancers do a pretty good job of the work, however, we've definitely seen jumpage from aol and webtv clients, as well as IIRC earthlink and mindspring==- where the routing is complex, and there can be multiple public IPs that a single session proxy can come from. I've seen requests from different IPs coming in with the same cookie or session IDs.

it's an imperfect solution, and we're still working on ours.

One thing i've thought of doing has been to setup a linux-vs cluster for the straight port-forwarding, then use apache/mod_ssl to handle the ssl negotiations, and pass it on to the real app server with mod_proxy.

glen

-- 
Glen S Mehn
Lead Systems Administrator		SquareTrade, Inc
[email-masked]	Building Trust in Transactions (sm)
______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl)                   www.modssl.org
User Support Mailing List                      [email-masked]
Automated List Manager                            [email-masked]