Re: FireFox v3.0.1 of Windows uses SSLv2 Record Layer even when SSLv2 is disabled

[Suresh Kumar J]

Please see inline for my repli @ [Suresh]. Thanks for your inputs. Enclosed the packet capture of the failing SSL handshake with FF3.0.1 on Windows. Nelson B Bolyard wrote: Suresh Kumar J wrote, On 2008-08-30 22:40: Am having the FireFox 3.0.1 on Windows XP with the default settings. When I try to connect(https on 443) to the internal website which is running on Apache Tomcat (v6.0.14), I get the following error: (Error code: ssl_error_no_cypher_overlap) I ensured that the both SSL3.0 and TLS1.0 are enabled(and SSLv2 is disabled) in the browser security settings and also the "about:config". The web-server is correctly configured for secured http on TLS. Earlier with Firefox2.0.x, it was working fine. Also checked with Linux version of FireFox3.0.1 and it is working fine. Two possible problems seem to be the most likely candidates: a) set of cipher suites enabled in the Windows profile does not include any implemented by the server [Suresh] The cipher suite TLS_RSA_WITH_RC4_128_MD5 (0x000004) is one of the suites negotiated in all of the Windows FF2.0, FF3.0 and Linux 3.0 browsers. This suite is implemented by the Tomcat webserver. Have observed this suite being negotiated by the server by using the FF2.0 and am able to make https connection successfully(with FF2.0). b) If you got your linux browser from a Linux distro (e.g. from a Linux vendor, rather than getting the builds from ftp.mozilla.org), your linux browser may be using a version of the crypto library that does not implement the full set of capabilities present in the Windows version. Perhaps your server is choking on the TLS client hello from the Windows box, but not on the less capable client hello from the Linux distro. [Suresh] My claim is that FF3.0.1(Windows) doesn't seem to use the TLS client hello format. Instead it uses the "SSLv2 Record Layer : Client Hello" message for initial negotiation. This seems to be the problem. The FF3.0.1 of Redhat distro uses TLS When I tried to analysis the packets capture of the browser/web-server communication via "WireShark/Ethereal" tools, I observed that the FF3.0 on Windows uses "SSLv2 Record layer(Client Hello)" for SSL handshake negotiations, eventhough the SSLv2 is disabled in the drowser settings. As my tomcat webserver is configured for TLS, it doesn't seem to understand the SSLv2 record layer format, eventually errors out with "javax.net.ssl.SSLException: INTERNAL ERROR" Java internal errors are clearly a server issue. Since SSLv2 is generally considered to be a weaker protocol than SSLv3 and TLS, why the heck FF3.0.1 on Windows uses SSLv2 Record protocol, FF 2 and FF 3 start out trying to use TLS, but if the attempt to negotiate a TLS handshake is unsuccessful, FF 2/3 fall back to a compatibility mode where client hellos (only) are encapsulated in SSL2 records, and the client attempts to negotiate only SSL 3.0, not TLS. This is because there are many servers out there that don't properly implement TLS, and are unable to negotiate a handshake with a TLS client, but are able to negotiate handshakes with clients following the old SSL 3 formula. [Suresh] As I mentioned earlier, the FF3.0.1(Windows) does NOT seem to use the 'TLS client hello' format for SSL negotiation. Instead it uses the "SSLv2 Record Layer : Client Hello" message format for initial negotiation. Have captured the packet communication between the browser and the server and viewed through the WireShark tool. The "version" field inside the message specifies as "TLS1.0", but the message format seems to be of SSLv2. After the first client hello fails, the client retries with SSLv2 messages with the version field marked as 'SSS3.0'. Enclosed the packet capture of the failing SSL handshake with FF3.0.1 on Windows. In case of FF3.0.1(Redhat Linux), the initial handshake uses the "TLS1.0 Record Layer" message format. Note that the FF3.0 of both Win and Linux are running with the default browser configuration(SSLv3 and TLS1.0 enabled). Am interested to know what makes the FF3.0 of Windows to use SSLv2 Record protocol even though the SSLv2 protocol is disabled. The one fact that is certain is that the client's first attempt to negotiate a TLS connection with your server failed. When you solve that problem, you will find that the SSL 2 encapsulation will no longer occur. _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto