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
