RE: Using SSL accelerators in firewalls

["Dawes, Rogan (ZA - Johannesburg)" <rdawes () deloitte co za>]

My personal perference is to use an "attached" SSL accelerator, such as the
nCipher devices. PCI or SCSI attached boxen, that still terminate the SSL
traffic on the server itself.

However, this raises a few problems, particularly in your "banking"
scenario, or actually, under any high load environment.

One often wants to have the traffic load balanced over a farm of servers.
There are a couple of approaches to doing this.

* Load balance based on source IP address
* Load balance on a round robin or least loaded basis

The significant differences are that the destination host is not
deterministic in the second case, i.e. you may not always be directed to the
same backend webserver on every request.

Applications typically want some kind of persistence, unless the application
is designed in such a way that you can connect to different servers for each
transaction without any problems. This is unusual, as most applications keep
some kind of state in the server itself, rather than writing it all back to
a database for every GET or POST.

So the load balancer either needs to be deterministic (based on source IP),
or else identify the connection based on the SSL stream.

The problem with using a deterministic algorithm comes up if you have a lot
of clients coming from a single IP address, such as an ISP's proxy (AOL,
anyone?). Those clients will all be sent to a single server, while the
others sit idle. Not a good solution.

Some load balancers can identify a connection based on the SSL sessionid
negotiated, and balance that way, however that is starting to become
useless, due to the browsers renegotiating stronger crypto within the
existing SSL stream, and then using a new SSL sessionid, that was encrypted
and hidden from the load balancer.

So the load balancer needs to actually terminate the SSL connection, so that
it can either insert a Cookie of its own, or record the application's
cookie, and balance using a table of "cookie to server" mappings. That means
we now have a clear text connection back to the backend, which is the
situation we were trying to avoid. :-(

So, the load balancer can also REencrypt the session to the backend server.
This has the downside that the backend server still needs an accelerator
card, as well as the load balancer needing one. (Doubly, because it is now
decrypting and encrypting the traffic.)

This introduces latency, which kind of defeats the object of load balancing
in the first place!

One solution that I have been looking at with interest is the ingrian
device, which can actually encrypt sensite field values in the SSL
terminator device. So the web server receives clear text connections, with
specific fields already encrypted. That can be useful to prevent PIN numbers
from being exposed, however, it still offers an attacker with access to the
cleartext segment the opportunity to hijack the session based on the cookie,
or change the password based on the existing encrypted PIN/password, collect
encrypted passwords for brute force attacks, etc.

Have I left anything out, or forgotten some obvious solution?

Any comments and suggestions welcome!

Rogan

> -----Original Message-----
> From: Darren Reed [mailto:darrenr () reed wattle id au]
> Sent: 17 July 2002 02:56
> To: firewall-wizards () honor icsalabs com
> Subject: Re: [fw-wiz] Using SSL accelerators in firewalls
>
>
> In some email I received from Darren Reed, sie wrote:
> > There would seem to be a growing trend in using SSL accelerators not
> > next to the web server but attached to a firewall so that it isn't
> > https traffic that passes through but http.
>
> Let me ask this question another way.
>
> If your bank was using one of these SSL accelerators and it was not
> directly attached to the web server, but the "far side" of something
> else so they could screen traffic and then pass your data through
> some number of other things, unencrypted, would you use that bank's
> Internet Banking service which used SSL encryption ?
>
> If you had a choice between that and one which did the SSL encryption
> on (or next to) the web server (lets assume all other 
> security measures
> are equal), which one would you choose, if you had the chance ?
>
> Darren
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards () honor icsalabs com
> http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards