LogJams, DHE Parameters, and Other Obstacles to TLS Excellence

If you're presently volunteering to wear the hat of “SSL/TLS Vulnerability Manager”, then you’ve come to the realization that patching one vulnerability often raises others. In wake of revelations about mass surveillance, many of us moved quickly to implement Perfect Forward Secrecy, or PFS, since this method of encryption is strongly resistant to man-in-the-middle (MITM) attacks. Implementing PFS is as simple as identifying and prioritizing the ephemeral ciphers supported by whatever terminates TLS in our infrastructures. For those of us managing BIG-IP, that meant prioritizing Diffie-Hellman Ephemeral (DHE) ciphers.

Fast forward to last month, and the publication of the LogJam vulnerability. Suddenly, some PFS ciphers weren’t so resistant to those pesky MITM attacks. Particularly, any DHE cipher using so-called export-grade encryption. DHE key parameters of 512 or 768-bit lengths were proven to be vulnerable by academic researchers. The WeakDH team further estimates "that an academic team can break a 768-bit prime and that a nation-state can break a 1024-bit prime". SSL Labs then moved quickly to cap the grade of sites negotiating DHE ciphers with key lengths of 1024 bits or less to a “B”. Since ZDnet has just published an article about how Chrome is now flagging some banks for weak crypto due to SHA1-signed certificates, a “B” grade from SSL Labs may not be something we can hang our hats on.

Since TMOS version 11.6, BIG-IP has prioritized ciphers as such: DHE>RSA>ECDHE. The reason for this ordering is that DHE and RSA are accelerated in BIG-IP crypto hardware, while ECDHE (the high performance Elliptic Curve variant of DHE) is handled by general-purpose CPU cycles. For a time, this priority order enabled BIG-IP administrators to achieve “A” grades right out of the box using the DEFAULT cipher string. However, since BIG-IP uses DHE 1024, that same DEFAULT string in TMOS v11.6 now achieves only a “B”. Here is an example of how to re-order and specify an explicit cipher string which omits the weak DHE ciphers and still maintains an A grade: !SSLv2:!EXPORT:ECDHE+AES-GCM:ECDHE+AES:ECDHE+3DES:RSA+AES-GCM:RSA+AES:RSA+3DES:-MD5:-SSLv3:-RC4

Many of those same BIG-IP administrators have queried the DevCentral community or opened support cases requesting DHE 2048 or better support on BIG-IP. However, much like the shift from RSA 1024-bit key lengths to 2048-bit key lengths, the additional workload, even with chip-based acceleration is at least 5x greater for DHE 2048. Additionally, there are older clients such as Internet Explorer before IE11 an Java before version 8 that do not support DHE 2048. As such, it is no easy decision to implement support for DHE 2048 on BIG-IP. 

Fortunately, all is not lost. Elliptic Curve DHE (ECDHE) performs very well even without hardware acceleration on BIG-IP, because Elliptic Curve Cryptography was designed, in part, to provide greater encryption strength with smaller key sizes. By prioritizing ECDHE in the cipher string, BIG-IP administrators can still easily achieve an “A” grade from SSL Labs.

In the event that we do need to preserve CPU cycles, and leave DHE 1024 as a higher priority, it’s important to understand how BIG-IP handles DH parameters by default. The most alarming weakness revealed by the LogJam research is the re-use of common primes for generating keys. A feature of BIG-IP mitigating use of weak or common DH parameters was recently noted by Ivan Ristic:

By default, BIG-IP automatically rotates DH parameters to prevent exploitation related to parameter re-use and weak or common primes.

While we may still need to explain our “B” grade, knowing how and why BIG-IP handles DHE goes a long way toward offsetting concerns about the potential vulnerability to a LogJam-style MITM attack.

Published Jul 07, 2015
Version 1.0

Was this article helpful?


  • For those interested, DevCentral Moderator John Wagnon published an article on how to improve your SSL that, combined with this article, should get everyone to their A/A+ rating. https://devcentral.f5.com/s/articles/security-sidebar-improving-your-ssl-labs-test-grade
  • @Jie, Single DH is not the default. However, BIG-IP does automatically rotate DH parameters (by default) to prevent exploits do to reuse.
  • Where can I get the technical details of DH parameter rotation that you mention above? Some details around how often and the fact it is on by default (and which versions it is on by default for - if that’s applicable)


    EDIT: Found it after Googling.


    The particular support article that details how often is K16674: TLS vulnerability CVE-2015-4000


    It states:


    The BIG-IP system, by default, uses custom DHE groups that are unique per install and are not static. These custom groups are also refreshed on a regular basis with the interval of regeneration varied by version. The interval is every month on BIG-IP 10.1.0 thru 11.3.0, and every hour starting in BIG-IP 11.4.0. This is enabled by default.


  • James, DH parameter rotation is on by default since F5 first implemented DHE ciphers (in TMOS v11.4.0). The rotation occurs every hour, though this fact is not publicly documented, as far as I can tell.


    The Single DH option is also available in the client SSL profile. Single DH forces the generation of a new parameter on a per-handshake basis. This does incur a non-trivial amount of additional processing overhead, but can be useful in very high security environments.


    Hope this helps.