239381 - Bugs in PSM's handling of TLS-intolerant servers

Status: RESOLVED WORKSFORME

(Core :: Security: PSM, defect)

Description

[chris hofmann]

report via a mozilla product security alias...

Nelson, can you have a look and let us know if there
is something we should do about this?

>
>
>Subject: - Windows 2000 (2k Professional) - TLS Doesn't Work
>Date: 3/31/2004, 3:02 PM
>From: [e-mail]
>
>    Submitter name:                Matthew S. Hamrick
>    Submitter email address:       [e-mail]
>    Acknowledgement checkbox:      on
>    Product:                       Netscape 7.x
>    Operating system:              Windows 2000
>    OS version:                    2k Professional
>    Issue summary:                 TLS Doesn't Work
>
>Issue details:
>Let's say there's a server out there that only
>does TLS and SSLv2. You don't want to do SSLv2
>because of all the security issues, so this leaves
>SSLv3 and TLS. You go into Edit -> Preferences ->
>Privacy and Security -> SSL and
>
>Deselect the SSLv2 check box.
>Select the SSLv3 check box.
>Select the TLS check box.
>
>You now attempt to connect to the server and are
>told that you can't connect because SSLv2 is not
>enabled.
>
>But wait, you say, Navigator / Mozilla should be
>connecting via TLS!
>
>Because you're an uber-geek, you pop into a shell
>and verify that the server you're looking at
>speaks TLS by doing:
>
>openssl s_client -tls1 -connect www.google.com:443
>-showcerts
>
>Yup. It's definitely negotiating. You then go back
>to your browser (your Netscape browser) and
>surprise! it's still giving you an error, even
>though you (think) you have TLS enabled. To be
>complete, you double-check that you can use any
>ciphersuite over TLS or SSLv3 (even though, in
>practice, you shouldn't be using the ones with
>small key sizes.)
>
>Still it doesn't work.
>
>So just for giggles, you deselect the SSLv3 box in
>the Edit -> Preferences -> Security and Privacy ->
>SSL dialog. When you attempt to connect again, the
>alert box that comes up says that SSL is not
>enabled. Wha?
>
>Yes, that's right, it appears that irrespective of
>the selection status of TLS in the Edit ->
>Preferences -> Security and Privacy -> SSL dialog
>box, you apparently can't convince Netscape
>Navigator to initiate a TLS connection.
>
>And the kicker is: MSIE works just fine with TLS.
>I never thought I'd see the day when MSIE beat out
>Navigator in a comparison of security features.
>
>
>This form was submitted from
>http://help.netscape.com/forms/bug-security.html
>with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4)
>Gecko/20030624 Netscape/7.1 (ax).
>
>

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

The mail quoted above reports a user experrience with N7.1, not mozilla.

I am unilaterally removing the security sensitive flag, and changing the
product to PSM.  This "bug" does not report any vulnerability of any product,
client or server.  The reported issue does not put the browser in an 
insecure state.

I'm not convinced this is a real bug at all.  It should be unconfirmed, 
at best, at least until a reproducible test case is presented. 

We know that NSS/PSM succesfully negotiate TLS for large masses of users. 
We also know that there are many servers that negotiate SSL/TLS versions 
properly, but do work with old versions of IE (that is, those servers are
bug compatible with old IE).  

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

That last comment was supposed to say "negotiate SSL/TLS versions IMproperly".

Comment 3

[John G. Myers]

No testcase.  I am able to negotiate a TLS connection with both SSLv2 and SSLv3
disabled in prefs.  Closing WORKSFORME.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

The original reporter of this bug sent me more information, with which 
I was able to reproduce the problem and identify the bugs.  This bug is
apparently in all versions of N7 and moz that implement the workaround for
TLS-intolerant servers.  I thank the reporter for being persistent. :)

Steps to reproduce:
1. disable SSL2 and SSL3, leaving TLS enabled.
2. Find an https server that implements TLS (properly).
3. Do something that causes a handshake with that server to fail.  
   (I'll explain some ways to do this below.)
4. Then try to contact that server again.
You will see the error message
         "You cannot connect to <host> because SSL is disabled."

One way to reproduce this is to visit an https server that has a cert 
with the wrong hostname in it, so that you get a host name mismatch warning.
One host that has such a cert (as of this writing) is www.google.nl .
Then just sit and wait about a minute, long enough for the server to give 
up on you and close the connection, before you click "OK" to allow the
handshake to proceed despite the hostname mismatch.  Then after you get the 
error dialog, try again. 

Another way to do this is to create an entry in your /etc/hosts file
(or equivalent on other platforms) that has the IP address of a known
TLS server, and some other name, e.g. www.wrongname.com.  Then go visit
that name, e.g. https://www.wrongnme.com/ which will force a hostname
mismatch error.  

An expired cert would also serve this purpose, that is, it would give
the user an overridable warning dialog, which the user could override
after an unsuitably long time.

What's happening is this.  When that handshake fails (because you waited
so long in the host name mismatch dialog), PSM concludes that the host was
TLS intolerant (That's bug 1), and adds the name of that host to PSM's 
list of TLS-intolerant servers.  When you visit that host again, PSM 
finds that hostname in the list of TLS intolerant servers, and so disables
TLS, without regard for the fact that SSL3 is disabled (Bug 2) at  
http://lxr.mozilla.org/mozilla/source/security/manager/ssl/src/nsNSSIOLayer.cpp#2261
Since TLS was the only version enabled, and PSM just disabled it, that left no
versions of SSL/TLS enabled.  When PSM then goes to try to do the handshake, 
the SSL library reports that SSL has been disabled (that is, all versions of
SSL/TLS have been disabled).  There's apparently no way to get PSM to flush 
its list of TLS-intolerant servers, short of a restart.  

I'd say that the TLS-intolerant server workaround code needs to be a little
smarter in two ways:

a) don't disable TLS if SSL3 is disabled.  That is, disable the 
TLS-intolerant workaround compmletely if SSL3 is disabled.  

b) It should be possible to take note of the fact that a host name mismatch
dialog, or other warning dialog, was presented to the user, and then not 
treat a subsequent failure as a sign of TLS-intolerance.  

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

One additional comment.  After reproducing this bug, if you restart your
browser, and visit the site again and QUICKLY dismiss the host name 
mismatch dialog, mozilla negotiates TLS just fine.  So, there is no problem
with the TLS protocol code shown by this bug report.  

Comment 6

[John G. Myers]

Nelson, if SSLv3 is disabled and SSLv2 is enabled, should not the TLS
intolerance workaround code try to restart the handshake?

Is there a particular error code or set of codes caused by TLS intolerant servers?

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

John, in answer to your two questions in comment 6:

1. Yes, IF SSL2 is enabled, it should be tried without TLS.
TLS should not be disabled when it is the only remaining enabled version.

2. TLS intolerant servers can misbehave in MANY ways, timing out, or closing
the connection or sending an alert after either the client hello or the 
client's [key exchange .. finsihed] message sequence.  So there is no 
single error (nor ever just a few errors) that indicate TLS intolerance.
However, there are quite a few errors that do not imply TLS intolerance
at all.  For example, none of the errors related to bad certificates 
implies TLS intolerance.  So, there's no point in attempting a retry 
with TLS disabled after one of those errors.  

I think I once worked up a list of errors that definitely do NOT imply
TLS intolerance.  I'll see if I can find it.  

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

There are servers that only implement and support TLS (SSL 3.1) and not
also SSL 3.0.  These servers sometimes fail to negotiate a TLS handshake.
Our TLS-intolerant server fallback logic causes us to be unable to 
connect to those servers thereafter, until a process restart.  
Disabling SSL 3.0 support in PSM preferences doesn't help.

See also bug 399061.

Comment 9

[Kai Engert [:KaiE:]]

Is there a testcase that still works?

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

If we can't find one easily, I'm sure we could devise one using selfserv 
very quickly.  But I know I've seen a bug in the last few months about 
a server that used only TLS and not SSL 3.0.  If we can find that bug,
we can use that server for a test case (unless the server admin has 
enabled SSL 3.0 since it was filed).  It may have been a Thunderbird bug.

Comment 11

[Bob Payne]

I'm having a problem which I believe is directly related.  I have a small embedded web server which only supports TLSv1.  It is serving complex pages which require many sessions.  When a page hasn't fully loaded and the user selects a tab which causes a new page to load, we sometimes encounter the dreaded "Firefox can't connect securely to x.y.z because the site uses a security protocol which isn't enabled".  I can also reproduce this by multiple attempts of pressing the refresh icon which can have the same effect of interrupting a session negotiation. A wireshark capture reveals that the selection of another page caused the negotiation to fail, firefox closed the socket between sending the TLSv1 client hello and receiving the Server Hello.  
At this point, Firefox will attempt to negotiate with SSLv2 which the server rejects.  Now Firefox apparently adds this server to the list of intolerant TLS servers.
No.     Time        Source                Destination           Protocol Info
2464 81.891092   10.7.6.165            10.7.40.31            TCP      33715 > https [SYN] Seq=0 Len=0 MSS=1460 TSV=683990859 TSER=0 WS=2

2466 81.892452   10.7.40.31            10.7.6.165            TCP      https > 33715 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 TSV=61032802 TSER=683990859 WS=0

2467 81.892490   10.7.6.165            10.7.40.31            TCP      33715 > https [ACK] Seq=1 Ack=1 Win=5840 Len=0 TSV=683990861 TSER=61032802

2468 81.892933   10.7.6.165            10.7.40.31            TLSv1    Client Hello

2469 81.893857   10.7.40.31            10.7.6.165            TCP      https > 33715 [ACK] Seq=1 Ack=179 Win=6432 Len=0 TSV=61032803 TSER=683990861

2470 81.899030   10.7.6.165            10.7.40.31            TCP      33715 > https [FIN, ACK] Seq=179 Ack=1 Win=5840 Len=0 TSV=683990867 TSER=61032803

2479 81.937338   10.7.40.31            10.7.6.165            TCP      https > 33715 [ACK] Seq=1 Ack=180 Win=6432 Len=0 TSV=61032821 TSER=683990867

2489 82.251368   10.7.40.31            10.7.6.165            TLSv1    Server Hello

2490 82.251377   10.7.6.165            10.7.40.31            TCP      33715 > https [RST] Seq=180 Len=0


Next...

2476 81.933428   10.7.6.165            10.7.40.31            TCP      33716 > https [SYN] Seq=0 Len=0 MSS=1460 TSV=683990901 TSER=0 WS=2

2477 81.934291   10.7.40.31            10.7.6.165            TCP      https > 33716 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 TSV=61032819 TSER=683990901 WS=0

2478 81.934332   10.7.6.165            10.7.40.31            TCP      33716 > https [ACK] Seq=1 Ack=1 Win=5840 Len=0 TSV=683990902 TSER=61032819

2480 81.946858   10.7.6.165            10.7.40.31            SSLv2    Client Hello

2481 81.947670   10.7.40.31            10.7.6.165            TCP      https > 33716 [ACK] Seq=1 Ack=91 Win=5792 Len=0 TSV=61032825 TSER=683990915

2491 82.276099   10.7.40.31            10.7.6.165            TLSv1    Alert (Level: Fatal, Description: Protocol Version)

2492 82.276123   10.7.6.165            10.7.40.31            TCP      33716 > https [ACK] Seq=91 Ack=8 Win=5840 Len=0 TSV=683991244 TSER=61032957

2493 87.875728   10.7.6.165            10.7.40.31            TCP      33716 > https [RST, ACK] Seq=91 Ack=8 Win=5840 Len=0 TSV=683996845 TSER=61032957

No more joy until quitting and restarting Firefox.

Comment 12

[Nelson Bolyard (seldom reads bugmail)]

Related bugs about PSM's TLS-intolerant server handling:

bug 412833, 
bug 412834, 
bug 412848