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)
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.
Return to March 1997
Return to “pgut001@cs.auckland.ac.nz (Peter Gutmann)”
1997-03-22 (Sat, 22 Mar 1997 07:44:17 -0800 (PST)) - Security of SSL proxies - pgut001@cs.auckland.ac.nz (Peter Gutmann)