FIPS SSL CipherSuites
Newsgroup: mozilla.dev.tech.cryptoMain technical contact: Nelson Bolyard
This document was originally written by Frank Hecker and Nelson Bolyard in November 1999. Netscape browsers, beginning with Communicator 4.71, and later versions all used these FIPS CipherSuites as described here. NSS 2.7.1 was the first version of NSS to use these CipherSuites. NSS 3.0 (the first version released on Mozilla) and later versions also used these CipherSuites.
Introduction
Netscape was an early participant in FIPS 140-1 validation, at a time when the SSL 3.0 protocol specification [SSL3] had been finalized and broadly implemented, but the TLS 1.0 protocol specification [TLS] (also known as SSL 3.1) was still in early draft form and some way from being completed. Netscape therefore implemented FIPS 140-1 capabilities within the framework of the SSL 3.0 protocol.In the course of validation NIST expressed concerns about the details of the SSL 3.0 protocol, and in particular about the SSL 3.0 key derivation algorithm and the particular manner in which it used a non-FIPS algorithm (MD5). NIST's concerns were the SSL 3.0 protocol specification itself, not with any one implementation of SSL 3.0, and could only be addressed by changing the SSL 3.0 protocol specification itself.
The IETF TLS working group was already using SSL version number 3.1 in the draft specification of TLS 1.0, and NIST was satisfied that the key derivation function in TLS was acceptable. NIST has published the list of approved TLS CipherSuites in table 3 of NIST Special Publication 800-52. But in 1999 the TLS specification draft was not yet final, and products could not be made or sold that claimed to be conformant with the TLS 1.0 specification because it was unfinished.
Netscape therefore chose to address NIST's concerns by creating two new SSL 3.0 ciphersuites. These new "FIPS SSL" CipherSuites used FIPS-approved algorithms (DES 3DES and SHA-1), and also modified the behavior of the SSL3 protocol to incorporate the changes suggested by NIST. They made SSL 3.0 behave more like TLS 1.0. Those changes are described in detail below.
Today, the specification of IETF TLS 1.0 has been finalized, and many new stronger AES CipherSuites exist that are approved for FIPS use. Therefore, the "FIPS SSL" CipherSuites described in this paper are now obsolete, and should no longer be used. NSS continues to support them ONLY for backwards compatiblity with old pre-TLS servers that supported them.
Today, those who wish to use FIPS 140 compliant TLS cipher suites should configure their SSL/TLS software to disable SSL2 and SSL 3.0 and enable only TLS 1.0 (SSL 3.1), and to disable any CipherSuites not found in this list:
- TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
- TLS_DHE_DSS_WITH_AES_128_CBC_SHA
- TLS_DHE_DSS_WITH_AES_256_CBC_SHA
- TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
- TLS_DHE_RSA_WITH_AES_128_CBC_SHA
- TLS_DHE_RSA_WITH_AES_256_CBC_SHA
- TLS_RSA_WITH_3DES_EDE_CBC_SHA
- TLS_RSA_WITH_AES_128_CBC_SHA
- TLS_RSA_WITH_AES_256_CBC_SHA
- TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
- TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
- TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
- TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
- TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
- TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
- TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
- TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
FIPS SSL CipherSuites (OBSOLETE)
The two added FIPS SSL CipherSuites are designated- SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA and
- SSL_RSA_FIPS_WITH_DES_CBC_SHA.
- TLS_RSA_WITH_3DES_EDE_CBC_SHA and
- TLS_RSA_WITH_DES_CBC_SHA
When negotiated as part of an SSL 3.0 session, these two CipherSuites are identical to the SSL 3.0 CipherSuites
- SSL_RSA_WITH_3DES_EDE_CBC_SHA and
- SSL_RSA_WITH_DES_CBC_SHA
When either of the above FIPS SSL CipherSuites is negotiated as part of an SSL 3.0 session, the derivation of the master secret from the pre-master secret, and the derivation of the "key block" from the master secret, are not done according to the SSL 3.0 specification, but rather are done according to the TLS 1.0 specification.
Specifically, the derivation of the master_secret from the pre_master_secret and the ServerHello.random and ClientHello.random values is not done according to section 6.1 of the SSL 3.0 specification. Rather, it is done according to the specification in section 8.1 of the TLS 1.0 specification (RFC 2246), which incorporates the PRF function, defined in section 5 of RFC 2246, which in turn incorporates the HMAC function, defined in RFC 2104 [HMAC].
Likewise, for the FIPS SSL CipherSuites the "key block" is not derived as specified in section 6.2.2 of the SSL 3.0 specification. Instead it is derived as specified in section 6.3 of RFC 2246, which incorporates the the PRF function, defined in section 5 of RFC 2246, which in turn incorporates the HMAC function, defined in RFC 2104.
Those are the only differences between the FIPS SSL CipherSuites and the corresponding non-FIPS SSL 3.0 CipherSuites, when negotiated in an SSL 3.0 session. In an SSL 3.0 session, all other computations are done exactly as specified in the SSL 3.0 specification. More specifically:
- Version {3,0} is used, not {3,1}.
- Padding of block ciphers is done according to the SSL 3.0 specification, and not according to TLS 1.0.
- Record layer MACs are computed according to the SSL 3.0 specification, and not according to TLS 1.0.
- All alerts remain the same as in SSL 3.0, not as in TLS 1.0.
- RSA public- and private-key encrypted values are encoded as in SSL 3.0, not as in TLS 1.0.
- DSA signatures (i.e., in client authentication) are encoded as in SSL 3.0, not as in TLS 1.0.
- The "finished" handshake messages are computed as in SSL 3.0, not as TLS 1.0.
- The no_certificates response to a certificate request is done as in SSL 3.0 (with an alert), not as in TLS 1.0 (with an empty certificates message).
Here are the definitions of the two new CipherSuites as they would appear
in Appendix C of the SSL 3.0 specification:
| CipherSuite | Is Exportable | Key Exchange | Cipher | Hash |
| SSL_RSA_FIPS_WITH_DES_CBC_SHA | (no) | RSA | DES_CBC | SHA |
| SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA | (no) | RSA | 3DES_EDE_CBC | SHA |
FIPS SSL CipherSuite Numbers (OBSOLETE)
Netscape's initial implementation of the FIPS SSL CipherSuites used code numbers in the space reserved for "local" algorithms, since these were thought to be of use only "locally" to certain specific U.S. government customers. The values of those CipherSuite codes were: CipherSuite SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA = { 0xFF,0xE0 };
CipherSuite SSL_RSA_FIPS_WITH_DES_CBC_SHA = { 0xFF,0xE1 };
However, since Netscape has published the specification of these CipherSuites,
to promote interoperability Netscape has chosen to use the following values
from the "public" CipherSuite space, and has updated its implementation
accordingly:
CipherSuite SSL_RSA_FIPS_WITH_DES_CBC_SHA = { 0xFE,0xFE };
CipherSuite SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA = { 0xFE,0xFF };