• Articles
    • Editorial Articles
    • Research Articles
    • WatchGuard Articles
  • The 443 Podcast
  • Threat Landscape
  • About
    • About Us
    • Contact Us
    • Contribute to Secplicity

Secplicity - Security Simplified

Powered by WatchGuard Technologies

WatchGuard Breaks Logjam and Protects Encrypted Connections

May 22, 2015 By Corey Nachreiner

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:

Related

Filed Under: Uncategorized Tagged With: Diffie-Hellman, encryption, FREAK, LogJam, man-in-the-middle, MitM, SSL

Comments

  1. jomor57 says

    May 22, 2015 at 10:31 am

    I’m using the HTTPS proxy on my XTM cluster but not doing deep packet inspection/ALG. Am I still covered?

    Reply
    • Corey Nachreiner says

      May 22, 2015 at 10:37 am

      Excellent question, and the answer is no. You need DPI enabled in order for the HTTPS proxy to perform the additional security functionality. I have made a slight update to the test above to make it a bit more clear. Thanks for bringing this up.

      Reply
  2. Gregg says

    September 5, 2015 at 3:23 pm

    I have a T10 running 11.10.2 U1 and HTTPS-DPI proxy. My browsers all show vulnerable when using that proxy, but not vulnerable if I use a bypass packet filter that turns my T10 into a basic NAT router. Why?

    Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

The 443 Podcast

A weekly podcast featuring the leading white-hat hackers and security researchers. Listen Now
the 443 podcast

Threat Landscape

Filter and view Firebox Feed data by type of attack, region, country, and date range. View Now
threat landscape

Top Posts

  • US National Cybersecurity Strategy
  • Here Come The Regulations
  • Successfully Prosecuting a Russian Hacker
  • Cybersecurity’s Toll on Mental Health

Email Newsletter

Sign up to get the latest security news and threat analysis delivered straight to your inbox

By signing up you agree to our Privacy Policy.


The views and opinions expressed on this website are those of the authors and do not necessarily reflect the policy or position of WatchGuard Technologies.

Stay in Touch

Recent Posts

  • An Update on Section 230
  • Here Come The Regulations
  • US National Cybersecurity Strategy
  • Cybersecurity News: Free Cybersecurity Training, TrickBot Group Exposed, Major GoDaddy Breach, and Russia to Legalize cybercrime?!
  • Cybersecurity’s Toll on Mental Health
View All

Search

Archives

Copyright © 2023 WatchGuard Technologies · Cookie Policy · Privacy Policy · Terms of Use