BolehVPN not vulnerable to Logjam DHE vulnerability

Exclusive ProtonMail "NSA-Proof" E-mail Invites for long term users
May 21, 2015
Google files creepy patent for toys that can watch and record you.
May 26, 2015
Show all

BolehVPN not vulnerable to Logjam DHE vulnerability

Logjam-vulnerability-exposure-chart

VPN Implications

A couple of alarming findings have emerged namely the Logjam DHE Flaw. News reports claims that up to 66 percent of the VPN servers can be vulnerable to eavesdropping by nation-states if they use a DHE key exchange with a key that is 1024-bit or smaller. This means using huge computational power, agencies such as the NSA can decrypt VPN connections that are subject to this vulnerability.

Nevertheless, it is not that easy to do so as certain conditions have to be met:

It takes a lot to mount a practical attack that hinges on Logjam (think: more computing power than the NSA or a major university lab).

1. The attacker must be actively listening to the conversation before it starts — lurking on an airport Wi-Fi near the victim is an example. The attacker must select a victim in advance and actively manipulate the victim’s connection. He cannot vacuum up all the data today and find a victim in it next week.

2. Both the victim and the victim’s online service must use traditional Diffie-Helman key exchange and “export-grade” ciphers.

3. The attacker must be a man-in-the middle on the conversation. The attacker must be in between the victim and the victim’s internet connection already or able to insert themselves once the conversation has started.

4. The attacker needs to spend some time and crypto power in advance to precompute values based off of commonly used 512-bit prime numbers. Or, they need access to a list of precomputed values for the primes that the client will choos

Also:

The main data an attacker would get from a VPN connection is whatever data she could get if there was no crypto. Internal email, internal web page content, phone numbers, email addresses, appointments, names, and so on will all be in the clear.

If the victim is using TLS with an internal system, even though they are connected via the VPN, the attack will probably fail. The attacker would have to detect and tamper with that TLS connection via more man-in-the-middle stuff inside the VPN connection they’re already attacking.

However, notwithstanding the implications of Logjam, BolehVPN is not subject to this vulnerability as we had updated our encryption mechanisms last year to use the 2048 bit Diffie Helman exchange. We continue to be at the forefront of VPN encryption developments and are constantly evaluating the best mix of security and speed.

Browser Implications

Surprisingly as at the date of writing, only Internet Explorer 11 is not subject to this bug as they had patched this a while back. All other browsers are still affected.

You can do a test to see if you are vulnerable by performing a test at Qualys SSL Labs or weakdh.org

To temporarily fix this while waiting for an update, follow the instructions here:

Firefox Instructions:
Disable the insecure ciphers here:
(1) In a new tab, type or paste about:config in the address bar and press Enter. Click the button promising to be careful.
(2) In the search box above the list, type or paste ssl3 and pause while the list is filtered
(3) Double-click the security.ssl3.dhe_rsa_aes_128_sha preference to switch it from true to false (this usually would be the first item on the list)
(4) Double-click the security.ssl3.dhe_rsa_aes_256_sha preference to switch it from true to false (this usually would be the second item on the list)

Chrome Instructions:

Try this plugin. We have however not audited the plugin so it’s at your own risk.

For further details on the Logjam bug, you can read it here. Bruce Schneier also has an excellent article.

0 Comments

  1. krasnal says:

    You might want to double-check your system.

    Here’s what I’m seeing on a Lux server, 94.242.213.252:443

    Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA, 1024 bit RSA

    Doesn’t this mean that you’re using 1024-bit RSA (not 2048-bit) for the DHE control channel?

    • Reuben says:

      Hey krasnal,

      Thank you for your comment. Rest assured that has nothing to do with DHE and more on the RSA keys which we will be upgrading very soon.

      On the server side we see this:
      Diffie-Hellman initialized with 2048 bit key

  2. krasnal says:

    Hi Reuben,

    Good to hear that it’s not an error. I thought there was a general feeling as far back as 2011 (if not before) that 1024-bit RSA keys should be upgraded to 2048-bit asap.

    I did a check of my keys and certificates. The ca.crt is still 1024-bit and you seem to be using MD5 for signing certificates. It certainly looks like it’s time for a serious upgrade.

    • Reuben says:

      Yeap we are aware of the 1024 bit RSA issue but as it requires a total global reissue of all keys, we’ve been holding on this until our new portal is launched then we can reissue with much higher security. 1024 bit still takes a good amount of effort to break.

      This reissue should be pretty soon and in a matter of weeks.

Leave a Reply

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