Remediating Logjam: an iRule Countermeasure

#SSL #LOGJAM

Professor Matthew Green of John Hopkins announced a weakness in the SSL Protocol and has given it the name Logjam (see weakdh.org). 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
• NGINX
• 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.