On secure SSL: The least every developer should know
Or, the NSA's recommendation for foiling the NSA
The NSA, besides playing the role of Big Brother in the unfolding dystopian saga revealed by Snowden’s leaks, is at the forefront of cryptography research. Being in the business of secrecy, the NSA also has recommendations for keeping things secret.
The first of these, Suite A is naturally a secret, and apparently recommends a mysterious list of algorithms known only to the NSA. However, their Suite B recommendation for general national security use is published as an RFC, and suggests technologies available today in browsers and web servers. Suite B is, for the most part, a short list of recommendations for cipher suites.
The TLS standard and assorted extensions predefine a list of cipher suites. During the TLS handshake, the client sends a list of suites that it will accept, in order of preference, in the client hello message. The server chooses the first one it likes and responds with its choice in the server hello.
A cipher suite consists of a key exchange scheme, a signature algorithm, a block cipher algorithm, and a hashing algorithm for computing the authentication key. They’re usually expressed as a string:
[SSL/TLS]_[key exchange]_[signature algorithm]_WITH_[block cipher]_[authentication hash]
For example, SSL_RSA_WITH_NULL_MD5 recommends a cipher suite that is part of the SSL standard,
using RSA for key exchange, no encryption (NULL), and MD5 for hashing. This offers very poor security,
not least of all because it lacks an encryption method. But what suites to prefer?
Well, let’s examine the NSA’s recommendation, which says that a Suite B compliant exchange
should use one of the following:
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
In english (more-or-less), these cipher suites implement Elliptic-curve Diffie-Hellman Ephemeral key exchange using the Elliptic-curve Digital Signature Algorithm, with AES-128/256 as the block cipher and SHA-256/384 HMAC for the authentication hash.
All of these represent the conventional state-of-the-art for their respective functions. Let’s take a closer look.
Elliptic Curves
Elliptic Curve Cryptography provides much-increased security for a given key size over plain RSA or DSA.
Suite B specifies the use of 2 precomputed elliptic curves (NIST) for 256 and 384-bit keys.
In his recent list of recommendations, Bruce Schneier recommends against using EC key exchange on the basis that, since the NSA had a hand in developing it and computing the NIST curves, it might have some attack against it. However, there is some dissent about this point.
If you’re concerned, you can drop the ECDHE_ECDSA and just use DHE_RSA instead,
but you’d better hope the server isn’t using 1024-sized keys – many fear RSA1024 is an
algorithm that the NSA has broken.
Diffie-Hellman key exchange
Diffie-Hellman is a key exchange method. It allows two actors, each with a public and a private key, to arrive at a shared secret (through math) without either revealing their private key. Have you ever seen that video which illustrates key exchange with paint? That’s DH.
Ephemeral
With standard DH key exchange, a given communication with the same public and private key arrives at the same secret every time. So, if some entity happens to be storing all of your encrypted communications in a database somewhere, as soon as they are able to obtain the secret they can immediately decrypt all of those messages.
By contrast, communications using Ephemeral key exchange will generate a unique secret for each message, making it impossible to bulk-decrypt them.
DSA (DSS)
DSA is a signing algorithm. It’s been in use for quite a while, and is generally thought to be secure for sufficiently large key sizes (2048 and up)
AES-GCM
AES stands for “Advanced Encryption Standard,” and is more technically referred to as Rijndael. It is the winner of the 2001 NIST Advanced Encryption Standard contest, superceding the older DES, and is the current symmetric encryption of record. Nobody ever got fired for using AES, although you might make the no-fly list. The 128 and 256 denote the keysize, and obviously bigger is better here.
GCM (Galois/Counter Mode) refers to the mode of operation used by the encryption algorithm. This is in contrast to the more-common CBC mode, which, unlike GCM, has had at least one known vulnerability be demonstrated.
SHA-256/384
SHA-256 and SHA-384 are one-way hash functions used for message verification. Both are members of the SHA-2 family (contrast with SHA-1). Where MD5 is more-or-less broken, and SHA-1 has had theoretical vulnerabilities published, SHA-2 is as-yet untouched.
Great, so what can I do?
Well, hopefully you’ve learned something already. But here’s a bit more about the practical reality.
Client-side
Your browser is basically responsible for choosing for you, and it will probably get that list
from your os. On my mac, I can examine my list using $ openssl ciphers.
Server-side
The downside to demanding advanced crypto algorithms is that you risk locking out users with less-enlightened clients. Proceed with caution.
Both Nginx and Apache use the list format specified by OpenSSL
Nginx
To just accept the suite B ciphers (and TLS 1.2):
ssl_protocols TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers EECDH+ECDSA+AESGCM;
A more practical configuration demanding only that TLS and ephemeral key exchange be used (Thanks baudehlo):
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA256:EECDH+aRSA+RC4:EDH+aRSA:EECDH:RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS;
Apache
Suite B only:
SSLProtocol TLSv1.2
SSLHonorCipherOrder On
SSLCipherSuite EECDH+ECDSA+AESGCM
Less picky
SSLProtocol TLSv1 TLSv1.1 TLSv1.2
SSLHonorCipherOrder On
SSLCipherSuite EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA256:EECDH+aRSA+RC4:EDH+aRSA:EECDH:RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS