Can someone explain what exactly is accomplished by generation of DH parameters?
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.
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.