1997-03-22 - Security of SSL proxies

Header Data

From: pgut001@cs.auckland.ac.nz (Peter Gutmann)
To: cypherpunks@toad.com
Message Hash: f1b8544352976f0d6c835e4ce3fdde425613633ee082ac1d71cbf89c794b2b80
Message ID: <85904544316081@cs26.cs.auckland.ac.nz>
Reply To: N/A
UTC Datetime: 1997-03-22 15:44:17 UTC
Raw Date: Sat, 22 Mar 1997 07:44:17 -0800 (PST)

Raw message

From: pgut001@cs.auckland.ac.nz (Peter Gutmann)
Date: Sat, 22 Mar 1997 07:44:17 -0800 (PST)
To: cypherpunks@toad.com
Subject: Security of SSL proxies
Message-ID: <85904544316081@cs26.cs.auckland.ac.nz>
MIME-Version: 1.0
Content-Type: text/plain


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.
 
The first one is a practical problem, the second one is more perceptual.  
Consider the following possible attack: A nice authenticoded ActiveX control 
("the tee proxy") installs itself on your machine and hooks itself into the 
chain of proxies by either moving the SSL proxy to a different port or 
changing the browser config entry so it's the first proxy in the chain.  It 
then scans all data being forwarded for credit card numbers/PINs/whatever and 
forwards them to God knows where.
 
There are various simple defences (eg the SSL proxy checks to make sure the 
browser still goes to it first), but in the end it's just a cat and mouse 
game - the tee proxy could spoof the registry calls (there was an article in 
DDJ which explains how to do this), or disable the check, or hook directly 
into the proxy service by patching the DLL (this was explained in MSJ I 
think).  In short, because the security stops a few feet short, it's possible 
to attack the system.
 
A related problem is that fact that the browser isn't aware that a layer of 
security is being applied to the connection, and so will act as if the 
connection was insecure (ie it won't display the usual signs that the link is 
secured, and will give annoying warnings when navigating secure web sites).
 
Finally, pulling personal certs into/through the proxy is rather complex, 
requiring the cooperation of the CA in issuing specific types of certs (one 
browser-specific one for the browser and an identical-content but 
proxy-specific one for the proxy), and all sorts of complex juggling by the 
user to install them.  This probably makes the use of certs in this 
environment fairly luser-proof, which more or less means no certs.
 
Are there any other problems which people are aware of?  There was a bit of a 
fuss made about these proxies being the end of ITAR when they were first 
announced, but since then things seem to have gone quiet.
 
Peter.






Thread