Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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

share|improve this question

3 Answers 3

up vote 7 down vote accepted

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.

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.

I don't have all the answers here, but I'll keep looking and update this answer when I know more.

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.

share|improve this answer
    
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 Jun 30 '13 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 Jun 30 '13 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 Jun 30 '13 at 6:19

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.

share|improve this answer
    
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 Jul 1 '13 at 17:20

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/

share|improve this answer
    
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 Dec 25 '13 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 Jan 14 at 11:01
    
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 Jan 14 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 Jan 14 at 22:42

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.