the Short & Sweet openSSL Cipher String (v.0.2):
Preamble:
While going over a bug with Jamie, over on the SourceForge bug tracker, I decided to write a clean and contexual openSSL cipher string. in particular, with the goal of setting out to provide a few much needed characteristics.
Simply put, the idea was to: abstract most complexity, solves common issues with cipher strings and SSL implementation, and to provide a feature rich (but reliable) SSL experience. the general dynamic could be defined as balancing security, scalability, reliability, and industry standard complacency.
While each one of these things, on their own, is rather simple to wrap your mind around… often times the issue rises when those not well versed in this area, or those with a lack of time, try to start building a cipher string that meets each or all of these goals.
When you combine each of the things, the cipher string can often become large, unruley, overly complex, and at times can contain both hidden or obvious pitfalls/falws.
during testing, most services running this cipher string would easily acheive an “A” - “A+” rating from the Qualys SSL Labs test, while also defeating most well know vulnerabilties. however, and please note, individual results may vary (until more users can report their experiences). so feel free to let me know how it works for you.
Details:
More specifically, the general goals of this cipher string consists of (but is not limited to):
- a) PCI Compliance,
- b) Perfect Forward Secrecy,
- c) Fall back mechanisms, *
- d) Support for a wide range of platforms.
- e) and “Forward Compatibility”. **
Fall back mechanisms: [*]
By “fall back mechanisms”, what Is meant is that the cipher list was designed with the intention of avoiding common pitfalls in the typical “copy & paste” method (why this is a problem, i’ll explain afterwards). this cipher list intends to ensure the “strongest”, but also most “practical” (or relevant) block cipher, key exchange, and signature algorithim.
For example, the cipher string was carefully crafted to balance the expectations of PCI Compliance, Perfect Forward Secrecy, Evasion of weak or vulnerable algorithims, and providing support for these things on most any device/software/browser used to communicate with the server.
even further, it will support the use of plain AES/128/256, or even RC4… but ONLY in the event when every single other reasonable option has been attempted. and even when using AES256, this will even go through a fall back procedure, trying to bulk up the signature/MAC spec.
this provide a robusy and security wise SSL experiance for both the adminstrator, and the client.
Forward Compatability: [**]
the “copy & paste” method can easily fall apart in several key areas of concern. for one, its typical that the cipher list you are using was made to take into consideration PCI Compliance. but what if you need to meet another expectation? are you going to switch to another cipher list when you need Forward Secrecy? will this break your PCI Compliance?
and what happens when you find out that Internet Explorer on all the Windows XP machines at the office do not support the ciphers defined in that list? are you going to take the time to combine these lists, hand picking ciphers to meet these requirements? do most people even understand enough, or have the time to learn about block ciphers, key exchange and signature algorthims? and why should this even be nessecary in our current day and age? should there not be some level of abstraction to simplfy this?
the other big problem with doing the “copy & paste” method is that it lacks the ability to have any forward compatibility. if a certain cipher is stripped from openSSL due to migration, upgrade, or a serious security vulnerability… it may still be in your list. and you may forever be none-the-wiser. moreover, and depending on the software or service… it may ever cause bigger headaches. for example, if openSSL refuses to load the cipher list because of a non-existing cipher… will the service fail to load? will all SSL connections to your service break? and will all your customers notice this?
In Conclusion:
Right now it seems virtualmin/webmin has a bug where Perfect Forward Secrecy does not work, when using the default embedded server. so this doesnt really help much, for virtualmin per-say.
However, this should come is really handy for most any SSL Enabled Service. this can be used with ANY software that supports openSSL. typically this includes, but is not limited to: Apache, NGinX, sendmail, postfix, dovecot, proftpd, and other back end server softwares.
as I made clear above, the driving force behind this was that most people just copy and paste cipher lists that they find online. and this has the potential to cause problems. ciphers can grow old. go out of date. bugs and vulnerabilities are found. and most ciphers list, even on very reputable website… are large an unruley.
this cipher list takes advantage the built-in tokens and operators. they aren’t very well documented, and really should be. I had to use some very out of date manuals as reference, and even dig into source code to get some of the latests additions to their specification.
a strong point of forward compatibility, since we are using operators and tokens (and not a long list of exact cipher names…), is that any additions to the openSSL libary, any changes that might happen, and anything that gets removes from the specification… should be automagically reflected in the resulting cipher list. this makes less work for the administrator, more security, and a general layer of abstraction that helps lighten the burden (just a teeny weeny bit!) that admins might have when keeping their servers up to date and secure.
the Cipher Strings:
here is the two ciphers strings which I came up with (version 0.2):
Sort for Speed (i.e. AES128/SHA256):
EECDH:EDH:ECDH:DH:HIGH:MEDIUM:!LOW:!SSLv2:!MD5:!DSS:!3DES:!EXP:!SRP:!PSK:!SEED:!aNULL:!eNULL:!NULL:@STRENGTH:+AES256:+SHA1:+CAMELLIA128:+CAMELLIA256:+RC4
Sort for Strength (i.e. AES256/SHA384)
EECDH:EDH:ECDH:DH:HIGH:MEDIUM:!LOW:!SSLv2:!MD5:!DSS:!3DES:!EXP:!SRP:!PSK:!SEED:!aNULL:!eNULL:!NULL:@STRENGTH:+AES128:+SHA1:+CAMELLIA256:+CAMELLIA128:+RC4
Note: Set your server to enforce the Server Defined Cipher Order to see the expected results…
Final Thoughts:
I hope that this is can be of use to somebody! I figured that no body was ever going to find it on the bug tracker. and that maybe it would be more useful here.
If you want to see the exact ordering, or the original article I wrote for this cipher list… you can view the document over at pastebin. I plan to add this into a repository in time, and when I do, ill be sure to post the URL here.
(Cipher List @ PasteBin: http://pastebin.com/yUB5c7XY)
This has only been tested on more recent versions of openSSL (specifically, that which is provided by Ubuntu 12.04). Results may vary on anything that is not considered a more recent version of openSSL.
and if you decide to use this cipher list, please consider a reply with your experience! or any issues you might have had! you may also contact me via email (at steven@rapidwebs.org), where we can discuss your problem or suggestions.
Thanks for reading! and Enjoy!
