WatchGuard Breaks Logjam and Protects Encrypted Connections

This week, a group of university researchers disclosed a new vulnerability affecting the Diffie-Hellman key exchange. The Diffie-Hellman (DH) key exchange is a cryptographic method for two systems to establish a shared secret over a public communication channel, which they later use to encrypt their communications. Many encryption protocols, including HTTPS, SMTPS, IPSec VPN, SSH, and other TLS implementations, use it to set up shared secrets.

According to these researchers’ whitepaper, the Diffie-Hellman key exchange suffers from an implementation flaw that attackers can exploit to downgrade your shared key’s strength, making it easier to crack your encryption. To pull off the attack, a bad actor first needs to perform a man-in-the-middle (MitM) attack in order to capture and manipulate your communications with the other host. Once they intercept your communications, the attacker can force the DH key exchange to use the DHE_EXPORT cipher, which limits the shared secret to a 512-byte key.

You may remember me talking about export ciphers in our previous FREAK advisory. Back in the day (1992 – 2000), the United States of America restricted the export of strong encryption to certain countries for political reasons. That meant many encryption products had to ship with weaker “export” cipher suites, which were presumably easier for the US government to crack. The DHE_EXPORT is the weaker cipher that ships with many DH implementations. With modern increases in processing power and the discovery of new cryptographic flaws, the 512-byte keys produced by this export cipher is especially weak today, and easily cracked. In fact, the researchers who found this flaw even allege that state sponsored actors may even be able to crack 1024-bit keys today. In short, you do no want to rely on encrypted connections that use a 512-bit key.

Though this new DH flaw sounds bad, it only poses a medium to low risk. In order to exploit it, an attacker needs to be able to intercept your network traffic. While this might be relatively easy to do on public wireless networks, its more difficult to pull off on wired networks (unless you are a nation state). Nonetheless, you still want to fix the flaw as soon as you can. Here are a few mitigation tips:

• Disable the DHE_EXPORT cipher. If you manage any products that use the Diffie-Hellman key exchange, you should remove the DHE_EXPORT cipher from their list of accepted ciphers. Many products, including web servers, email servers, VPN products, SSH servers, and more, use the Diffie-Hellman key negotiation, so you’ll likely have many products to check.  I suspect many manufacturers will release patches to disable the DHE_EXPORT cipher for you.
• Deploy Elliptic-Curve Diffie-Hellman (ECDHE). This more modern key exchange is more resilient to known cryptanalytic attacks. See the researchers deployment guide for more details.
• Use strong 2048-bit keys for fixed groups. You should generate 2048-bit keys or stronger for DH groups on your web servers. Again, see the deployment guide for more details.
• Update your web browsers. At the time of this writing, Internet Explorer is the only browser that has been patched to not use the DHE_EXPORT cipher. I expect Mozilla, Google, and others to release updates soon. Be sure to update your browsers as soon as patches become available.
• Use WatchGuard’s HTTPS ALG. If you’re a WatchGuard XTM customer, our HTTPS proxy can protect your users from this attack. See the details below.

What about my WatchGuard products?

You may be wondering if your WatchGuard products are affected. The good news is most of our products are not vulnerable to this issue, with the exception on our SSL VPN appliances. Here’s the run down:

• XTM appliances: Not Vulnerable
• XCS appliances: Not Vulnerable 
• Wireless Access Points: Not Vulnerable
• WatchGuard Dimension: Not Vulnerable
• SSL VPN Appliances: Vulnerable.
  • Our SSL VPN Appliance supports the DHE_EXPORT cipher. By default, we don’t allow use of this cipher in the Application Portal, but we do in the Administrative Web UI. You can mitigate this vulnerability by limiting external access to the Web UI, or by proxying the Web UI through the Application portal. We’ll release an update to completely remove the DHE_EXPORT cipher in the future. 

More importantly, WatchGuard XTM appliances can actually help protect you from the Logjam vulnerability, if you use our HTTPS application layer gateway (ALG). Our HTTPS ALG temporarily decrypts HTTPS connections going through our appliance, so it can apply security services, such as antivirus and intrusion protection, to otherwise encrypted traffic. Furthermore, if you are using our HTTPS proxy with deep packet inspection enabled, it performs additional security functions including not allowing the use of the DHE_EXPORT cipher. Even if your users browse with unpatched web browsers that support the weak cipher, our HTTPS proxy will not allow them to establish connections with this weaker cipher. If you haven’t configured the HTTPS ALG on your XTM device, you may want to consider it.

If you’d like more details about this flaw, see the references below:

• WatchGuard’s Daily Security Byte video on Logjam – WatchGuard Blog
• Primary Logjam FAQ page – WeakDH.org
• Academic Logjam vulnerability whitepaper [PDF] – WeakDH.org
• Logjam proof-of-concept examples – WeakDH.org
• Logjam mitigation strategies – WeakDH.org
• Media article covering the Logjam vulnerabilities – Ars Technica

— Corey Nachreiner, CISSP (@SecAdept)

Share This: