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