COMMAND

    Netscape 4.0x https

SYSTEMS AFFECTED

    Netscape 3.x, 4.0x and 4.5 PR1 https (all?)

PROBLEM

    Joe Ramey  found following.   If you  are using  Squid 1.2beta and
    Netscape 4.x  then you  MUST use  different server  names for your
    HTTP  and  Security  (SSL)  proxy.   This  is  due  to  a  bug  in
    Netscape4.0x that  may cause  https requests  to be  sent in plain
    text to a Squid 1.2beta proxy  server.  This bug is still  present
    in the latest  Netscape beta, 4.5  PR1.  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.

    Henrik Nordstrom posted 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

    -----------------------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

SOLUTION

    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 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.  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.