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

  • 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".

    ya i think i wrote the question before SSL labs started capping the grade at B for using RC4

  • tylerl

    tylerl Correct answer

    8 years ago

    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)

    @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.

    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)

    I believe the message presented at is directly related to this answer.

License under CC-BY-SA with attribution

Content dated before 7/24/2021 11:53 AM