Static Pages

Sunday, September 13. 2009

The Problem

Securing network services with SSL is, in general, a good idea, if you can spare the CPU cycles. Especially personal data should always be protected while in transit via the network. But it may not be enough to simply enable SSL in the service (be it Apache, Lighttpd, Cyrus IMAPD or something else) to get a reasonably secure connection.

SSL is a cover phrase for a wide collection of protocols and crypto algorithms. There are at least three protocol suites in use (SSLv2, SSLv3 and TLSv1), which between them support tens of different crypto algorithms with different strengths. Not all of those are still suitable for serious use today.

A list of the ciphers supported by the popular OpenSSL library, which is used by many projects to handle SSL, can be obtained with the following command:

On my notebook (running Fedora 11) this produces a list of 62 ciphers. The number of ciphers supported changes with the version of OpenSSL, so other
systems may display a different list.

During an SSL handshake between a client and a server the cipher to use is negotiated between the two machines. In practical terms this means that the client send list of ciphers it is able and willing to use to the server, the server compares this list with it’s own list of supported ciphers and, if a cipher supported by both sides is found returns it’s choice to the client.

Defaults

Unless something else is configured, a server using OpenSSL uses the “DEFAULT” group of ciphers. The content of this group can also change between versions of OpenSSL. The value for the installed version can be queried:

This list is shorter than the list of all ciphers above, containing 44 ciphers on my notebook. This list is not entirely nonsensical. It does not contain ciphers without encryption (yes, that is a valid mode of operation for SSL), it does not contain ciphers without authentication (which would allow for Man-in-the-middle attacks). It does, however, contain ciphers whose strength in this day and age must be questioned. These include the so called “export” ciphers.

These ciphers stem from a time when it was illegal to export software from the United States which supported strong encryption. So software supporting encryption (for example web browsers, like the venerable Netscape Nagivator) destined for export only supported watered down versions of the strong encryption variants, mostly by supporting shorter keys. Fortunately it is no longer illegal to export strong crypto from the United States, and hasn’t been for years, but for compatibility reasons OpenSSL is still willing to negotiate these weak ciphers with a client.

Another weak candidate is the DES algorithm. It was made a standard in 1976 (which is an eternity ago in IT terms). Although it was never cryptographically broken, it’s key length of 56 bits made it increasingly more vulnerable to brute force attacks as faster CPUs became available. Since the Electronic Frontier Foundation demonstrated a custom-built DES cracker in 1998, built for $250.000 and able to brute-force a DES key in under two days, DES has been effectively dead. But, for compatibility reasons, OpenSSL is, by default, willing to negotiate DES as a cipher.

OpenSSL can be told which ciphers to offer in an SSL negotiation, and thankfully most programs using OpenSSL offer configuration statements so the admin can change the default settings.

Selections

Which ciphers should be used then? Let’s start with all the ciphers supported by the SSLv3/TLSv1 cipher suite (which every program offering SSL should support, the use of SSLv2 is strongly discouraged due to vulnerabilities). And we only want ciphers which offer high security (which in OpenSSL terms means more than 128 bits key length, plus some ciphers with 128 bit keys). To be on the safe side we also explicitly disable SSLv2 ciphers, so they cannot be reintroduced later:

On my notebook 14 ciphers remain. For comparison, on my web server (running CentOS 5) this selection only produces 6 ciphers, due to an older version of OpenSSL.

There is, however, two problem with this list. First, it does no longer contain the export or simple DES ciphers (which was kind of the point). This means that SSL services secured with this selection are no longer available to SSL client which only support export grade ciphers. This is a good thing, as these clients are insecure and need to be replaced with something more recent. Depending on the details of the service this option may not be available, though. Please check if these old ciphers must be supprted further before turning them off.

The second problem is Windows. In detail, Windows versions before and including Windows XP. The crypto libraries shipped with these versions do not support newer crypto algorithms (like AES), so there is no overlap between the set of algorithms supported by the server and those supported by the client. These crypto libraries are primarily used by Internet Explorer, Outlook and Outlook Express, so these programs on Windows XP and earlier will not be able to negotiate an SSL connection to a web or mail server. Other web browsers and mail clients (like Firefox and Thunderbird) usually ship with their own crypto libraries which do support modern algorithms, and are not
affected. The system crypto libraries in Windows Vista and Windows 7 are also not affected.

If support for older Windows versions cannot be dropped (likely), the cipher list needs to be extended by some RC4 ciphers (which Windows does support):

This brings the number of ciphers up to 19, the new RC4 ciphers are added at the end of the sorted list.

Configuration

Now that the cipher list is complete the various services that use SSL need to be configured to use it. Instructions how to do this can be found in the documentation, examples for some services are below.

Exim

Add the following line to the global (first) configuration section and restart Exim:

Good stuff, thanks a lot!
BTW, once you are done you can check the new config with this great tool. It will list the ciphers and complain if it finds insecure ones.
https://www.ssllabs.com/ssldb/index.html

To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly.Enter the string from the spam-prevention image above: