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.

---