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--
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:08:08 PDT