Security warning: Netscape https & proxies

Here is the details behind my message on squid-users about https
security in Netscape 4.x when using Squid 1.2beta proxy server.

The bug is NOT a Squid bug, it is a bug in Netscape for which
Squid 1.2beta does not currently include a workaround (it will in
a later release, but as you will se a proxy can't fix all aspects
of the bug..).

The bug is in Netscapes handling of persistent proxy connections.
If it has a persistent connection open to the proxy then https
requests is NOT encrypted using SSL encryption, but sent in
plaintext to the proxy.

The bug is verified to exist in most versions of Unix Netscape
(Navigator 3.01gold, Communicator 4.04, 4.05 and 4.5 PR1). I
have not been able to test other versions of Netscape due to
limited resources, but I believe the bug is present in all
versions supporting persistent proxy connections, and also on
other platforms than UNIX.

The workaround is to have different settings for your security
proxy than the other protocols. Using different hostname-aliases
or even case is enough so if your proxy is www-proxy.some.domain
then you could set security-proxy to WWW-Proxy.Some.Domain and the
other protocols to www-proxy.some.domain and your browser should
be secured against this bug.

I have attached a small test program than can be used to test
if your browser in vulnerable. The test program is a UNIX shell
script and requires netcat (or socket) to function. To test a
non-vulnerable configuration you may need to run two simultaneous
copies of the test program since netcat can only handle one TCP
connection.

Conditions when the bug shows up:

1. Persistent connections are used between Netscape and the proxy
2. The proxy settings for security-proxy is identical to other
   protocols.
3. There is a persistent connection open between Netscape and the
   proxy.
4. The user initiates a https request

Known workarounds:

1. Use different proxy-settings for security(SSL) and other
   protocols. Netscape seems to do a case-sensitive string-compare
   of the proxy names so using different aliases or even case for
   the same proxy is enough. You do not need to have a separate
   SSL proxy server.
2. Configure the proxy to deny persistent connections from
   Netscape.
3. Silently drop unencrypted requests for https objects.

Workaround 1 is recommended, and seems to work again all known
effects of this Netscape browser bug.

Workaround 2 does workaround the initial problem, but has some
important drawbacks:
1. The end-user has to trust the security of the proxy-server to
   trust their SSL connections. If the proxy-server security is
   breached then a hacker could modify the proxy to exploit the
   browser bug, even if the proxy does not normally use persistent
   connections.
2. Not using persistent connections is a big performance penalty,
   especially on slow connections like modems.

Workaround 3 does only hide the problem. The request is still sent
in plaintext to the proxy, and then retried & properly encrypted.
It does not workaround the actual problem, only the end-user
visible effect of it. This is NOT RECOMMENDED by obvious
reasons.

Netscape has been notified several times, both by me and others,
but to my knowledge they have not responded to any of the messages
(perhaps the message has not reached the right persons or they
simply have not understood the impact of this bug).

---
Henrik Nordstrom
Sparetime Squid Hacker (not cracker)
http://hem.passagen.se/hno/Welcome.html