Remediating Logjam: an iRule Countermeasure


Professor Matthew Green of John Hopkins announced a weakness in the SSL Protocol and has given it the name Logjam (see With Logjam, a malicious attacker can get access to the encrypted content of SSL connections that use ephemeral Diffie-Helman (DH) by tricking the server and client to use the 512-bit ephemeral keys. Some servers support a special export mode that uses 512-bit keys specifically and this is where Logjam comes in. An attacker able to manipulate traffic between a browser and a vulnerable server can use Logjam to force a downgrade to the weaker 512-bit key. The resulting connection must then be cracked in real-time by the attacker. The John Hopkins team leverages pre-computation against implementations that use static DH keys to achieve that real-time break.

Logjam isn’t a five-alarm fire like Heartbleed. According to the Green, only about 8% of the busiest websites in the world are affected. Of more concern is the possibility that 26% of SSH servers may be vulnerable, and 66% of (other vendors’) SSL VPN aggregators.

However, if you’re reading this, you’re probably an F5 customer worried about your commercial, educational or government website.

So Is Your Site at Risk?

Ivan Ristic has modified the SSL Labs analyzer to detect vulnerability to Logjam. A quick visit to the site will tell you if your site is vulnerable.

The weakdh site also has a testing service.


Long-Term Remediation

SSL vendors around the world will be issuing patches, and of course you should pick them up and apply them when they are available. The weakdh site has a partial list of common vendors with vulnerable software, and instructions on how to remediate for each.

  • Apache
  • Tomcat
  • IIS
  • Lighthttpd
  • ...and others

What is F5's Logjam Status?

In general, F5 scores very well against Logjam. Our NATIVE cryptosystem uses custom groups for ephemeral key generation and EXPORT ciphers are off by default. This is likely why less than 0.1% of BIG-IP servers are potentially vulnerable (in a sample of the top 100,000 busiest websites in the world).

The 0.1% of customers that are using the OpenSSL compatibility mode (“COMPAT”) were vulnerable to Heartbleed, POODLE and all the previous SSL attacks of the last year. Let this be another prompt to see if they can get off of OpenSSL and on to the F5 custom NATIVE stack instead. For those customers, patches are available at the schedule listed in solution 16674.

F5 servers can also be configured with a short handshake timeout (i.e. 10 seconds). A short timeout makes a real-time break much harder than implementations that allow the attacker several minutes.

If you are using F5 to terminate your SSL, you have little or nothing to fear from Logjam for your website, especially if you bound the handshake timeout. The majority of HTTPS applications used by F5 customers fronted by BIG-IP are protected by its SSL code.

iRule Countermeasure to Block Logjam

There may be reasons to have BIG-IP load-balancing at layer 4 to a pool of HTTPS servers instead of doing the termination itself. These include:

  • Using a pool of servers with a security policy restricting private keys to origin server hosts.
  • Using BIG-IP as an ingress point for multi-tenant SSL sites (using SNI and different keys).
  • Using a virtual load-balancer to front a pool of virtualized SSL sites.

If any of these cases apply to your organization, F5 has an iRule to detect and block Logjam attacks. Written by Jason Rahm a the DevCentral team, the iRule very similar to one that he wrote long ago as a demonstration of the binary scan command. He's done some testing on it and it seems to block requests for export DH ciphers while still passing other traffic.

In Jason's testing, the iRule was able to sustain 9,000 new connections per second with logging off. If you turn logging on, you'll see the following message when it blocks a Logjam attempt.


May 21 13:27:21 ltm1 info: Rule /Common/logjam: TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA matched DH Export Cipher, rejecting

The iRule is blocking SSL clients that attempt to negotiate any the DH ciphers defined in this data-group (from rfc2246):

TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0B }; TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0E }; TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x11 }; TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x14 }; TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x17 }; TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 };

The iRule makes use of the powerful iRule primitive, binary scan, which it uses to pick apart SSL connections passing through the virtual server.

If you want to do logging, I suggest that you tweak the iRule to include support for the high-speed logging (HSL) facility. HSL is easy to set up and will retain the iRule performance. Otherwise expect to see a 10-20% performance decrease if you log locally.

DevCentral Codeshare: Logjam Mitigation iRule


What about 768-bit and 1024-bit DH Keys? That topic, my friends, is even more complicated that Logjam, and I (or another F5er) will tackle that in a different post.

To summarize the remediation options of the 512-bit Logjam attack: if your BIG-IP is terminating your SSL, use the NATIVE stack (not EXPORT) and set a short handshake timeout in your clientssl profile. If your BIG-IP is load-balancing to servers terminating their own SSL, use Jason's iRule to keep Logjam out of your network. Finally, use one of the Logjam test sites (above) to make sure that your remediation is taking effect. Good luck.

Published May 23, 2015
Version 1.0

Was this article helpful?


  • EvanH's avatar
    Icon for Nimbostratus rankNimbostratus
    I appreciate the update and on how LogJam impacts F5s. However, I'd like to request that you expand on the statement "Our NATIVE cryptosystem uses custom groups for ephemeral key generation". Does this mean the same custom DH groups are used for every F5 device? Is it possible to generate new custom groups? Lastly, the LogJam paper also calls out that 1024bit DH groups are vulnerable to state sponsored actors and websites who include that in their threat model should be using 2048bit DH. Unfortunately, there is no mention of this in your article and seems to be consistently under played. I'd urge others who are concerned about the lack of greater than 1024bit DH in F5s to add their names to RFE 435231 - "RFE: LTM Support for higher-bit DH keys"
  • Different devices don't share DHE groups and any given device regenerates its group often. This feature is not configurable and cannot be disabled. HA cluster of nodes will share the groups within HA, but they are likewise regenerated often. If DHE 1024 is insufficient, please consider ECDHE P-256.
  • @EvanH; Building on brainhub's response, the NATIVE cipher suites are version and hardware/software dependent. We're expecting the BigIP admin to have this knowledge in hand when referencing the topic. Our F5-validated and official support stances can all be found at In this case, the NATIVE suites for different TMOS versions can be found here: You can also create custom cipher "lists" for the SSL profiles and then assign them to new templates and is also available via the support web site, here's a good starting point for all things SSL. Related to the lack of data related to DH above 1024. I've asked F5 internal to review the LTM Support for higher-bit DH keys (I was in that thread) because I think the denial for support mentioned at the bottom was misleading. However, anything official to F5 support will be on the support site. The DC team will republish anything related to this just to ensure audience awareness and publish back to that original article too. Hope this helps answer a few of your questions. *this does not save formatting well, I'll have that fixed!*