The SSL protocol supports the use of a variety of different cryptographic algorithms, or ciphers, for use in operations such as authenticating the server and client to each other, transmitting certificates, and establishing session keys. Clients and servers may support different cipher suites, or sets of ciphers, depending on factors such as the version of SSL they support, company policies regarding acceptable encryption strength, and government restrictions on export of SSL-enabled software. Among its other functions, the SSL handshake protocol determines how the server and client negotiate which cipher suites they will use to authenticate each other, to transmit certificates, and to establish session keys.
Key-exchange algorithms like KEA and RSA key exchange govern the way in which the server and client determine the symmetric keys they will both use during an SSL session. The most commonly used SSL cipher suites use RSA key exchange.
The SSL 2.0 and SSL 3.0 protocols support overlapping sets of cipher suites. Administrators can enable or disable any of the supported cipher suites for both clients and servers. When a particular client and server exchange information during the SSL handshake, they identify the strongest enabled cipher suites they have in common and use those for the SSL session.
Decisions about which cipher suites a particular organization decides to enable depend on tradeoffs between the sensitivity of the data involved, the speed of the cipher, and the applicability of export rules.
Some organizations may want to disable the weaker ciphers to prevent SSL connections with weaker encryption. However, due to US government restrictions on products that support anything stronger than 40-bit encryption, disabling support for all 40-bit ciphers effectively restricts access to network browsers that are available only in the United States (unless the server involved has a special Global Server ID that permits the international client to "step up" to stronger encryption).
To serve the largest possible range of users, it's a good idea for administrators to enable as broad a range of SSL cipher suites as possible. That way, when a domestic client or server is dealing with another domestic server or client, respectively, it will negotiate the use of the strongest ciphers available. And when a domestic client or server is dealing with an international server or client, it will negotiate the use of those ciphers that are permitted under US export regulations.
However, since 40-bit ciphers can be broken relatively quickly, administrators whose user communities can use stronger ciphers without vilating export restrictions should disable the 40-bit ciphers if they are concerned about access to data by eavesdroppers.
Note.
Netscape Console does not support all of the cipher suites supported by Netscape clients and servers. To ensure that Netscape Conolse can control an SSL-enabled server, the server must enable at least one of the following cipher suites for SSL 3.0:
Cipher Suites with RSA Key Exchange
Table 5.1 lists the cipher suites supported by SSL that use the RSA key-exchange algorithm. Unless otherwise indicated, all ciphers listed in the table are supported by both SSL 2.0 and SSL 3.0. Cipher suites are listed from strongest to weakest.
Table 5.1 Cipher suites supported by the SSL protocol that use the RSA key-exchange algorithm
Strength category and recommended use
|
Cipher suites
|
Strongest cipher suite. Permitted for deployments within the United States only. This cipher suite is appropriate for banks and other institutions that handle highly sensitive data.
Netscape Console does not support this cipher suite.
|
Triple DES, which supports 168-bit encryption, with SHA-1 message authentication. Triple DES is the strongest cipher supported by SSL, but it is not as fast as RC4. Triple DES uses a key three times as long as the key for standard DES. Because the key size is so large, there are more possible keys than for any other cipher--approximately 3.7 * 1050.
This cipher suite is FIPS-compliant.
Both SSL 2.0 and SSL 3.0 support this cipher suite.
|
Strong cipher suites. Permitted for deployments within the United States only. These cipher suites support encryption that is strong enough for most business or government needs.
|
RC4 with 128-bit encryption and MD5 message authentication. Because the RC4 and RC2 ciphers have 128-bit encryption, they are the second strongest next to Triple DES (Data Encryption Standard), with 168-bit encryption. RC4 and RC2 128-bit encryption permits approximately 3.4 * 1038 possible keys, making them very difficult to crack. RC4 ciphers are the fastest of the supported ciphers.
Both SSL 2.0 and SSL 3.0 support this cipher suite.
Netscape Console supports only the SSL 3.0 version of this cipher suite.
|
RC2 with 128-bit encryption and MD5 message authentication. Because the RC4 and RC2 ciphers have 128-bit encryption, they are the second strongest next to Triple DES (Data Encryption Standard), with 168-bit encryption. RC4 and RC2 128-bit encryption permits approximately 3.4 * 1038 possible keys, making them very difficult to crack. RC2 ciphers are slower than RC4 ciphers.
This cipher suite is supported by SSL 2.0 but not by SSL 3.0.
Netscape Console does not support his cipher suite.
|
DES, which supports 56-bit encryption, with SHA-1 message authentication. DES is stronger than 40-bit encryption, but not as strong as 128-bit encryption. DES 56-bit encryption permits approximately 7.2 * 1016 possible keys.
This cipher suite is FIPS-compliant.
Both SSL 2.0 and SSL 3.0 support this cipher suite, except that SSL 2.0 uses MD5 rather than SHA-1 for message authentication.
Netscape Console does not support this cipher suite.
|
Exportable cipher suites. These cipher suites are not as strong as those listed above, but may be exported to most countries (note that France permits them for SSL but not for S/MIME). They provide the strongest encryption available for exportable products.
|
RC4 with 40-bit encryption and MD5 message authentication. RC4 40-bit encryption permits approximately 1.1 * 1012 (a trillion) possible keys. RC4 ciphers are the fastest of the supported ciphers.
Both SSL 2.0 and SSL 3.0 support this cipher.
Netscape Console supports only the SSL 3.0 version of this cipher suite.
|
RC2 with 40-bit encryption and MD5 message authentication. RC2 40-bit encryption permits approximately 1.1 * 1012 (a trillion) possible keys. RC2 ciphers are slower than the RC4 ciphers.
Both SSL 2.0 and SSL 3.0 support this cipher.
Netscape Console supports only the SSL 3.0 version of this cipher suite.
|
Weakest cipher suite. This cipher suite provides authentication and tamper detection but no encryption. Server administrators must be careful about enabling it, however, because data sent using this cipher suite is not encrypted and may be accessed by eavesdroppers.
|
No encryption, MD5 message authentication only. This cipher suite uses MD5 message authentication to detect tampering. It is typically supported in case a client and server have none of the other ciphers in common.
This cipher suite is supported by SSL 3.0 but not by SSL 2.0.
|
FORTEZZA Cipher Suites
Table 5.2 lists additional cipher suites supported by Netscape products with FORTEZZA for SSL 3.0. FORTEZZA is an encryption system used by US government agencies to manage sensitive but unclassified information. It provides a hardware implementation of two classified ciphers developed by the federal government: FORTEZZA KEA and SKIPJACK. FORTEZZA ciphers for SSL use the Key Exchange Algorithm (KEA) instead of the RSA key-exchange algorithm mentioned in the preceding section, and use FORTEZZA cards and DSA for client authentication.
|