Security of SSL proxies

[Peter Trei]

pgut001 at 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 at process.com