Skip navigation.

Implementer's notes

What might get caught in the gears under the hood?

Posts tagged with "encryption"

"Nobody checks the padlock" debunked by Opera users

, , , ...

There's been a number of criticisms directed at the padlock over the years, some of which may be correct, to some extent, at least.

One objection has been that users misunderstand the padlock's meaning, thinking it is an indicator of trustworthiness, rather than a protection rating for the connection.

Another objection (which flies in the face of the first), is that "nobody checks the padlock".

Well, I can't say much about the correctness of the first objection, but the past couple of weeks a growing number of Opera users have been working hard at debunking the second one.

In Opera 9.50 we added some new security features, and changed a some others. Two of these are the following:



Both of these turned out to encounter unexpected problems, not due to bugs in our implemenation, but at the CA side. In all cases the problem cause full validation of the certificates to fail, and as a result Opera reduces the security level of the connection so that a padlock will not be displayed. Quite a lot of people noticed.

For OCSP we encountered problems with at least three different brands of OCSP responders. These responders did not respond correctly when we sent a request for infromation about a certificate. It wasn't until a couple of weeks ago that the vendor for one of them discovered the reason for the problem, their expectation of input format was wrong. According to my information they have developed a patch, and I assume they are doing QA on it now, before sending it to the two (or more) CAs that are affected by this. The others have shown up recently and I do not have good information about the causes.

With CRLs we encountered two problems. Just before 9.50 was released we got the first reports about the first case, but it was not until a few days after the release that we got an overview of the situation.

It turns out that one specific CA created an intermediate certificate a few years ago for one of their certificate hierarchies. This certificate included an incorrect URL for where we should go to fetch the CRL, so when Opera fetches the CRL it gets a CRL created for a different hierarchy than the one being verified. As a result Opera's ceritificate validation code can't find the right CRL, and this step fails. This certificate became installed on thousands of servers before the mistake was discovered, and despite a campaign to replace the certificates, several hundred sites (many of them banks) still use the old certificate.

In another case, which came to light last week, another CA have issued an intermediate certificate directly below their root that does not contain a URL for a CRL, but the sub-ordinate certificate issued from that intermediate does specify a CRL. As Opera's certificate validation code expects that if one certificate have a CRL they all use CRLs, validation of the topmost intermediate certificate fails because it can't find the CRL for that certificate.

What can be done about this?

  • About the OCSP issue, we wait for the vendor patch, but in Opera 9.51 we have added an override that lets us use the certificate update system to specify which OCSP URLs that must use the old POST method. In addition one CA also deployed a workaround.
  • About the first CRL issue, the websites need to update their installed certificates, in the second case the CA must also issue a new updated certificate. While waiting for that, in 9.51 we are adding a similar override mechanism as for OCSP, by specifying extra CRL download locations for specific CAs. In the second case we might also be able to fix the issue if the CA has a root for that particular CA name by distributing it to all installations that access the affected sites (that is not a realistic option for the first case).


These changes will be active in the upcoming Opera 9.51 RC2 (Update: Now available), and is already active in the online certificate repository. You will get the updates the next time Opera checks for updates, or if you use Help->Check for updates.

Update July 9: There are some sites with certificates that does not provide any CRL or OCSP information in the site certificate, while the rest of the certificate in the chain have CRLs. Due to a minor bug, and restrictions in the override functionality, the override for that will not become active before 9.52 has been released. At present we are only aware of 10-20 sites affected by this.

Lowering the EV bar

, , , ...

Last week at the W3C's Web Security Context Working Group's meeting at Opera HQ here in Oslo we discussed what should be the criteria for displaying the Extended Validation (EV) indicator, or the Augmented Assurance (AA) indicator, as the WG has decided to call this technology.

As I have said earlier, we are of the opinion that the EV indicator should not be displayed unless all content is loaded from EV servers.

The opposing view is that, so long as all content is loaded over secure connections, the displayed document is what the author of the main document intended (bugs, vulnerabilities, and all), and that it is therefore only necessary to verify that the main document is served from an EV server, as this will provide the information necessary to identify the author.

The decision of the WG was in favour of the less restrictive position: if an AA/EV document loads all resources over strongly TLS-protected connections, then the document can be displayed with an AA/EV indicator.

In the interest of providing a common user experience with respect to EV we have decided to follow this recommendation, and today's Kestrel snapshot include this policy change.

We have, however, left the old logic in place, controlled by a preference that can be updated remotely. This permits us to quickly change to a stricter mode if the consensus about what constitutes an AA/EV site changes in the future.

As a consequence of this policy change a large number of sites, such as Paypal, with mixed EV and non-EV content will now get the "Green Bar" in Opera:

New^W NOT in Kestrel #4: As many warnings about unknown certificate issuers

, , , ...

One of the most important parts of SSL/TLS, as it is used in browsers, is the use of certificates to identify the website you are visiting, and to identify the keys used to agree on the encryption keys used for the connection.

The certificate is the website's passport, and like a passport it is issued by an authority trusted by the people checking them. For passports this is the government of a country, for certificates it is a trusted Certificate Authority (CA).

As with passports, there are a lot of things that have to be checked to make sure the certificate is not forged.

Each certificate contain, among other things the name of who the certificate is issued to (the website); the public key of the website; who issued it (the CA); and a digital signature of the data in the certificate, which is signed by the CA.

To verify the signature the browser must use the public key of the CA to decrypt the signature (which could only be created by using the associated private key), and compare the result with the calculated "checksum" of the certificate. The public key is stored in another certificate issued to the CA - the CA certificate.

There are two types of CA certificates, the ones that are signed by yet another CA, called Intermediate CA certificates, and certificates signed by the CA itself, which are known as the Root Certificates or Self Signed Certificates.

The Intermediates CA certificates are verified using the public key of the signing CA, while the Root CA certificates are verified using the public key in the certificate itself.

The Root CA certificate is a special case. By itself it only verifies that somebody claiming to be the named issuer issued the Root Certificate, and by extension vouches for the named identity in the certificates issued from it. But that does not carry any real assurances.

To be sure that the Root CA is valid the signature on the certificate have to be verified by a trusted copy of the Root Certificate, stored in the client's list of such certificates. These certificates are usually shipped with the client, and are accepted and trusted by the vendor to be reasonably careful about who they issue certificates to and how they store the private key. The user can elect to not trust some of these roots, and may add his own list of certificates.

Only a certificate and its associated certificate chain that can be verified and traced back to a Root in the Trusted Root store on the client is accepted automatically. If a certificate cannot be verified because the signature does not validate this is a fatal error; if we can't trace the certificate to a known root we display a certificate warning.

A problem often encountered is that a web site gets a certificate from a CA that is issued from an Intermediate CA (Most CAs do this now, for convenience and security reasons, as well as for selling CA certificates to CAs without their own root or to cross-sign roots) but the web site administrator forgets to install the Intermediate CA certificate on the server. This means that the client will not be able to trace the certificate to a known Root, even if it has the Root in its repository, because clients usually do not, and are not expected to, know specific Intermediate CA certificates; the result (for the user) is an unexpected Unknown Issuer certificate warning.

SSL/TLS servers that do not send intermediate certificates are actually not operating in compliance with the SSL/TLS standard. The standard requires the server to send any CA certificates it cannot reasonably expect the client to have already, and the only thing it can expect the client to have is the root certificate, and not any intermediates.

There is however a mechanism (called Authority Information Access, AIA) defined in the specification of the certificate format that let the CA specify a "CA Issuer" download location for the Intermediate CA certificates. This mechanism is already used by at least one other browser (which neatly explains why so many badly configured sites get past testing), and now Opera 9.50 also use this mechansism.

When Opera 9.50 encounters a site with a certificate chain that is missing an Intermediate CA certificate linking it to the Root, but the certificate specifies an AIA issuer download location, Opera will download the specified certificate. If the verification then succeeds (without other incidents) to link the certificate with a known root, the certificate will be accepted as normal, and the intermediate CA certificate will be "cached" in the new Intermediate CA certificate store in Opera's certificate manager for future reference, to avoid downloading it again later.

What this means is that you will no longer get any certificate warnings about unknown CAs when the certificate is issued from a root and a CA that also includes an AIA issuer download location for the intermediate certificate(s) for the Intermediate CA(s) that issued the certificate.

Special thanks to Gary and Les in Verisign for helping me debug this new functionality.

New^W NOT in Kestrel #3: As many warnings about weak temporary public keys

, , , ...

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

New^W NOT in Kestrel #2: "Export"-grade encryption is junk(ed)

, , , ...

SSL v2 is not the only old encryption capability that is no longer supported by Opera 9.5, also known as Kestrel. We have also removed support for 40 and 56-bit encryption. Like SSL v2 these methods have been disabled by default since v9.0

There are several reasons for this move:

  • 40 and 56-bit encryption methods are "soooooooo" last century. These methods were defined as a way for US based browser vendors to be able to distribute their SSL enabled client outside the US. The reason this was necessary is that the US government and several allies defined (and I believe still define) encryption as a weapon, but it was possible to get permission to export software that only supported 40 bit encryption (and later 56 bit) and that included a couple of other restrictions (there was an exception for financial services). The reason for the limitations was, presumably, that the intelligence communities of these countries had the technology needed to break these keys. In 1999/2000 the restrictions were partially lifted, at least for mass market products like browsers and email clients.

  • 40 and 56-bit methods are dismally weak given today's technology. In mid-1998 56-bit DES was broken in less than a 56 hours, this was reduced to 24 hours less than half a year later. Given today's technology I expect that the same can be done in less than 30 minutes with enough hardware. And 40-bit can probably be broken in less than a second. What this means is that these methods no longer provide any protection at all.

  • Any server that only supports these methods is more than 8 years old, which means the actual security of the server, even ignoring the lack of encryption strength, is .... questionable. To top it off, a number of Certificate Authorities sell "SGC" certificates that will permit most US produced and exported servers (and clients) to enable 128 bit encryption. These certificates were originally reserved financial institutions, but after the crypto export restrictions were lifted they have become available to all.


While I believe servers that only support 40/56 bit encryption are a bit more common, in absolute numbers (perhaps a few thousand), than SSL v2 servers, I can't remember hearing about any such sites for over a year, despite the fact the the methods have been disabled by default about that long in several browsers. That indicates that the servers are not visited by a lot of people, if any. I think it is time to signal quite clearly to the sites that may be left that the technology they are using is obsolete.

If you do encounter a "secure" site that require 40 or 56 bit encryption, what can you do? Well, I don't recommend it, but you can go back to Opera 9.2x and enable the weak ciphers. But before you do, perhaps you should ask the system administrator this question: "Why are you running the site with 8 year old software?"

New^W NOT in Kestrel: The death of SSL v2

, , , ...

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?"

(51)2-bit banks

, , , ...

It shouldn't come as a surprise to anyone who is familiar with my opinions on encryption strength that I do not hold 512 bit RSA encryption keys in high regard. To put it mildly.

Unfortunately, I continue to be disappointed by the many sites using such weak keys. But I am even more disappointed by the fact that it turns out there are banks that are still using these keys.

Recently I have become aware of two banks/financial services that are using such weak keys:



Both of these sites are, as of June 15th, 2007, still using 512 bit RSA keys, and have been doing so for about a year, at least.

I have tried to contact these banks yesterday evening and today, but have so far gotten no response (and I also had trouble submitting the comments to the Israeli bank), and to Amazon UK, who answered quickly that they would forward the information internally.

The problem with 512 bit RSA keys is that an attacker, using (almost literally) a handful of computers, can break them in a couple of weeks, at most.

And when an RSA key is broken the attacker can do a lot of things:

  • He can read all previous traffic with the site if he have recorded it (if the site uses Ephemeral Diffie-Hellman keys, then those keys must be broken instead).
  • If he is able to intercept current traffic to the site, he can pretend to be the site and read all the data passing back and forth between the site and the users.
  • If he is able to pretend to be the site, he can also change the information on the fly, if he wants too.


There is absolutely no way to detect any of these attacks through the SSL/TLS protocol, because the sanctity of the site's secret private key is the fundamental pillar of the protocol. That key is used to agree upon the encryption keys that are used to protect the rest of the
communication.

10 years ago, 512 bit RSA was the highest level of encryption the US government permitted foreign users of US manufactured servers and browsers to use, except for financial services, who could use 1024 bit RSA keys, or better. It was widely assumed that the reason for this limit was that the US government could break 512 bit RSA keys relatively fast. The restriction was lifted in 1999/2000.

The proficiency of RSA key breaking is, as I mentioned a couple of weeks ago, rapidly increasing. At present general 640 bit RSA keys can be broken in 5 months using just 100 computers. But recently a special 1020 bit number was factored (the difficulty of factoring large numbers is what provides RSA with its security) in about 11 months using the same amount of computing power. That means that 1024 bit RSA keys are fast approaching their "consume by" date, if it hasn't already been passed.

Today, I would strongly recommend that secure websites, in particular financial sites, should use 2048 bit RSA keys.

The days of 1024 bit RSA keys are numbered: 1296 days, at most. (See the countdown for the up to date number, on the frontpage).



Update, June 18: Halifax has responded that they are in the process of upgrading the server certificate.

1020 bit special number factored

, , , ...

Earlier this week news arrived about the successful factoring of a 1020 bit (307 digit) number using just 11 months and about 100 computers to perform the necessary calculations.

The number that was factored is a specially structured number, meaning that it was much easier to factor than a general number of the same size. The largest general factorings accomplished so far are 640 and 663 bits. Both were announced last year.

This is important because the difficulty of factoring a large number determines the security of the RSA encryption method, one of the primary supporting pillars of SSL/TLS, as well as PGP and S/MIME, as they are used today. If the RSA key used by a site is broken, an attacker can not just read all communcation with the site protected by that key, he can also impersonate the site from then on, and he would be able to read all communication with the site that was ever protected by that key, assuming he had archived them.

At present there is no immediate danger that an attacker can break a 1024 bit key, the keylength used by most website certificates (and also CAs) at present. However, like what has been happening to SHA-1 which is another cornerstone of SSL/TLS, this is a warning shot across the bow of the world's 1024 bit RSA keys. Within a few years (it could be 3-4 years, or it could be 10 or more) it is quite likely that the methods used will dramatically reduce the security of 1024 bit RSA keys.

There is currently no indication that RSA itself is broken, but as computation power increases and factorization methods improve this will change the properties of which RSA keys can be considered secure. 10 years ago 768 bits were considered reasonably secure, that limit was later raised to 1024 bits, now it is time to raise the limit even further.

Effects for Opera

I have already taken steps to increase the default length of client certificate keys generated by Opera to 1536 bits.

We are also considering changing the default value of opera:config#SecurityPrefs|MinimumSecurityLevel from "0" to "1". This would raise the lower limit of what is Level 3 (L3) security for RSA from 1000 bits to at least 1020 bits (For settings "0"-"3" Level 1 security is everything below 900 bits).

The consequence of such a change is that sites using certificates issued by at least one root (that was issued with a 1000 bit key) would lose the padlock, as they would be classified as having Level 2 security. We haven't made a decision on this yet, because we first need to find out how problematic the change would be.

Within a few years, probably between 2009 and 2012 (depending on what happens on the factorization front), it is likely that this preference will be raised to "2" (L3 = 1100 bits) or "3" (L3 = 1200 bits).

And before somebody asks: Yes, I am investigating Elliptic Curve Cryptography (ECC). But before it can be implemented and released in a public version, there are still several legal requirements that have to be met.

Last week I also suggested to the W3C's Web Security Context (WSC) group that browsers should not consider a connection secure (and show a padlock) unless the encryption keys used to protect the communication was 232 (4 billion) times more difficult to break than what can reasonably be broken in one year using currently known methods and technology. The other members of WSC has not yet considered my suggestions.

Such a rule will ensure that, short of revolutionary leaps in technology and/or methods (such as a complete solution of the factoring problem), not even enormous amounts of money can compromise the keys by brute-force computation (if somebody is that interested in some piece of informaiton there are other, less expensive, ways to get hold of the key, such as "buying" it, although that would reveal the interest).

Given the current state of the art, this proposed rule puts 1024 bit RSA in the unsafe zone.

General effects

My recommendation to the world's RSA users would be to use longer keys, at least 1536 bits ( only if performance is an issue), but preferably 2048 bits, and get their certificates issued from Certificate Authorities (CAs) using keys that are at least 2048 bit long (ask the CA if you are not sure).

Thanks to Bruce Schneier for the first post. Bruce also says: "I hope[d] RSA applications would have moved away from 1024-bit security years ago, but for those who haven't yet: wake up."

Thanks also to Eric Rescorla.

See also http://en.wikipedia.org/wiki/RSA_Factoring_Challenge for more on factoring big numbers
November 2009
S M T W T F S
October 2009December 2009
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30