Re: Security tool for monitoring HTTPS traffic?

["lists AT dawes DOT za DOT net" <"lists AT dawes DOT za DOT net"@securityfocus.com>]

Hi folks,

Imre Kertesz wrote:

> This kind of defeats the purpose of SSL, doesnt it? Its like UPS opening 
> up boxes at the transfer station to check out what's inside and 
> repackaging.  Interrupting SSL for any reason increases the risk of data 
> compromise significantly, not to mention the privacy issues.  For this 
> to happen legally, the organization using this mechanism has got to have 
> a very clearly worded policy about intent.
>
> -I

I don't believe that this defeats the purpose of SSL at all.

The organisation is providing a service on their web server, and 
consequently have a need/right to see the data in clear. In particular, 
they may wish to do multiple things with the data, such as performing 
IDS, tracking users, etc, apart from providing the service.

Whether they get access to that data via the specific web server API's, 
or by decrypting the stream in parallel to the webserver, or by placing 
a proxy in front of the actual server that runs the app, and decrypting 
and reencrypting the data, is entirely up to them.

One would hope that they are doing this within a good architectural 
framework, and practicing appropriate security measures where the data 
is in clear, and where the SSL keys are located, but it is ultimately up 
to the web server owner if they choose to do this.

Let's give an example:

My bank's network architecture is as follows:

In order to provide high-performance and redundancy, they have a load 
balancer in front of a server farm. They want a particular user to get 
the same web server in the farm for each subsequent connection, since 
the session state is not distributed over all the servers in the farm. 
However, they do not want to use source IP address load-balancing, 
because they have a number of users coming through proxies, and do not 
wish to overload a particular server in their farm.

There are a couple of solutions, but probably the most effective and 
reliable solution is to insert a cookie into the browser, so the 
load-balancer can tell which server the user was connected to 
previously. This is a common technique when the connection is not 
encrypted.

What do you do when the connection is encrypted? Well, many places are 
implementing an SSL accelerator in the load balancer, that performs 
hardware-accelerated decryption of the SSL stream, and passes the 
unencrypted stream on to the appropriate server in the server farm.

Obviously, it is important for access to the data travelling on the 
network between the server farm and the load-balancer/accelerator to be 
tightly controlled. But this is not really any different to saying 
"access to the web server should be tightly controlled".

A similar thing is done between web servers and application servers, for 
that matter. The web server terminates the SSL stream, decrypts the 
data, and passes the request over the network to the application server 
(maybe using a binary protocol, but most times not encrypted)

I don't see any reason to disclose this or similar information to the user.

Regards,

Rogan

> John Floyd wrote:
>
> > There are Application Layer firewalls which can inspect HTTPS traffic to
> > assure that the communications coming in are not maliscious attacks via
> > the web browser.  These types of solutions will decrypt the traffic,
> > inspect it, and then either re-encrypt or not, and send back to your web
> > server.
> > http://www.infoworld.com/article/04/02/06/06FEsecureapp_1.html
> > Cheers
> >
> > John


--
"Using encryption on the Internet is the equivalent of arranging an
armored car to deliver credit card information from someone living
in a cardboard box to someone living on a park bench."
- Gene Spafford