I'm setting up a node.js server:

    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:


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?

  • Since one point was left hanging: ECDHE is not a ciphersuite. There are 16 ECDHE suites, 8 that can go back to SSLv3 and 8 new in TLSv1.2 only. What requires 1.2 is authenticated encryption (GCM or CCM) or SHA-2 HMAC and/or KDF. ECDHE suites with AE or SHA-2 require TLSv1.2, ECHDE suites without AE or SHA-2 don't. Yes ECDHE-RSA-RC4-SHA exists; see the 3rd group in "Elliptic curve cipher suites". Commented Aug 10, 2014 at 12:31
  • An article about RC4 that you probably should read: community.qualys.com/blogs/securitylabs/2015/04/23/…
    – BgrWorker
    Commented Sep 2, 2015 at 7:16
  • ya i think i wrote the question before SSL labs started capping the grade at B for using RC4
    – Steven Lu
    Commented Sep 2, 2015 at 7:19

4 Answers 4


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:

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.

  • Interesting. Are you saying that ECDHE does not require the generation of that prime? I did notice as I ran openssl dhparam -rand - 1024 that it generated for me a "1024 bit long safe prime, generator 2". Now it does seem based on this that node.js's support of ECDHE is not quite there. I think it would be smart for me to go with nginx with node running behind that. It should be a lot more mature. Either way i probably also need to read up more and generate my keys and certs using openssl the proper way. (been just trying things till they work)
    – Steven Lu
    Commented Jun 30, 2013 at 5:55
  • @StevenLu There's not a lot written on the subject, but from what I've read, ECDH is based on curves, not primes, so I don't think the traditional DH params will do you any good. This is all based on reading, and not on experimenting, though.
    – tylerl
    Commented Jun 30, 2013 at 6:02
  • Yes there does appear to be some specific setup needed to get ECDH-related things working (and the github discussion for joyent/node is about that, so this makes a good bit of sense now). The details are totally unclear though so time will tell. As for me... My app isn't anywhere near completed so I'll just be happy with my "A" rating now, and wait for the smart folks to iron the kinks out. And also take a stab at nginx (though, really, once node is robust enough, i don't see why not just stick with node)
    – Steven Lu
    Commented Jun 30, 2013 at 6:19
  • I believe the message presented at weakdh.org is directly related to this answer.
    – Steven Lu
    Commented Oct 19, 2015 at 15:13

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.

  • An answer from the master! awesome. This summarizes the topic quite nicely, though I guess the specific information I'm after is related to getting this stuff working under node.js. I now realize that that would be more of a StackOverflow question.
    – Steven Lu
    Commented Jul 1, 2013 at 17:20
  • 1
    "It is more ritualistic than scientific, though: the SSL server library should come with default DH parameters which are fine" unfortunately the default dh parameters are often only 1024 bit which is within the reach of state level attackers to crack. Furthermore shared parameters allow the attacker to reuse their cracking effort on many servers. Commented Dec 8, 2015 at 4:35

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.


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/

  • Well, you're going to have to be a lot more specific. A PRNG isn't supposed to be used for cryptography, isn't this rule #1 of cryptography? That product actually does look useful, but I'm almost certain that this isn't an answer to the original question.
    – Steven Lu
    Commented Dec 25, 2013 at 5:31
  • The PRNG is what's used to generate all the keys, that's why the NSA tricked (or, as with RSA, paid $10M) people into using their own version - so they don't have to crack the crypto, because they've already got a backdoor into the way you created your key. They've also had their hand inside the "standardization" of elliptic curves (causing weak and probably backdoor-enabled versions to be used extensively). This is relevant to the original question, because he's trying to set up PFS. You need to choose algorithms and keygen techniques that are safe, or else it's all a waste of time trying.
    – anon
    Commented Jan 14, 2014 at 11:01
  • 1
    Okay, I can see how this is tangentially related, but my question nevertheless has nothing to do with "the use of a knobbled PRNG". I think that the question is specific to a different part of the crypto stack from the RNG part which you have called into question. Then you go on to say "[the NSA]'ve also had their hand inside the 'standardization' of elliptic curves..." without producing any references. So, unless I misinterpret something, essentially some hand-waving followed by vague lamentations of futility and defeat. Not particularly helpful...
    – Steven Lu
    Commented Jan 14, 2014 at 22:26
  • In addition to those points I want to indicate that my questions are specific to open source implementations (OpenSSH et al.) and not e.g. RSA (the company, not to be confused with the algorithm)'s implementations. @anon thanks for providing some reasons for why that is. Whether or not these sordid tales of sums of money being paid for implementing backdoored systems are true, they don't affect those of us who already know not to trust those types of products.
    – Steven Lu
    Commented Jan 14, 2014 at 22:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .