10

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)?

|improve this question
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

|improve this answer
  • It looks like this case statement would fall through. I assume that's not intentional? – forest Dec 9 '17 at 10:14
  • I don't think it is, but I just copied it straight from the RFC. I think their code examples are just pseudocode, and not expected to be used in production. – RoraΖ Dec 9 '17 at 16:18
6

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.

|improve this answer
  • Interesting. A follow on question: doesn't the client need to know the chosen group size before providing its public value in the Client Key Exchange record? – Eddie Nov 3 '15 at 20:42
  • 2
    The server sends the modulus, generator, and its public DH value in the ServerKeyExchange. The client then learns all of these; the client will send its public DH value in the ClientKeyExchange, which occurs later on in the handshake. (Note that the client must know the complete modulus, not just its size. In DH, all computations must be done modulo the same prime p.) – Tom Leek Nov 3 '15 at 20:45
1

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.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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