From: “Peter Trei” <trei@process.com>
To: pgut001@cs.auckland.ac.nz
Message Hash: 1fd694d628d8436ab3a6caaa92df709df20471af02537099541f4181964e42f4
Message ID: <199703241526.HAA07715@toad.com>
Reply To: N/A
UTC Datetime: 1997-03-24 15:26:17 UTC
Raw Date: Mon, 24 Mar 1997 07:26:17 -0800 (PST)
From: "Peter Trei" <trei@process.com>
Date: Mon, 24 Mar 1997 07:26:17 -0800 (PST)
To: pgut001@cs.auckland.ac.nz
Subject: Re: Security of SSL proxies
Message-ID: <199703241526.HAA07715@toad.com>
MIME-Version: 1.0
Content-Type: text/plain
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
Return to March 1997
Return to ““Peter Trei” <trei@process.com>”