Implementer's notes

Extended Validation (EV) is not the only new feature in the most recent Weekly; we've also improved the certificate database by making it able to download new Roots automatically. This means that we can add new Roots to the Certificate Authority database without requiring users to update their installation.

Root Certificates are one the fundamental pillars of Internet security. They are used to confirm the identity of secure webservers by acting as a trusted third party. The introduction of a third party is what makes it possible for two parties that have had no previous contact to determine who the other is, and, based on that, establish an encrypted connection. That is the true "magic" of Public Key Cryptography.

The problem with Root Certificates has been that before they can be used, each relying party (in particular, TLS clients, as in our case) must have a copy of it. If a party doesn't have a trusted copy of the Root it cannot verify the certificate that the other party sent, and can therefore not make any statement about the identity, nor establish a secure connection to that other party.

In SSL/TLS clients like Opera, much of this initial problem has been handled by the vendor shipping a list of trusted Roots with each installation, as well as some update mechanism to add new Roots when necessary. In Opera, this update mechanism has until now been rather crude, as a new version of Opera would have to be installed by each user.

In this Weekly, we are adding an automatic certificate download capability that works like this:

• A number of frequently used Roots are still shipped with Opera.
  
• If a Web site presents a certificate issued from a Root that is not in the local Certificate store, but is available in the online repository, it will be downloaded and installed in the repository. (Please note that this means that if you delete a certificate rather than marking it as untrusted, it will be downloaded again if necessary.)
  
• If a Root is added to the repository, and is closely associated with another Root, we can instruct all Opera instances to download that root if they have the other Root. This is particularly important in relation to how EV certificate chains have to be organized.
  

The certificates are downloaded from a repository hosted at https://certs.opera.com/, which is also the server hosting the EV information, and the information is refreshed every 6 hours. The certificate files hosted on this server, whose names are constructed from a SHA-256 digest of the CA name and other information that uniquely identifies them, are all digitally signed to prevent forgery.

A separate list in the repository identifies all the certificates that are included in the repository. This list is used to stop Opera from checking the repository for unknown issuers. The list is currently retrieved every time Opera starts, but will later be checked when Opera checks for other updates, that is, once a week when Opera starts.

We are particularly interested in your experiences with this new functionality and would like you to test it in various environments, such as:

• performing an upgrade of a used test installation of 9.2x
  
• clean installs,
  
• whether or not secure sites that worked in 9.2x and previous Kestrel Weeklies work OK in this build.
  

Also, somebody may ask, "Does this mean Opera now have the ability to automatically remove a Root certificate?". Yes, in extreme cases, such as the unlikely event (I hope) of a Root Key compromise, we now have the ability to do what previously would have required an emergency security update.
We also have the ability to add certificates to the new "Untrusted" certificate store, which might be necessary in cases where an important certificate has been issued in error.

As I explained in "NOT in Kestrel #4", the certificate is the passport of the website. What was not significatly mentioned in that article is that if there is any non-fatal problem with the verification of the certificate, or with other related information, Opera (and other clients) will display
a certificate warning.

Problems that cause certificate warnings to be displayed can for example be:

• The certificate issuer is unknown (and it is not possible to discover a link to a known Root).
  
• The certificate is expired
  
• The name of the server does not match any of the servers named in the
  certificate.
  
• Weak encryption keys (now only public keys)
  

These warnings are displayed the first time in a session that you connect to a given server, and would not be displayed again for the rest of the session if the user accepted the certificate.

This has (understandably) caused some irritation when a user is frequently visiting a site causing such warnings to be displayed, and there has been frequent requests to be able to accept such certificates more permanently.

I have been, and still am, skeptical to such an ability, because I think a serious and secure website should not trigger security warnings.

I have, however, decided to meet the requests halfway. In Opera 9.50 it is now possible from the security panel of the certificate warning to "permanently" accept a certificate for the given SSL/TLS server (and port). Although accepted by the user, Opera will (same as before) not display a padlock for these sites because Opera has not been able to properly establish the server's credentials.

The acceptance isn't, however, quite "permanent" (therefore the quotes). A certificate that has not expired will be accepted until it expires (at which time the webmaster SHOULD replace it), and for periods of 90 days at a time after expiration.

Enjoy, but use with caution.

Seasons Greetings! See you in the new year.

The most important security pillar in SSL/TLS is the strength of the method used when agreeing on the encryption keys. If the method used for this is inherently weak, then it doesn't really matter how secure the rest of the encryption we are using really is.

The primary method used for this is the Public Key encryption methods, the most famous of which is RSA. These methods work by breaking the encryption key into two parts; one secret/private key and one public which is known by all (certificates are used to confirm who the public key belongs to). The relationship between these is that a message encrypted by one key can only be decrypted by the other. This means that anything encrypted with the private key can be read by everyone, but one will know that only the secret key could have created the message, and this property is used in digital signatures. Similarly a message encrypted with the public key can only be read using the private key to decrypt, and this is used in SSL/TLS to agree on the encryption keys used for the connection.

The security of this step depends on how difficult it is to break the encryption used to protect the encryption keys. For these methods breaking the private key means you can break all messages protected by it, and that when you have broken the key you can impersonate the owner. The difficulty of breaking an RSA key is generally determined by how long the key is. Given present technology, I estimate that the work doubles for every 25-30 bits that are added to the key length (as opposed to work doubling for every additional bit when attacking keys for a symmetric method, like AES). At present, 640 bit RSA keys have been broken in 5 months using less than 100 workstations, but even the commonly used 1024 bit keys are threatened now and are not recommended for messages that need to be secure past 2010. As a result, Opera will warn (and is the only browser that does) when these keys are shorter than 900 bits.

A way to make exposure of past messages more difficult is to change the key used to protect the messages very often. This means that there are more keys to break if you want access to all messages. With sufficiently strong private keys, massive attack becomes infeasible and even attacking a single key becomes impracticable.

In SSL/TLS these kind of rapidly changing keys are implemented using the Public Key method, also known as the Diffie-Hellman (DH) key agreement. The system most commonly works by having the server send a temporary (ephemeral) DH key (or DHE key) to the client, which then confirms the authenticity of the key by digitally signing it with its RSA key. The client then uses this DHE key to agree with the server on the encryption keys. Given that these keys are changed every few minutes there will be hundreds of keys used by a server every day, making the task of breaking the keys infeasible if the tasks take even a short time. But best of all, even if the RSA key of the site is broken, the attacker won't get the secret parts of the DHE keys. To be able to do this, they would have to break each key.

Given that the RSA and Diffie-Hellman algorithms are based on the same math, they are equally strong for a given key-size. This means that to provide the same level of security for a given connection as the RSA key, the DHE key has to be as long as the RSA keys. This is where an increasing number of secure servers fall short.

Both RSA and DHE secret key operations are very time consuming and therefore reduce the number of connections a server can handle. While most sites are using RSA keys that are sufficiently long, the fact that there are lots of DHE keys have led some vendors to mistakenly think that they can reduce the length of the DH keys so that more transactions can be performed. Most of these reduced keys are either 512 bits or 768 bits long (which Opera warns about), but I have actually seen servers sending 256(!) bit DHE keys (Hint: I estimate that these can be broken in minutes or hours).

What these vendors seem to forget is that not all attackers are interested in every transaction performed at a site. An attacker might just be interested in one individual visiting the site, and in such cases the size of the DHE key becomes significant. If the key is too short it may become economically feasible for the attacker to break the DHE key. This is why Opera also warns about weak DHE keys, which are shorter than 900 bits.

As reports about weak DHE keys seem to increase, I found it necessary to take a few steps to counter this problem.

The first step was to ask the TLS Work Group to specify clearer how these keys are created. In addition, specify what steps a client should take to ensure the DHE keys are adequately secure. This is currently being worked on for TLS 1.2.

The second step was to evaluate the size of the DHE key when we receive it. If the key is shorter than 1024 bits, we close down the connection after sending an Insufficient Security (71) fatal error to the server, and automatically try to establish a new connection where the DHE methods are listed as less preferred than they normally are. By doing this we will most likely be able to establish a sufficiently secure connection using the RSA-only methods instead. If the server still selects a DHE method, then a warning may be displayed if necessary. This extra round trip will usually not take extra time because it will be handled as part of our usual TLS feature testing of the server (watch this space for news about that). A known issue we are working to fix is that for mail servers where this dialog have been shown previously, this will not take effect until the second time you check email, and that the first attempt will fail.

The end result is that (normally) you will no longer see the weak public key warning, except if the site is using a weak key in the certificate. We can't do anything about the certificate keys because the size of that key is selected directly by the Webmaster. If you get any of those warnings, please notify the webmaster!

Further reading about crypto on Wikipedia:

Public Key Cryptography
RSA
Diffie-Hellman (DH)
SSL and TLS
About Keysizes

As I've written earlier, in Opera 9.0 we disabled SSL v2 by default, but if necessary a user could enable it.

In Opera 9.5 (Kestrel) we've taken this one step further, and completly disabled the support for SSL v2. That is, as of Opera 9.5 Opera is no longer able to connect to servers that only supports SSL v2.

There are several reasons for this:

• SSL v2 is OLD. It was added in Netscape 2, back in 1994! SSL v3 replaced it 1996, which means that any service that only wants to use SSLv2 was designed in 1996, or earlier. And it hasn't received a significant upgrade since! Think about what that means about the technology used, and the security of the site...
  
  
• SSL v2 is binary incompatible with SSL v3 and TLS; you cannot send a modern TLS handshake to a SSL v2-only server, it won't understand it. In fact, one of the very few things SSL v2 and SSL v3 have in common is the name! Given new TLS functionality Opera 9.x had already put SSL v2 as the last thing it will try before giving up.
  
  
• SSL v2 itself is known to have at least one major security vulnerability. This particular vulnerability is not present in SSL v3
  
  
• There are few, if any, publicly accessible SSL v2 servers left. A major reason for this is Gerv from Mozilla's campaign two years ago; he managed to convince the hosting company with almost 90% of the servers to upgrade. According to my information Netcraft stopped counting them last year, because there were so few left.
  
  If you do encounter a "secure" site that requires SSL v2, what can you do? Well, I don't recommend it, but you can go back to Opera 9.2x and enable SSL v2. But before you do, perhaps you should ask the system administrator this question: "Why are you running the site with 12 year old software?"