Can someone explain what exactly is accomplished by generation of DH parameters?

Question

I'm setting up a node.js server:

https.createServer({
    ...
    ciphers: 'ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH',
    honorCipherOrder: true
}, app).listen(443);

This is a able to achieve a SSLLabs A rating, which is good. Now, it appears that all of the negotiations in the handshake simulation are performed using TLS_RSA_WITH_RC4_128_SHA.

RC4 is resilient against BEAST. If we are vulnerable to BEAST we cannot get an A rating.

I would like to support PFS (forward secrecy) if supported by the client.

Based on my reading I "must generate some randomness" by generating Diffie-Hellman parameters and get that into my certs somehow, before the server will properly implement ECDHE for forward secrecy. I read somewhere that ECDHE is less CPU-intensive than DHE, so that is a plus.

Well, I have a lot of questions. But I will ask the first one:

Why must I generate "some randomness" to append to the certificates, what purpose does it serve, and what does the command actually do? The OpenSSL page on dhparam doesn't tell me a lot about what it actually does.

I have seen this answer and am looking for a more clear explanation (or at least references to relevant reading!).

According to OpenSSL Ciphers it looks like ECDHE is a TLS 1.2 cipher. On Qualys' PFS page it says that ECDHE is supported by all major modern browsers, and yet I only see iOS6 in the results from my SSLLabs test connecting via TLS1.2. I guess I can take the "handshake simulation" section with a grain of salt.

Another question is why SSLLabs rates with an A if I leave the HIGH entry in the cipher list: This would have the server support a connection e.g. TLS_RSA_WITH_AES_128_CBC_SHA (the report indicates as much), which is vulnerable to BEAST! Perhaps because it never tested with a "client" that reports no RC4 support.

One more question: On the OpenSSL Ciphers page the list under TLS 1.2 cipher suites includes:

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256     ECDHE-RSA-AES128-SHA256

Does this indicate that if I do get it connecting with ECDHE that is now vulnerable to BEAST as well due to the use of CBC? E.g. I should switch this to do as Google does: ECDHE with RC4. But the Ciphers page does not include anything that looks like ECDHE-RSA-RC4-SHA. There is however a ECDHE-ECDSA-RC4-SHA. How is this different? Edit: this SO answer mentions that ECDSA is something separate from RSA. I'd like to replicate what Google's doing with the ECDHE_RSA+RC4+SHA as that seems like the perfect blend of performance and security.

More notes (please tell me if I have misunderstood things, especially the statements disguised as questions):

BEAST resilience is controlled through the selection of the symmetric cipher (RC4 vs AES, etc). Modes of AES not using CBC are not supported by many clients? So we should just avoid AES altogether...? PFS is may be obtained through the use of Diffie-Hellman key exchange, and only the modes that include either DHE or ECDHE satisfy this. Only OpenSSL supports perfect forward secrecy. RC4 is faster than AES. RC4 is better than AES (because of BEAST)?

Another edit: Let's see... here is an indication that BEAST isn't something to be too realistically concerned about, though it negatively affects SSLLabs rating. That big "A" looks so good... Let's see... I should probably still put the RC4_128 ciphers in the beginning of the cipher chain if for no other reason that they have not been shown to be "broken", and are faster than AES generally. Anyway I've strayed far away from the original topic which is ECDHE. And how to get the DH parameters properly working with Node/Express?

Answer 1

The traditional RSA-based exchange in SSL is nice in that a random session key is generated and transmitted using asymmetric encryption, so only the owner of the private key can read it. This means that the conversation cannot be decrypted by anyone unless they have the certificate's private key. But if a third party saves the encrypted traffic and eventually acquires the private key, he can use that to decrypt the session key from SSL exchange, and then use that to decrypt the whole session. So that's not perfect forward secrecy.

The key here to Perfect Forward Secrecy is the Diffie-Hellman key exchange. DH is a very cool algorithm for generating a shared key between two parties such that an observer who sees everything -- the whole exchange between the two parties in the clear -- cannot derive the key just from what is sent over the wire. The derived secret key is used one time, never stored, never transmitted, and can never be drived ever again by anyone. In other words, perfect forward secrecy.

DH alone can't protect you because it's trivial to play man-in-the-middle as there's no identity and no authentication. So you can continue to use RSA for the authentication and just use Diffie-Hellman to generate the session key. That's DHE-RSA-*, so for example: DHE-RSA-AES128-SHA1 is a cipher spec that uses Diffie-Hellman to generate the key, RSA for authentication, AES-128 for encryption, and SHA1 for digests.

But Diffie-Hellman requires some set-up parameters to begin with. These aren't secret and can be reused; plus they take several seconds to generate. But they should be "clean", generated by you so you know they're not provided by an attacker. The dhparam step generates the DH params (mostly just a single large prime number) ahead of time, which you then store for the server to use.

Some recent bit of research showed that while "breaking" a DH exchange (that is, deriving the key from the traffic) is difficult, a fair amount of that difficult work can be done ahead of time simply based on the primes. This means that if the same DH primes are used everywhere, those become a "prime" target for well-funded agencies to run their calculations against. This suggests that there is some amount of increased safety to be had in generating your own primes (rather than relying on those that come with your software), and perhaps in re-generating those primes periodically.

An interesting bit is that Elliptic curve Diffie–Hellman is a modified Diffie-Hellman exchange which uses Elliptic curve cryptography instead of the traditional RSA-style large primes. So while I'm not sure what parameters it may need (if any), I don't think it needs the kind you're generating.

See also:

• What is ECDHE-RSA?
• SSL/TLS & Perfect Forward Secrecy

With respect to BEAST
The BEAST attack relies of some artifacts of the block chaining method used with AES on older versions of SSL. Newer versions of SSL do things right, so no worries there. RC4 is not a block cipher, so there is no block chaining. The BEAST attack is so absurdly difficult to pull off that its real-world implications are decidedly nonexistent. In fact, RC4 has some weaknesses of its own, especially when when abused the way the BEAST attack would have to do. So you may not actually be getting any better security.

Certainly forcing TLS 1.2 would solve all your theoretical security problems, while at the same time preventing many visitors from actually connecting. Not entirely unlike using ECDHE.

Answer 2

In a "DHE" cipher suite, the server generates on-the-fly a new Diffie-Hellman key pair, signs the public key with its RSA or DSA or ECDSA private key, and sends that to the client. The DH key is "ephemeral", meaning that the server never stores it on its disk; it keeps it in RAM for the duration of the SSL handshake, then forgets it altogether. Being never stored, it cannot be stolen afterwards, and that's what PFS comes from. Note that this DH business never enters the certificate: the server certificate contains the server's permanent public key, of type RSA or DSA or ECDSA, and used only for signatures.

Diffie-Hellman, generically, is an algorithm computed in a finite group where computations are easy, but discrete logarithm is hard. In the "plain" DH, the group consists in some integers modulo a big prime p, with multiplication as the group law. The DH parameters are the definition of that group, namely the big prime p and the conventional generator g. For security, there is no problem in reusing the same parameters for several key pairs, including using the same DH parameters as somebody else. What is needed is that the parameters are "fair", i.e. that the prime p was generated randomly, and not specially crafted to make discrete logarithm easy modulo that prime.

Generating your own DH parameters is a way to "make sure" that you use properly random DH parameters. It is more ritualistic than scientific, though: the SSL server library should come with default DH parameters which are fine, and you already, by definition, trust that SSL library for not playing nasty tricks on you.

ECDHE follows the same lines, except that it applies DH in another group, namely an elliptic curve. Elliptic curves have some computational benefits, but are less widely supported (yet). The analog of generating your own DH parameters would be choosing your own random curve. Nobody actually does that, because:

• Generating a random curve with appropriate characteristics is a complex and expensive endeavour.
• The computational benefits of elliptic curves partially come from both parties (client and server) being optimized for a specific curve. Generating your own random curve would defeat that.

---

As for BEAST, don't worry too much about it. It is an attack on the client, not on the server, and modern clients include workarounds (the "1/n-1 split", in particular). It is a nice attack, but it does not work anymore. The only thing that the server could do about it was to force an unaware, old client to use RC4 (which is not vulnerable by construction).

Note that BEAST applies only to SSL 3.0 and TLS 1.0. With TLS 1.1 and 1.2, BEAST does not work at all, even if the symmetric cipher is a block cipher in CBC mode.

Answer 3

RC4 is resilient against BEAST.

IT is true that using a stream ciphers avoids BEAST and POODLE, however RC4 has problems of it's own. The keystream has known biases which can leak information.

RC4 was briefly reccomended during a time after beast was discovered but before it was realised just how bad the keystream bias issues in RC4 were.

If we are vulnerable to BEAST we cannot get an A rating.

This may have been true at one point, it is not any longer.

The qualys guys judge beast to be a lesser evil than RC4.

Why must I generate "some randomness" to append to the certificates, what purpose does it serve, and what does the command actually do? The OpenSSL page on dhparam doesn't tell me a lot about what it actually does.

dhparam generates parameters used for conventional diffie-hellman (not ECDH). These parameters are not secret but for DH to be secure they must satisfy some conditions. There are a few reasons you may want to generate your own parameters.

1. The parameters shipped with your software may be too short. While 1024 bit dh has not been publically broken it is suspected that some well-funded attackers may have done so.
2. Much of the work of cracking dh is per set of parameters not per session. So using the same parameters as everyone else lets an attacker reuse their work to crack many sessions from different servers.
3. It is possible to create backdoored parameters that can be easilly cracked by the entity that generated them but look fine to everyone else. The more paranoid may worry that the parameters shipped with their software are backdoored.

Afaict there are no DHE ciphersuites that use RC4. So in your configuration this would only matter if the client supports neither of the ciphersuites you have explicitly identified and instead ends up using one of the tradtional "DHE" ciphersuites from the "HIGH" list.

I would like to support PFS (forward secrecy) if supported by the client.

To get forward secrecy you need to use a DHE or ECDHE ciphersuite, so if forward secrecy is your priority you should put these ahead of any other ciphersuites. For best compatibility and performance you should put ECHDE ciphersuites ahead of the corresponding DHE ciphersuite.

Finally please think very carefully before hardcoding ciphersuite lists into your software. What options are considered best can and does change over time.

Answer 4

The NSA attacks on RSA knobbled the PRNG (random number stuff). It's a fair bet that's not the only PRNG they've messed with. Here's a non-USA hardware-based random generator that might be worth looking into: http://www.entropykey.co.uk/