F5 SSL Profile: “Single DH use” not working?

In the paper of the Logjam attack, a sentence about the F5 load balancers confused me a bit: “The F5 BIG-IP load balancers and hardware TLS frontends will reuse unless the “Single DH” option is checked.” This sounds like “it does NOT use a fresh/ephemeral diffie-hellman key for new connections”. I always believed, that when a cipher suite with EDH/DHE is chosen, the diffie-hellman key exchange always generates a new for computing . Hm.

Therefore, I tested this “Single DH use” option on my lab F5 unit, in order to find out whether the same public key (as noted in Wireshark) is used for more than one session.

Some Notes

I am using a F5 VM with version 11.6.0 build 4.0.420 installed. For the following tests, I created a new virtual server (https://test.webertest.net) with an own SSL certificate. Inside the “Client SSL Profile”, which has the default “clientssl” as parent, I only customized the ciphers and options. I captured the raw packets on the F5 root console with:

tcpdump -ni 0.0 -s0 host 2003:51:6012:110::102 -w /var/tmp/testx.pcap

The most confusing part for me is the description of F5 about the Single DH use option: “This option creates a new key when using ephemeral (temporary) Diffie-Hellman parameters. This option is necessary if you want to prevent small subgroup attacks when the Diffie-Hellman parameters were not generated using strong primes (i.e. when using DSA-parameters). Remember, the strength of the Diffie-Hellman key agreement protocol depends on the strength of the prime number used to generate the shared secret key.  If strong primes were used, you don’t have to generate a new Diffie-Hellman key during each handshake, but it’s highly recommend that you do. You should enable the Single DH use option whenever ephemeral Diffie-Hellman parameters are used.”

To be more clear, in this F5 article it is said, that “you can tell the F5 to use a different DH for every connection (see “Single DH” in the clientssl profile).”

However, this is similar to the description of openssl about the SSL_OP_SINGLE_DH_USE option: “If “strong” primes were used to generate the DH parameters, it is not strictly necessary to generate a new key for each handshake but it does improve forward secrecy. If it is not assured that “strong” primes were used, SSL_OP_SINGLE_DH_USE must be used in order to prevent small subgroup attacks. Always using SSL_OP_SINGLE_DH_USE has an impact on the computer time needed during negotiation, but it is not very large, so application authors/users should consider always enabling this option. The option is required to implement perfect forward secrecy (PFS).”

–> Okay, so it is a MUST to have really PFS enabled, though ephemeral diffie-hellman is used anyway.

(By the way, interestingly the openssl documentation says something about reusing DH parameters and how to generate strong primes, which is exactly the cause of the second Logjam finding: “The risk in reusing DH parameters is that an attacker may specialize on a very often used DH group. Applications should therefore generate their own DH parameters during the installation process using the openssl dhparam application. This application guarantees that “strong” primes are used.”)

Test Procedure

I customized the ciphers for the client SSL profile to the following:

DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA

Then, I tested the following three cases by opening and closing the IE 11 and Firefox 38 browsers each five times:

1. No further custom options on the SSL profile
2. “Single DH use” enabled
3. “Single DH use” explicitly disabled (which should be the same as case 1)

After that, I analyzed the pcap files with tshark in order to grep the “public keys” sent by the server in the certificate messages (see screenshot below for a better understanding):

This message displayed with tshark looks like that:

Secure Sockets Layer
    TLSv1.2 Record Layer: Handshake Protocol: Server Key Exchange
        Content Type: Handshake (22)
        Version: TLS 1.2 (0x0303)
        Length: 527
        Handshake Protocol: Server Key Exchange
            Handshake Type: Server Key Exchange (12)
            Length: 523
            Diffie-Hellman Server Params
                p Length: 128
                p: 8eee3b9339c972e32c8df724998bb8024fd2fa23a2e023fd...
                g Length: 1
                g: 02
                Pubkey Length: 128
                Pubkey: 4beb2d368e2ca2a1329f933459be091501545097764418be...
                Signature Hash Algorithm: 0x0201
                    Signature Hash Algorithm Hash: SHA1 (2)
                    Signature Hash Algorithm Signature: RSA (1)
                Signature Length: 256
                Signature: cf05aa7dd5b0b2cb6c435288ea67297d715e47f7dcda1b9b...

I used the display filter with tshark to only show the Handshake Type: Server Key Exchange (-Y …), grepped the public key, sorted the output (sort), and counted the uniq lines (uniq -c). Here are the results for these three cases.

1)

weberjoh@jw-nb12:~$ tshark -r test1-no-custom-options.pcap -V -Y 'ssl.handshake.type == 12' | grep Pubkey:
                Pubkey: 4beb2d368e2ca2a1329f933459be091501545097764418be...
                Pubkey: 4773150d0bf7dc465d6cacd6dd9ccff380bb156c0748e103...
                Pubkey: 4beb2d368e2ca2a1329f933459be091501545097764418be...
                Pubkey: 671ded7f17d37398e208fbfeb160dfe5c525f434dd0cc4f1...
                Pubkey: 4773150d0bf7dc465d6cacd6dd9ccff380bb156c0748e103...
                Pubkey: 81a87088383110db929a21894abb898f5399dd969c0e77ff...
                Pubkey: 4beb2d368e2ca2a1329f933459be091501545097764418be...
                Pubkey: 4773150d0bf7dc465d6cacd6dd9ccff380bb156c0748e103...
                Pubkey: 4beb2d368e2ca2a1329f933459be091501545097764418be...
                Pubkey: 671ded7f17d37398e208fbfeb160dfe5c525f434dd0cc4f1...
                Pubkey: 81a87088383110db929a21894abb898f5399dd969c0e77ff...
                Pubkey: 671ded7f17d37398e208fbfeb160dfe5c525f434dd0cc4f1...
                Pubkey: 4beb2d368e2ca2a1329f933459be091501545097764418be...
                Pubkey: 671ded7f17d37398e208fbfeb160dfe5c525f434dd0cc4f1...
                Pubkey: 81a87088383110db929a21894abb898f5399dd969c0e77ff...
                Pubkey: 4773150d0bf7dc465d6cacd6dd9ccff380bb156c0748e103...
weberjoh@jw-nb12:~$ tshark -r test1-no-custom-options.pcap -V -Y 'ssl.handshake.type == 12' | grep Pubkey: | sort
                Pubkey: 4773150d0bf7dc465d6cacd6dd9ccff380bb156c0748e103...
                Pubkey: 4773150d0bf7dc465d6cacd6dd9ccff380bb156c0748e103...
                Pubkey: 4773150d0bf7dc465d6cacd6dd9ccff380bb156c0748e103...
                Pubkey: 4773150d0bf7dc465d6cacd6dd9ccff380bb156c0748e103...
                Pubkey: 4beb2d368e2ca2a1329f933459be091501545097764418be...
                Pubkey: 4beb2d368e2ca2a1329f933459be091501545097764418be...
                Pubkey: 4beb2d368e2ca2a1329f933459be091501545097764418be...
                Pubkey: 4beb2d368e2ca2a1329f933459be091501545097764418be...
                Pubkey: 4beb2d368e2ca2a1329f933459be091501545097764418be...
                Pubkey: 671ded7f17d37398e208fbfeb160dfe5c525f434dd0cc4f1...
                Pubkey: 671ded7f17d37398e208fbfeb160dfe5c525f434dd0cc4f1...
                Pubkey: 671ded7f17d37398e208fbfeb160dfe5c525f434dd0cc4f1...
                Pubkey: 671ded7f17d37398e208fbfeb160dfe5c525f434dd0cc4f1...
                Pubkey: 81a87088383110db929a21894abb898f5399dd969c0e77ff...
                Pubkey: 81a87088383110db929a21894abb898f5399dd969c0e77ff...
                Pubkey: 81a87088383110db929a21894abb898f5399dd969c0e77ff...
weberjoh@jw-nb12:~$ tshark -r test1-no-custom-options.pcap -V -Y 'ssl.handshake.type == 12' | grep Pubkey: | sort | uniq -c
      4                 Pubkey: 4773150d0bf7dc465d6cacd6dd9ccff380bb156c0748e103...
      5                 Pubkey: 4beb2d368e2ca2a1329f933459be091501545097764418be...
      4                 Pubkey: 671ded7f17d37398e208fbfeb160dfe5c525f434dd0cc4f1...
      3                 Pubkey: 81a87088383110db929a21894abb898f5399dd969c0e77ff...

2)

weberjoh@jw-nb12:~$ tshark -r test2-single-dh-use.pcap -V -Y 'ssl.handshake.type == 12' | grep Pubkey: | sort | uniq -c
      4                 Pubkey: 4773150d0bf7dc465d6cacd6dd9ccff380bb156c0748e103...
      2                 Pubkey: 4beb2d368e2ca2a1329f933459be091501545097764418be...
      4                 Pubkey: 671ded7f17d37398e208fbfeb160dfe5c525f434dd0cc4f1...
      4                 Pubkey: 81a87088383110db929a21894abb898f5399dd969c0e77ff...

3)

weberjoh@jw-nb12:~$ tshark -r test3-single-dh-use-disabled.pcap -V -Y 'ssl.handshake.type == 12' | grep Pubkey: | sort | uniq -c
      3                 Pubkey: 4773150d0bf7dc465d6cacd6dd9ccff380bb156c0748e103...
      3                 Pubkey: 4beb2d368e2ca2a1329f933459be091501545097764418be...
      5                 Pubkey: 671ded7f17d37398e208fbfeb160dfe5c525f434dd0cc4f1...
      5                 Pubkey: 81a87088383110db929a21894abb898f5399dd969c0e77ff...

Just for intereset I displayed the prime number for all three test cases:

weberjoh@jw-nb12:~$ tshark -r test1-no-custom-options.pcap -V -Y 'ssl.handshake.type == 12' | grep 'p: ' | sort | uniq -c
     16                 p: 8eee3b9339c972e32c8df724998bb8024fd2fa23a2e023fd...
weberjoh@jw-nb12:~$ tshark -r test2-single-dh-use.pcap -V -Y 'ssl.handshake.type == 12' | grep 'p: ' | sort | uniq -c
     14                 p: 8eee3b9339c972e32c8df724998bb8024fd2fa23a2e023fd...
weberjoh@jw-nb12:~$ tshark -r test3-single-dh-use-disabled.pcap -V -Y 'ssl.handshake.type == 12' | grep 'p: ' | sort | uniq -c
     16                 p: 8eee3b9339c972e32c8df724998bb8024fd2fa23a2e023fd...

Conclusion

Hm, I am still confused. In all three test cases, the same four different public keys, that is: , are used from the F5 LTM load balancer. Have I tested something wrong? (E.g., must the “TLS context” be restarted?) Or does it really re-use this public keys that often, even though the single DH use is enabled??? Oh oh.

I only tested 10 connections to the server. To be more evident, much more connections should be investigated. However, since I already saw collisions, a wider range of connections won’t be better.

(Thanks to PZO for the previous discussion and information.)