Re: Security of SSL proxies

["Peter Trei" <trei@process.com>]

pgut001@cs.auckland.ac.nz (Peter Gutmann) writes:
> A number of vendors are now selling SSL proxies which implement secure 
> tunnelling for web browsers using a non-crippled SSL implementation running on 
> the client machine.  Has anyone considered the total security level provided 
> by one of these systems?  I can see three problems with this approach:
>  
> 1. The security stops a few feet short of the browser, making a MITM attack 
>    possible (see below).
>  
> 2. Security and authentication is handled by the proxy and not the browser.  
>    This means that the browser (and browser user) never get to see the usual 
>    indicators that their connection is secure (or "secure" for non-US users).
>  
> 3. If you use a proxy like this to protect traffic for an entire company, the 
>    proxy provides the same type of target as a GAK key center: An attack which 
>    compromises this compromises security for the entire company.
[problems with this approach deleted]

> Peter.

I'm a little confused by your use of the term 'SSL proxy'. Netscape 
defined an extension to HTTP to allow SSL traffic through a firewall:
the encrypted request is prepended (in clear) with the actual 
destination IP address and port. The firewall proxy then opens a 
TCP/IP channel to the actual destination/port, and blindly relays packets
between the actual destination and the browser until one side or the
other shuts down the link.

The proxy does no encryption or decryption - in fact, it requires no 
crypto code at all. 

(BTW: this what setting the 'security proxy' field in Netscape is 
all about).

The scheme has some drawbacks 

- there is no provision for chaining proxies. 
- the server can't determine the source browser's IP - it only sees 
  the proxy's IP address. This makes it more difficult to filter 
  requests based on source ID.
- the proxy has no idea of the actual URL requested - proxies which
  want to filter or log requests based on URL can't do so.

Or are you talking about something entirely different? 

Peter Trei
(yes, I've implemented the above)
trei@process.com