Friday, 27. June 2008, 13:53:06
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.
.
.
WIDGETIZE