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