When a browser and website communicate over a secure connection, they encrypt and decrypt the data using a shared symmetric encryption key; the same key is used for encryption and decryption. In order for the browser and server to make sure they use the same key, they first need to share the key with each other, using another – slower – technique, such as Diffie Hellman (DH) or RSA. This must prevent any eavesdropper from being able to see the key that will be used.

Recently, a new attack on the DH algorithm which is used to exchange secret encryption keys in TLS was presented in this paper. The authors show that 512 bit DH can be attacked by the average Joe with a powerful computer, 768 bit DH can be attacked by bigger organizations with a super computer, and they make a rather good case suggesting that the NSA or other government agencies might already be able to eavesdrop on connections secured by 1024 bit DH.

The first question that arises is: Why have 512 and 768 bit been accepted until now in the first place? Those key sizes have been blocked for years with RSA key exchange, and 1024 bit RSA keys are being phased out, even though the time needed to attack DH and RSA is roughly the same. Well, one reason is (as always) compatibility issues. The other reason is that Diffie Hellman key exchange provides a feature called “perfect forward secrecy” which makes it a less attractive target than RSA key exchange. Or so we thought…

When using RSA to exchange symmetric encryption keys, the secret key is created by the client, and shared with the server by encrypting it using the server’s public RSA key, before sending the now-encrypted secret over. Since only the server can decrypt the secret using the corresponding private RSA key, the secret will be a shared secret between the client and server, and can be used as an common encryption key. The problem with this scheme is that if the private RSA key somehow is revealed, all previous and future conversations using that key can be decrypted by anyone knowing the private key, even if a new symmetric encryption key is created for every conversation. The RSA key pair is only changed when the certificate is replaced, since they are tied to the certificate.

DH is different in that the key is never actually sent over the network. Instead, both the server and client create a secret. Next, both parties run their secrets through a one way function before sending the result over to their pairs. Through some “magical” mathematics both the client and server are able to combine their own secrets with what was received from the pair and arrive at the same shared secret. The big difference from RSA, is that no encryption key was used to encrypt the secret, and breaking one DH session can only be used to decrypt the messages exchanged during that session. All previous conversations must be broken individually. Now, 512 and 768 bit DH are still bad, but have not been considered to be as bad as RSA, until now, due to the forward secrecy property.

As with many of the recent attacks on TLS, the theoretical background for this attack was actually developed years ago, and the attack is yet a case of “connecting the dots” more than developing new groundbreaking cryptanalytic techniques. This time it was the realization that the well known algorithm for attacking DH can be separated into two stages; a computational intensive pre-processing stage that can be done towards all TLS servers sharing some specific DH parameters, and a relatively fast attack stage that is used to attack single TLS connections to servers that share those parameters. Typically the shared parameters are hard coded as defaults into different server implementations of TLS. This preprocessing stage strongly weakens the forward secrecy feature of DH, and means that an attacker only needs to do one heavy computation for a collection of TLS servers, and all previous and future connections to those servers can be decrypted relative easily. Finally, by looking at the state of art of DH attacks, along with NSA budgets and the increase in computer power, the paper’s authors estimate that NSA or other government agencies probably are able to decrypt TLS sessions secured by 1024 bit DH.

Countermeasures

First of all, for users who are still using the legacy Opera 12, you should know that Presto has already been blocking 512 and 768 bit DH for some years, so at present, Opera 12 is not affected, assuming that 1024 bit DH has not yet been broken. However, for various other reasons, such as the lack of process sandboxing, and lack of support for modern cipher suites, we would of course urge users to upgrade to current releases.

Today’s release of Opera 30 for Desktop will block less than 1024 bit DH.

For users of the Opera browser for Android, less than 1024 bit DH was blocked some days ago in a version 29 update. Opera Mini, similarly, has already been updated to block less than 1024 bit DH.

As with most browser products on iPhone, Opera uses the operating system functionality to establish secure connections. Users of iPhone are therefore urged to follow the advice from their operating system’s vendor, and update as soon as possible to a version where shorter DH keys are blocked.

We will of course be looking into the strength of these cipher suites in the future, and our ongoing work may involve retiring 1024 bit DH as well. Since this is used by a large number of websites today, this is something we would hope to do gracefully. However, website owners are urged to take a proactive stance here, and update to stronger bit lengths sooner, rather than later.

Reducing trust in the Certificate Authority CNNIC

A couple of months ago, we were notified that CNNIC had issued an unconstrained intermediate CA certificate which has been used to issue certificates for domains which are controlled by others. These certificates were used in private MITM proxies to intercept and monitor employees’ TLS connections. Many websites use certificates which were legitimately issued by CNNIC. CNNIC has released a list of all these, and these sites will continue to work. In newer Opera versions, new certificates issued by CNNIC will not be trusted until the CA has been re-approved. In Presto based versions, we have reduced the amount of trust we place in CNNIC by no longer accepting EV certification from them. This is in line with the response from other browser vendors, and ensures that innocent websites with legitimate certificates can continue to function, without compromising on security.

Back to top
  • :knight:

    ‘I’m a lumberjack and that’s ok’ this patch breaks logjams

  • A Antov

    My website obviously uses a certificate with a weak key issued from a CA. Until this is fixed some day, to use it with Opera people must obviously access it using http and not https. I am wondering how exactly this makes everyone more secure? Care to elaborate?

    • Håvard Molland

      The certificate is not the problem since the Diffie-Hellman key size is set by the server.

      The website administrators only need to change their server settings, and the website will work again. Instructions are here: https://weakdh.org/sysadmin.html

      Also, note that this is not just Opera. All other browsers are implementing similar blocks. Most browsers based on Chromium will inherit the block once they update to a version with the fix (Chromium 45).

      • stackCrawler

        This will cause half of the websites running on https to change their server settings.

        • tarquinwj

          Thankfully it’s not very many websites at all – almost all sites have already moved away from such short key lengths. However, websites that want to offer secure connections do have to keep their cipher suites up to date anyway, to take account of newly developed ciphers, and research that exposes weaknesses in older ones (which is what happened here). They also have to apply any new certificates when they are re-issued. These are normal things that website administrators have to take care of. It doesn’t happen too often, perhaps things need to be updated once or twice per year on average.

      • A Antov

        Thanks for the quick and detailed reply.

  • Vikont

    There needs to be a way (via developers flags, for example) to disable the enforcement. I am aware of weakened security for some sites but need to connect to them anyways – locking the users out is not a solution because we do not control the server settings! Warning is fine, but locking out is unacceptable – besides, on some sites I may not even care that much about perfect security in the first place.

    Opera is trying to be a nanny-browser when no one asks it to. Logjam is not an easy exploit to, well, exploit, and it’s not like I’m trying to connect to a compromised banking site. With this enforcement policy, Opera found a way to drive its single-digit market share even lower.

    Every good security policy states that at the end of the day security should be in the hands of customers. The product must provide all the tools to enable “perfect” security and flag all known issues, but it must be up to the end user to make the ultimate decision whether to take a perceived risk.

    Please consider providing a workaround for this policy, possibly with a consent from users that they understand the implications of disabling the policy.

    • tarquinwj

      It is not really a good approach to provide a way to disable essential security protection. It makes the rest of the Web unsafe to use, even if the specific site you want to access is not considered important enough to need security. Even if it could be done on a per-site basis, an attacker could just trick a user into adding an exception to their target site, which then allows an attack. If users are given a way to disable protection, a number of them will disable protection without understanding the implications.

      We would prefer to find a way to connect safely to those affected websites instead. In the latest Opera beta and developer, we have added a workaround that works on all of the sites we have tested so far. It basically pretends not to support the DH cipher, and tries to connect that way; websites will therefore choose a different cipher. At least one other browser has already done that a long time ago (not in response to the Logjam issue), and is able to work even with websites which only support a minimal number of ciphers. If Opera fails to connect that way, then it retries with DH enabled.

      We are not aware of any websites that are broken by this approach, and access has been restored to all of the websites we have tested, which were broken by the initial Logjam fix. (The only websites that might possibly remain broken are ones that will also not work in the latest versions of any other major browser, and which are also vulnerable to Logjam. We are not aware of any websites in this category.)

      So give Opera Beta or Developer a go, and see if they fix your problems. You can get them here:
      http://www.opera.com/blogs/desktop/

      • Vikont

        Thanks for the tip, tarquinwj. The approach indeed works with the site in question.

        Are there plans to bring this feature into the Stable version of Opera? The reason I’m hesitant to switch to the Developer stream is there is no mechanism to import data (bookmarks, extensions, etc) from another installation of Opera – only from other browsers, like Chrome, FF or IE.

  • thank you very much, nice article
    Ankara burun estetiği

  • Thanks for the article. Best regards. Güvenlik Kamerası İstanbul