duraconf

duraconf - A collection of hardened configuration files for SSL/TLS services Hopefully this will help you make a more informed choice about what cipher list should be used for different applications. What you find here are recommended configurations, you should seriously consider using these, but you have to make some choices. When you pick a cipher list, you have a couple different options of how you go about it: 1. make a very specific declaration of what is acceptable. This has the advantage of being able to define very closely of what you want, but the disadvantage of having to stay on top of the latest crypto advancements, with every crypto library upgrade. 2. make a general declaration of which cipher list to use. this has the advantage of allowing you to rely on your crypto libraries to make (hopefully) informed choices for you (and to deactivate known bad/weak/recently broken) ciphers while you don't have the burden of ensuring that they are always resulting in a good cipher suite. The disadvantage is that you cannot fine tune what exactly you get in return. 3. A mixture of being specific and letting your crypto library decide from general statements. This can be useful if, for example, you find out that some particular crypto has become too weak, for example you might use a generic list but then exclude MD5, because your crypto libraries haven't removed that yet. 4. Decide on a threat model for possible attacks that may expose an important private key. Ciphers are often offered in a mode that provides Perfect Forward Secrecy. While there are performance considerations, if you run a high security operation where traffic disclosure would be a serious problem, it is an important property to consider. Generally it seems safer to have the crypto library take the bulk of the decision since it should be for the most part fire-and-forget, while the other options require that you always stay up to date on things and tweak as needed. For practical use, and for people who can afford to follow crypto news, a mixture of both is surely a good idea. So start with the general cipher list and when you become aware that something is bad then just add this specific part to your otherwise general cipher list until the crypto library defaults get updated to fix that. Unfortunately, its not possible to come up with one cipher configuration that is going to work for all configurations. There are many different programs that implement different versions of libraries that have different ciphers available. In fact, a different versions of the same program may be linked against different libraries which have different ciphers available. An important configuration issue for service operators and users is understanding Perfect Forward Secrecy. Generally, PFS sessions are computationally more expensive than connections without PFS properties. It is extremely important to remember that using SSL and/or TLS does not ensure that your traffic is encrypted for all time. Generally, SSL/TLS services offer two general modes of operation - one mode is ephemerally keyed and the other is not. A TLS server that only offers AES256-SHA is strong against an attacker who will never recover the secret key used by the server and cannot break AES256. However, if an attacker is able to recover the server's key, the attacker will be able to retroactively decrypt all traffic that has been recorded where the AES256-SHA cipher was used. If that same server uses an ephemeral cipher such as DHE-RSA-AES256-SHA, the attacker cannot recover previous encrypted sesssions without breaking RSA and/or AES256 for *each* session. In both cases, when the attacker has the private key, all future communications with the server are unsafe. Clients generally deal with this by looking up a revokation list or by using something like the OCSP. Realistically, they're in a lot of trouble and that kind of trouble is out of scope. If you're in doubt it's probably a reasonable thing to use DHE or EDH modes unless you have load issues. The cipher lists you will find here actually vary depending on which version of the crypto library that you have. For example, if you were to find this list recommended: HIGH:MEDIUM:!aNULL:!SSLv3:!SSLv2:!MD5:@STRENGTH In openssl version 1.0.1e this will mean the following list of ciphers: $ openssl ciphers -v 'HIGH:MEDIUM:!aNULL:!SSLv3:!SSLv2:!MD5:@STRENGTH' ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384 ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA384 DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(256) Mac=AEAD DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256 DHE-DSS-AES256-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(256) Mac=SHA256 ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(256) Mac=AEAD ECDH-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(256) Mac=AEAD ECDH-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(256) Mac=SHA384 ECDH-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256) Mac=SHA384 AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256 ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256 ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA256 DHE-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(128) Mac=AEAD DHE-RSA-AES128-GCM-SHA2