What DH Group size do TLS Ephemeral DHE ciphers use?

Question

In SSL/TLS, the Client and the Server have the option to use an Ephemeral Diffie-Hellman exchange to establish a shared secret for which to seed the ensuing Master Secret and Session keys.

In the case of DHE being selected as the Key Exchange between two parties, how do they determine the DH ModP Group size (so that they can then agree upon a P and G number)?

Answer 1

When configuring a server for DHE you must generate Diffie Hellman parameters. You then configure OpenSSL/Apache/Nginx etc to use the DH parameters that you've generated.

The DH parameters to use are sent in the ServerKeyExchange message. After the ServerHello and Certificate messages, but before ServerHelloDone.

The ServerKeyExchange message contains the following:

   struct {
       select (KeyExchangeAlgorithm) {
           case diffie_hellman:
               ServerDHParams params;
               Signature signed_params;
           case rsa:
               ServerRSAParams params;
               Signature signed_params;
       };
   } ServerKeyExchange;

Source: RFC2246 Section 7.4.3

Answer 2

With DHE cipher suites, the modulus size for DH is entirely chosen by the server, with no input from the client about acceptable sizes (this is indeed a defect in the TLS protocol with regards to DHE cipher suites).

Some historical clients (including the one shipped with Java up to and including Java 7) did not support DH modulus beyond 1024 bits. Thus induced some server implementations to stick to 1024-bit DH modulus. However, some others decided at some point that such sizes are too low. Apache+OpenSSL made that particular jump a few years ago; see this for details.

With ECDHE (the elliptic curve version), the elliptic curve to be used is still chosen by the server, but there is a ClientHello extension that allows the client to specify which curves it supports, thus allowing the server to make a truly informed decision.

Answer 3

The server chooses the group and tells the client. The client provides no input to this process.

Most servers will ship with a default set of parameters (prime and generator) but it is reccomended to generate your own for two reasons.

1. Some servers ship with a default prime that is only 1024 bit. This is now considerered too small.
2. Much of the work in cracking dh is per-prime, not per session. So it is good practice to avoid using the same prime everyone else does.

Unfortunately Java 7 and older will fail the handshake if a server uses a prime larger than 1024 bits.

For Java 6 there is no good soloution to this. If you need to support Java 6 clients you have to pick your poison between no forward secrecy for clients that don't support ECDHE or weak 1024 bit DSA parameters.

For Java 7 you can avoid this problem by giving the ECDHE ciphersuites higher priority than the DHE ciphersuites.