Resources for Security Engineers to understand & harden the SSL crypto stack. Written 2016-02. Updated 2017-04
The default out of the box configuration is designed firstly for maximum interoperability allowing any client to connect. They dont want to discriminate and provide you with SSL that you cant use. The second goal is to provide high levels of security by enabling the strongest and fastest ciphers, thus today you will find that the client often connects with AES128GCM using Elliptic Curve Key generation. The third is to reluctantly cut off the oldest ciphers that are deemed weak. For instance long ago we made a decision to not use 3DES as it was the weakest, then when RC4 was deamed insecure, 3DES made a come back. The reason that the oldest clients like IE6 on windows XP support at best SSLv3 with 3DES or RC4, so the options are pretty limited. The problem is that neither of these two should be used if you want performance or security, just SSL for the sake of SSL. SSL Labs maintains an excellent list of clients here. I hope to add to this shortly.
SSL almost needs to be considered a personal statement as per your goals and the content of your website. If you are running a public site which like this provides only information which may as well be HTTP, then the ideal selection is interoperability & performance. If SSL has some issues, well who cares, the risk is limited to a stream mitm only, no user data is going to be compromised. You need to think about why you are using SSL and even if SSL is even required. For instance, if you had a HTTP website which provides public information and you wish to use Secure SSL for the sake of beng secure, then a bunch of your users may not be able to connect. This is why if you browse google, although they use mandatory SSL, they provide the oldest and weakest ciphers as options so that anyone can connect. This is SSL for the sake of SSL. Its a hard call to either alienate potential customers from not being able to open your website, vs getting an A+ in SSL labs sever test to stimiluate your ego. For instance you cant get A+ without HSTS, but in enabling HSTS and forcing HTTPS you turn off the ability to use HTTP, so you cant use HTTP for old clients and have strong SSL for good clients. Its an arguement if SSL is a privelidge or a right. Personally i think its a right and i would rather leave an HTTP version for old clients and then only provide good strong SSL as a statement. As an engineer I want people to upgrade and patch so I will offer strong SSL ONLY and make people upgrade for the right to use SSL.
I like the approach of using a specific list of ciphers that meet the needs of the website. for example:
You can custom test the performance of SSL on your server using "openssl speed". This will test every cipher it has and take a while so specifiying the group or exact will speed things up eg "openssl speed aes" or "openssl speed aes-128-cbc" (CBC is the default AES type in SSL)
Give Preference to:
To get the widest support while still valuing some security, the default of AES 128 in TLS1.0 would suffice.
Give Preference to:
Dont use HSTS if you want 100% browser compatibility. Offer HTTP alternative because it is the only way to offer total interoperability.
To achive good security, you must be prepared to cut off old clients and use fast CPUs to offset the requierments of good encryption.
Give Preference to:
To achive very high end security, you have to cut the ties with old systems, and cut off chrome & firefox.
Restrict to:
camellia (japan) & gost (russia) not supported for obvious reasons
The NSA Suite B is approached with a bit of sceptacism. On one hand how do we trust the recommendations of an agency that goes out of its way to subvert encryption to meet its own need to gather intelligence (or it just screwed up its own encryption), and on the other hand why shouldnt we trust the recommendations of an agency who has gone out of its way to provide guidance on protecting businesses and its partners. For instance the NSA guide to configuring Cisco Routers was an excellent applied security configuration resource. For now lets put fears aside and believe that they have the interests of their partners at hand, and look at the integration with SSL and how we can provide these rigid levels of encryption and push SSL to its limits. On a note I started deriving this from the NSA brief guidance source here, then swapped to the RFC for additional guidance on things implied like PFS(E). On a note, the guidance is by NIST
For NSA Secret (128bit):
Server Settings:Compliant Browsers:
Compliant Ciphers:
For NSA Top Secret (192bit)):
Server Settings:Compliant Browsers:
Non Compliant Browsers:
Compliant Ciphers:
The ISM indicates that RSA is no longer acceptable and all keys must be Eliptic Curve based. The ISM also implies that the limit must be used as the minimum which I appreciate the view of. Therefore in my understanding, GCM must be used which implies tls1.2 only, and the highest strength configuation is currently AES256-GCM-SH384. Therefore TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 would be the only compliant cipher with secp521r.
Security is a priviledge, not a right. To maintain priviledge, you must upgrade and patch your technology, not expect technology to downgrade to you. In other words if youre not patched, you dont deserve SSL. This section was about experimenting with the upper limits of SSL, but is now a blunt minimum.
This Server
Legacy Mode (no GCM or Eliptic Curve)