Date: Sun, 26 Jul 1998 18:38:18 +0200
From: Henrik Nordstrom <[email protected]>
To: [email protected]Subject: Security warning: Netscape https & proxies
This is a multi-part message in MIME format.
--------------4A4A2E19141EAACFA220D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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
--------------4A4A2E19141EAACFA220D
Content-Type: application/x-sh; name="test_https_proxy.sh"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="test_https_proxy.sh"
#!/bin/sh
# Proxy port number
port=8080
# Using netcat or socket?
tcpserver="nc -l -p $port"
#tcpserver="socket -s $port"
# Show how to configure netscape
echo "Test running."
echo "Configure Netscape to use proxy-server `uname -n` port $port"
echo
# Here is the test page/server
while $tcpserver <<%EOF%; do cat <<%EOM%
HTTP/1.0 200 OK
Proxy-Connection: Keep-Alive
Content-Type: text/html
Content-Length: 202
<TITLE>Netscape Bug test page</TITLE>
<FORM ACTION="https://testserver.nowhere/" METHOD=POST>
<INPUT TYPE=HIDDEN VALUE="Your browser is VULNERABLE" NAME="DATA">
<INPUT TYPE=SUBMIT VALUE="TEST">
</FORM>
%EOF%
* If you see "Your+browser+is+VULNERABLE" above, then it is.
* If you see a lot of garbage above, then it isn't.
* If you don't see anything when pressing the TEST button (and
Netscape gave you a error dialog), then you have not configured
your proxy settings correctly.
Press reload to retry the test.
%EOM%
done
--------------4A4A2E19141EAACFA220D--
