Abstract
Three versions of SSL, or protocols, are in use. SSL V2 and SSL V3 are standards published by Netscape. TLS V1 is an RFC (RFC2246) published and administered, as are the other Internet standards.
SSL V2 is old and not often used now. It does not support client authentication and has a number of known security weaknesses.
SSL V3 is significantly different from SSL V2 and is now the protocol most commonly used. TLS V1 is a new protocol, very similar to SSL V3, that addresses some security and performance issues discovered in SSL V3.
Both the SSL clients and servers have a list of ciphers, known as the cipher suite list, they are willing to use. During the SSL handshake, the lists are compared and a cipher, normally the strongest, is chosen.
Tip: This article will help you understand how to configure these cipher lists in your HTTP Server (powered by Apache). The theory behind the example used in this section is based upon the IBM Redbook IBM eServer iSeries Wired Network Security: OS/400 V5R1 DCM and Cryptographic Enhancements, SG24-6168. This redbook is a "must read" for your work.
In a perfect world and with modern Web browsers, the negotiation of the suite of ciphers used is transparent to both the client and even your HTTP Server administrator. But, in a Business-to-Consumer (B2C) environment, you cannot control the age and quality of the Web browser.
Contents
The handshake
When a client (that is, a Web browser) establishes a SSL session, the client sends a Client Hello message to the server. Amongst other things, this message contains all the supported cipher suites the browser can handle. A single cipher suite is a combination of an encryption protocol (that is, DES, RC4, AES), the encryption key length (40, 56, or 128) and a hash algorithm (SHA or MD5) that is used for integrity checking. When the server receives the Client Hello message, the server controls and decides which offered cipher suite it will use to secure this particular session.
With no SSLVersion or SSLCipherSpec directives specified, the server accepts anything. That is true for all newer browsers, because they support the handshake correctly. With some older browsers there are some problems due to bugs in their implementation of the SSL protocol at that time.
To "fix" these bugs you can force your clients to upgrade to a more modern version of Web browser. As we said earlier, however, in a B2C environment this is not always an option.
Or, you can control the order that the ciphers will be selected during the SSL handshake to avoid know problems with older (buggy) Web clients.
To actually force a client to work with a specific encryption strength, you have the chance through directives to control what algorithms and key lengths your server will accept. If, for example, your client only supports 56-bit encryption and your server requires at least 128-bit, then the handshake will fail. As a general rule, the SSLCipherSpec directives are good to limit the number of algorithms and key lengths to what you think is acceptable and secure. That, of course, depends on the content to be protected (how sensitive) and the client community you are dealing with.
An example
The CipherSuiteList directive of the HTTP Server (original) was just one directive with all supported ciphers specified from left (preferred) to right. For the HTTP Server (powered by Apache), you have to add one SSLCipherSpec directive per cipher suite from top (preferred) to bottom.
The problem is that Microsoft's Internet Explorer’s (IE) 56-bit SSL implementation has flaws in that it prevents it from negotiating with servers that use a higher encryption than it does, unless you disable a few ciphers on the server side. This bug was released with IE Version 5, and the only fix that Microsoft has is to install 128-bit encryption. To circumvent this problem in the HTTP Server (original) configuration you can use this directive:
CipherSuiteList 0405090A0306
For the equivalent configuration, you would specify in your HTTP Server (powered by Apache) configuration file:
SSLCipherSpec SSL_RSA_WITH_RC4_128_MD5
SSLCipherSpec SSL_RSA_WITH_RC4_128_SHA
SSLCipherSpec SSL_RSA_WITH_DES_CBC_SHA
SSLCipherSpec SSL_RSA_WITH_3DES_EDE_CBC_SHA
SSLCipherSpec SSL_RSA_EXPORT_WITH_RC4_40_MD5
SSLCipherSpec SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5
Attention: The third line SSLCipherSpec SSL_RSA_WITH_DES_CBC_SHA indicates use DES with 56-bit encryption. The four line SSLCipherSpec SSL_RSA_WITH_3DES_EDE_CBC_SHA indicates use 3DES with 168-bit encryption. Why would somebody want a weaker cipher to be chosen before the stronger one? To solve a problem with an older browser. You must be careful to not "oversell" to your clients the strength of your encryption on your site if you make these types of server-side configuration changes.
Special Notices
This material has not been submitted to any formal IBM test and is published AS IS. It has not been the subject of rigorous review. IBM assumes no responsibility for its accuracy or completeness. The use of this information or the implementation of any of these techniques is a client responsibility and depends upon the client's ability to evaluate and integrate them into the client's operational environment.