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:
- We now use HTTP GET requests to retrieve OCSP revocation information
- Additionally we download further revocation information, the CRLs (Certificate Revocation Lists), from the issuer and check those.
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.
Hello Yngve,Thank you very much for that workaround! Now I can do online banking in 9.51, and doesn’t have to start up 9.27 every time.I have contacted my bank after you answered my bugreport, but until now, these stupid helpdesk employes was not able to confirm their broken certificate. I hope that verisign contact its customers with broken certifikates, and this will be fixed in the future.Nevertheless, for the user the issue will be fixed with 9.51 :-)Claus Berghammer
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. But does the missing padlock really mean that the connection is insecure, as the dialog says for one of my banks? Or can I assume that if it’s the same certificate as when I logged in with 9.27, the connection will be just as secure?
Scipio: It means that given the items we now check, we cannot assure you that you are talking to the right party. The failures could be due to malicious interference; we have no way to tell. We therefore consider the connection to at least be questionable. We notify the user by removing the padlock, and let the user decide.In a few years I expect that most clients will consider a failure of these checks to be a fatal error, not just an inconvenience. The reason we aren’t right now (For a while Opera did this for OCSP) is because the services have not been tested enough by clients using them by default.
OK, I have problem with my bank. Opera 9.27 reported as site is secure, but opera 9.50 and 9.51 RC2 report that site is not secure. I have checked Versign site and it says everythink is OK.The site is: https://net.pbz.hr/pbz365/And yes I always check padlock about secure site. 😉 TIA.
Magi: My guess is that you did not trigger a manual update to fetch the most recent data using Help->Check for Updates. That is currently required before the override is activated (it depends on data hosted on the auto update system).
Thx yngve, now with Opera 9.51 RC2 everything is OK.
So, is OCSP the reason it now takes a minute to connect to any https website?
On the to-do list.
Yngve;When you have some time, how about adding some extra details to the “Grey Question Mark” info popup. (Security Information for xxxx)I.E. When you bring up the details (on a site with a grey question mark) the message does not really allow for any diagnostic info just that “something” failed.Two quick ideas for this:First, just give a simplified additional text return below the existing “The Server attempted to apply security measures, but failed” message.Something along the lines of (rough thoughts and examples only) “Can not connect to Cert CRL” “Error talking with Cert CRL” “Mixed InSecure and Secure Content” etc…? Of course and the ever present: “Unknown Reason” as a fall through.Secondly, maybe a “debug” button/routine that will run through all of the checks that are being accomplished with a “pass/fail” return code?Granted its likely nothing that your average user would care about. But I think it would allow the maintainers of sites who were encountering these kinds of problems self diagnose the “real” root issue.
The coders at Opera have gotten the certificate checking rules WRONG here:1. The CRL location information is part of each certificate because THERE IS NO RULE THAT JUST BECAUSE ONE ELEMENT OF THE CHAIN USES CRLs, THEN ALL THE OTHERS SHOULD TOO. So failing any certificate on that basis alone is a bug.2. If a certificate specifies a CRL checking method not implemented by Opera (such as ), then Opera’s own lack of support should not be treated as a failure unless that certificate extension in that certificate is marked as “Critical”. This is the definition of marking a certificate extension as “Critical” or not.3. Giving an error message that the SERVER failed, when it was either Opera or some 3rd party server contacted behind the scenes by Opera that failed is LYING, and a BUG.One case that is currently failing for me (Opera 9.52), is Intranet sites using certificates issued by our Internal CA (Microsoft default configuration). The CA provides ldap: and http: CRL URIs, and downloading the http: URI actually provides a seamingly valid CRL. All further debugging is prevented by the informationless error message. I.E. (may know some MS tricks) and Firefox (lousy CRL checking) work nicely with these certificates.
1. Actually: It is our certificate verification system, from OpenSSL that requires that all certificates in a chain have a CRL. And if you think about it for a few seconds you will realize that requiring it makes sense.2. I think HTTP support for CRLs should be considered a minimum requirement.3. If the server provides incomplete information, or the systems that information depends on are failing, then the server have failed to provide sufficient security.For clarity: If an intermediate CA specifies a CRL, all non-root certificates must specify a CRL, but the site certificate may specifiy an OCSP responder instead (OCSP is recommended). The CRLs must be accessible via HTTP.
I have used Firefox (instead of Opera) twice for banking in the past 2 or 3 months due to “The Server attempted to apply security measures, but failed” message and missing padlock icon.
Yngve, this is a good blog post about how users are noticing the change in behaviour (lack of padlock) when they do sensitive interactions on the web.http://anil-identity.blogspot.com/2008/10/do-you-notice-padlock-during-online.htmlAn important question I have is, why is the user registration on Opera site not running on https? You want me to enter birth date in my profile on a http site?http://anil-identity.blogspot.com/2007/11/why-does-facebook-want-my-date-of-birth.html
Entering personal information is purely voluntary.
that was a good read, although the entry is from 2008Greetings