Gordon.Young wrote, On 2008-10-29 07:10 PDT: > This query is in regards to troubleshooting an SSL handshake issue we are > seeing between a older Sun-One product and a Microsoft Active-Directory > DC. We wanted to understand when TLSv1 became available to assist us in > troubleshooting.
Although NSS added TLS v1 support in y2k, a number of server products did not immediately incorporate NSS 2.8 or NSS 3.x into their products, and/or did not enable TLS v1, even though it was available in NSS 2.8. So, it's possible that you have a server product that does not support TLS v1, even if the the version(s) of NSS that were available at the time it was released did support TLS v1. I recall a number of issues in the interoperability of TLS clients and SSL 3.0 servers in the early days of TLS support on the Internet. I recall one in particular that affected MS's early TLS clients when visiting NSS SSL 3.0 servers. The SSL 3.0 and TLS specifications both require the client to send to the server, inside the RSA-encrypted pre-master secret (RSA-PMS), a copy of the version number that the client first sent in its client hello. Even if the version number chosen and returned by the server in the server hello does not match the value in the client hello, the value sent in the RSA-PMS must match the version sent by the client in the client hello. Servers are supposed to enforce that, detecting a mismatch between the value they received in the client hello and the value they receive inside the decrypted RSA-PMS as a "version roll-back attack". NSS gets that right, and always has (IIRC and IINM), sending the right value and checking the received and decrypted value properly. Unfortunately, in a number of other vendors' SSL 3.0 and early TLS v1 implementations, they got it wrong. In the RSA-PMS, their clients sent the negotiated version number returned by the server in the server hello, rather than sending the client's original version number, and their servers required that the version in the RSA-PMS match the version number chosen by the server and previously sent in the server hello. This is generally not a problem as long as the server chooses the same version number that the client sent in its client hello. As long as the version number returned by the server matches the version number in the client's hello, it all works, even if one or both ends are incorrectly choosing the value which they send, or expect to receive, in the RSA-PMS. And until the introduction of TLS v1, all clients and servers in the world understood only one version number, so this error was present in many products but went undetected for a long time, until the introduction of TLS v1 clients and servers on the internet. The problematic scenario occurs when a TLS-enabled client sends a TLS client hello (v 3.1) to an SSL 3.0 server, the server returns a server hello bearing version 3.0, and then the client sends an RSA-PMS bearing the version number 3.0 instead of 3.1 (TLS). In such a circumstance, an NSS server will reject that PMS and declare a version roll-back attack had been detected, just as the version roll-back detection feature of SSL 3.0 was intended to operate. This would have been a big problem, except that the early versions of Windows that supported TLS had it disabled by default, and almost no-one (except TLS developers like me) ever enabled it to see what it would do. By the time that Windows later enabled TLS by default, MS had changed that behavior in their client software so that it sent the proper version number in the RSA-PMS. Fearing that this was going to be a big problem, NSS 3.0 introduced a feature whereby a server application could disable the version roll-back attack detection in NSS. But as far as I know, that feature was never actually used by any server product. I think this is because most servers that used NSS 3.0 supported TLS, and so never experienced the version number mismatch issue. _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto