Closed Bug 454759 Opened 13 years ago Closed 11 years ago
Firefox still sends SSLv2 handshake even though the protocol is disabled
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:184.108.40.206) Gecko/2008070208 Firefox/3.0.1 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:220.127.116.11) Gecko/2008070208 Firefox/3.0.1 (.NET CLR 3.5.30729) Title should say it all, FF3 is still sending an SSLv2 handshake even though this protocol is supposed to be disabled by default. This protocol format has historically had a number of security problems due to datagram-parsing bugs, and in any case it makes no sense to send a hello message for a protocol that you don't support. In addition as the Mozilla wiki points out at https://wiki.mozilla.org/Necko:SSL_v2_Sites, you're losing capabilities by still sending the SSLv2 hello. Reproducible: Always Steps to Reproduce: 1. Connect to an SSL/TLS server using FF3. 2. Examine the client hello sent by Firefox. Actual Results: The client hello was an SSLv2 hello, not an SSLv3 hello. Expected Results: Send an SSLv3 hello. Not sure if this counts as a FF bug or an NSS bug, I've filed it against FF for now under the assumption that FF is telling NSS to still use SSLv2. If it's a problem at the NSS level (FF thinks it's sending an SSLv3 hello but NSS is wrongly sending an SSLv2 one) then it's a bug in NSS instead.
Additional information in case it's of any use: Explicitly disabling SSLv3 also disables the sending of the SSLv2 client hello, so it seems to be tied to use of SSLv3.
And even further information: With SSLv3 disabled and after an initial failed connect to a test server (in this case via https://localhost), FF reports 'Can't connect securely because the SSL protocol has been disabled'. From the server side I can see it opening the socket and then immediately closing it again without sending any data. Closing FF and restarting clears the problem for the first connect attempt, after which it reappears. In other words: 1. Disable SSLv3, leave TLS enabled. 2. Connect to a test server, e.g. https://localhost. 3. Have the server abort the connection rather abruptly during the handshake, e.g. by closing the socket. 4. Try reconnecting, and you'll get the 'SSL protocol disabled' error.
Continuing the saga... other errors during the handshake like a timeout due to the server being slow to reply also produce the 'SSL protocol has been disabled' problem... this is probably starting to get significant enough for a bug report of its own.
It's not clear to me if this is best dealt with at the PSM or NSS layer - but it sure does sound broken. Zipping over to Kai/Bob for more investigation.
Assignee: nobody → kaie
Component: Security → Security: PSM
Product: Firefox → Core
QA Contact: firefox → psm
This is all working as intended. Amazingly enough, Peter, we do know how our product works. There are still a lot of SSL 3.0 servers out there that don't handle SSL 3.0 client hellos correctly, but do handle SSL v2 client hellos correctly. PSM starts out with a TLS client hello. If the server fails to negotiate a handshake, we "fall back" to SSL 3.0 with an SSL 2 client hello because this is maximally interoperable with old servers. We considered, and rejected, the idea of doing two fallbacks, from TLS 1.0 to SSL 3.0 (pure) to SSL 3.0 with SSL 2.0 client hellos. Not enough benefit. It's a shame there are still so many broken servers out there, that cannot negotiate an SSL 3.1 or even SSL 3.0 handshake when presented with an SSL 3.1 (TLS) client hello, but there are still many of them. Browsers perpetually try to avoid problems that are solved by switching to other browsers. That is why FF continues to do this fallback stuff. Peter, you might consider searching through existing bugs. There is a known problem that occurs when the user has disabled all but TLS and the server fails to negotiate TLS. In that case, the browser should not attempt to "fall back", and when it does so, it finds that SSL 3.0 is disabled, and no other versions are enabled, so it reports "SSL is disabled". It's just not been a problem for enough users to become a priority to fix.
>There are still a lot of SSL 3.0 servers out there that don't handle SSL 3.0 >client hellos correctly, but do handle SSL v2 client hellos correctly. OK, fair enough. Wow, this seems rather odd behaviour, they don't talk SSLv2 but do require an SSLv2 hello... actually see the comment further down about how MSIE and Opera handle this. >PSM starts out with a TLS client hello. If the server fails to negotiate a >handshake, we "fall back" to SSL 3.0 with an SSL 2 client hello because this >is maximally interoperable with old servers. That's not the behaviour I've seen, if SSLv3 is enabled it starts right off with an SSLv2 hello (no TLS or even SSLv3, just straight SSLv2), only if it's disabled does it send a TLS hello. >Browsers perpetually try to avoid problems that are solved by switching to >other browsers. That is why FF continues to do this fallback stuff. Well neither MSIE 7 nor Opera send an SSLv2 hello any more (I don't have Safari on this machine to test), they both send a straight SSLv3 hello with TLS versioning (i.e. "3.1") but no extensions, so I'm not sure that this reasoning holds - if FF did send an SSLv3 hello and there was a problem, switching to any other browser wouldn't make any difference. This would also seem to rule out the "servers can't handle an SSLv3 hello" argument above, or am I missing something? >Peter, you might consider searching through existing bugs. I searched for SSLv2 problems before submitting, I didn't know I had to check for every imaginable variant of "SSL" and "TLS" as well :-). In any case since neither MSIE nor Opera seem to have this problem, it did look an awful lot like an FF3 bug. >There is a known problem that occurs when the user has disabled all but TLS >and the server fails to negotiate TLS. In that case, the browser should not >attempt to "fall back", and when it does so, it finds that SSL 3.0 is >disabled, and no other versions are enabled, so it reports "SSL is disabled". I'm not sure from the above whether this is quite what you're describing, the server isn't failing to negotiate TLS (that is, it's not saying "I can't do TLS, only SSL"), it's saying ECONNRESET or ETIMEDOUT or something similar and then, as you say, it's falling into the no-fall-back error handling. Maybe we're talking about the same thing here, just seen from different angles.
Here are some notes on TLS intolerant servers and "transparent recovery". The notes include comments about Mozilla, Netscape, Google Chromium, and the IETF-TLS mailing list. http://developer.mozilla.org/en/Notes_on_TLS_-_SSL_3.0_Intolerant_Servers http://devedge-temp.mozilla.org/viewsource/2001/tls-ssl3/ http://osdir.com/ml/ietf.tls/2003-06/msg00015.html http://www.netscape.ca/browser/netscape8/help/en/ssl_help.html#SSL_Protocol_Versions http://code.google.com/p/chromium/issues/detail?id=1891#c3 When we first enabled TLS in Netscape about 9 years ago, we found that many servers failed to negotiate any handshake when presented with a TLS 1.0 client hello. There were a small number of common failure modes: 1. After completing the TCP 3-phase handshake, upon receipt of the TLS client hello, the server sends a RST packet, resulting in ECONNRESET. 2. Server hangs upon receipt of client hello, never responding, holding the connection open as long as the client does so. 3. Server sends alert immediately upon receiving client hello 4. Server goes through entire handshake, appearing to negotiate an SSL 3.0 session, and then sends alert after receiving the client's Finished message. (This was commonly due to the server's incorrect handling of the version number embedded in the RSA-encrypted pre-master secret.) Servers that exhibit those behaviors will do so EVERY time they receive a TLS client hello. A browser that tries the same client hello again, after experiencing such a failure, will experience the same failure again. Therefore, a browser that wishes to successfully communicate with any of these servers MUST NOT repeat its attempt to use a TLS client hello with them. Upon detecting any of those failures, the client MUST revert to using a form of client hello that the server can handle. Years ago, I coined the phrase "transparent fallback" to describe this mode of operation. Prior to enabling TLS for the first time, SSL 3.0 servers always saw one of two kinds of client hellos: a) an SSL 3.0 client hello encapsulated in an SSL2 record. This was used in cases where the client had no prior connection with this server, and did not know if the server supported SSL2 or SSL3. b) an SSL 3.0 client hello in an SSL 3.0 record. This was used only to reuse an SSL session that had previously been established with an SSL 3.0 handshake. There exist(ed) servers that cannot handle any other forms of client hello. Even an simple SSL 3.0 client hello in an SSL 3.0 record could fail if the client had no prior SSL session ID to attempt to reuse in the client hello. If the user ran into such a server (they were common) the user had to manually disable TLS to communicate with those servers. That was generally a one-way street. Having disabled TLS, the user would never re-enable it. So, today, PSM (a browser component that interfaces with the SSL library) has an algorithm to decide if a failure appears to be one of the failure modes of a TLS intolerant server, and if so, it will NEVER again attempt to use a TLS client hello with that server, until the process is restarted. Once PSM has branded a server as "TLS intolerant", thereafter it will only send one of the two formats of client-hello described above. Now, as you know (I think), in Firefox 2, we finally disabled SSL2 by default. We received a LOT of grumpy pushback from corporate IT types who told us that we were acting prematurely to disable SSL2. Maybe the time has come to stop supporting this "transparent recovery" from "TLS Intolerant" servers. Maybe the time has come that servers must be able to at least successfully negotiate an SSL 3.0 connection when presented with a TLS client hello (and the version 3.1 in the RSA- encrypted pre-master secret). That is a call for the PSM browser folks to make, not for the SSL library (NSS) folks. No changes to NSS's SSL library are required to effect that behavioral change. It's a matter of how much pain the browser is willing to put upon its users who are unfortunate enough to still depend on TLS intolerant servers. One problem with the transparent fallback is that it masks the problem, so we have no metrics of how many servers still have the problem, and how many users unknowingly depend on that feature to continue to use the web. It's conceivable to me that some regression in PSM has caused it to start treating all servers as TLS-intolerant from the start. Several have alleged that it was so, but my most recent tests (weeks ago) showed that PSM was operating as described above.
This bug is mentioned in the Security section of the SSL article on Wikipedia (http://en.wikipedia.org/wiki/Secure_Sockets_Layer#Security). "SSL v2 is disabled by default in Internet Explorer 7, Mozilla Firefox 2, and Safari, however Mozilla Firefox was still sending SSL v2 handshakes as of version 3.01 ."
Mass change owner of unconfirmed "Core:Security UI/PSM/SMime" bugs to nobody. Search for kaie-20100607-unconfirmed-nobody
Assignee: kaie → nobody
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 148876
You need to log in before you can comment on or make changes to this bug.