Implementer's notes

For some time now Opera has supported the Certificate Status Request Extension to TLS, although we did have a false start which was fixed in Opera 9.26.

What this extention does is to provide a way for a client to ask the server to do the OCSP revocation check for its own certificate, rather than the client doing a separate connection to the issuer's OCSP responder. The benefit of this policy is that the client saves time completing the connection since it does not have to wait for the OCSP responder. Also, if the server stores the OCSP response for a while, then the traffic to the OCSP responder becomes much lower (and much less expensive). Mostly servers will request updates and not all the clients visiting the site. This is called TLS OCSP stapling.

This mechanism only works for the server's own certificate. It does not work for any of the other certificates in the chain, and these days most Certificate Authorities (CAs) use at least one intermediate certificate, and some use four, or more. Today all the revocation information about these are retrieved using CRLs, not OCSP. This means that the information is not as up-to-date as is possible for OCSP, as CRLs (particularly for intermediates) are valid for much longer periods than OCSP. This may not be an issue today because most intermediates are controlled by the CA or other relatively big CAs, but it could become a problem if CAs start issuing large numbers of intermediate CA certificates that they do not control, for example to corporate customers. This might become a possibility if/when better domain limitations are widely implementated in browsers. If one of those corporate customers or an independent sub-CA starts issuing bad certificates, it is imperative to be able to revoke those CA certifiates quickly, which would be difficult if the CRL was updated every 12 months. On the other hand, OCSP responses are usually valid for less than a week.

Some intermediate CA certificates are now issued with OCSP URLs specified, but no browsers are currently using them. It is my recommendation that they do not start using them. The reason is that for all clients to use OCSP to check intermediate CA certificates would increase traffic to those
servers multifold, perhaps dozens of times when TLS OCSP Stapling becomes widespread, meaning the bandwidth cost for the CA will increase significantly. A number of CAs have already been concerned about the cost of supporting OCSP just for server certificates while waiting for stapling to become widespread; they would not like the cost of supporting OCSP for one or more intermediate certificates.

The solution, of course, is to expand the TLS Extension to support multiple OCSP responses, which should have been a fairly straightforward task, which it was for the handling of the responses. It turned out, however, that it was not practical to use the existing Certificate Status Request extension in TLS, since it does not allow multiple methods to be specified (but only a single method), which would be necessary to support servers that do not support the new response format. The limitation is due to both a hard restriction in TLS, as only one entry for a given extension can be sent in any extension list, and the request extension only permits a single format to be specified, not multiple.

The solution in the end was to create a new extension that permits multiple formats to be specified, not just a single one as before.

I have just submitted an Internet Draft to the IETF TLS Working Group defining such an extension and new response format. The draft is based on the existing definition with enhancements for the new requirements.

I hope the TLS WG will take on the work to help me complete the draft so that we can get this new functionality into all new clients and servers as soon as possible.

Comments intended as contributions to the draft should also be posted at the TLS WG mailing list.

draft-pettersen-tls-ext-multiple-ocsp-00.txt (archive)

The drafts I have written about Opera's DNS heuristic used to check cookie domains and the online "subTLD" information system that I suggested to replace it have now been refreshed.

There are no changes in the DNS heuristic draft, but the subTLD draft have been updated based on my experience with implementing the Public Suffix (a.k.a. SubTLD or Effective TLD) support that is planned for future versions of Opera (well past v10.0). As a result, the certs.opera.com server which is used for Opera's online Root Certificate repository has now started hosting Opera's XML based Public Suffix List,
based on and generated from the Public Suffix List project's list. The XML files are also available as a single download (without the digital signature, under the Mozilla Tri-license (MPL, GPL, LGPL) from our online download location.

The drafts are available at

draft-pettersen-dns-cookie-validate-05.txt (archive)

draft-pettersen-subtld-structure-05.txt (archive)

See also the Rootstore update.

draft-pettersen-dns-cookie-validate-05.txt
draft-pettersen-subtld-structure-05.txt

I've once again refreshed my HTTP Cookie and Cache related Internet Drafts. The drafts have been discussed here a couple of times before, but to summarize:

draft-pettersen-dns-cookie-validate-04.txt (archive)

This Draft describes Opera's current heuristical approach to avoid sending cookies to registry-like domains like co.uk (The "Cookie Monster Bug"). First discussed here.

draft-pettersen-subtld-structure-04.txt (archive)

This Draft describes an improved approach to handling the "Cookie Monster Bug", using an online black list of registry-like domains. Also first discussed here.

The Mozilla team's work on "Effective TLDs" is based on an early version of this suggestion. The result of this work is now available from PublicSuffix.org, and is AFAIK currently used for one or more features by Chrome Beta, FF3, and IE8 Beta.

To reduce the complexity of the specification, and to avoid excluding possible solutions, I have now removed the previous suggestions for how the repository should be generated, and just shortly mention some possibilies in the Appendixes.

draft-pettersen-cookie-v2-03.txt (archive)

This Draft describes the ideal solution to the "Cookie Monster Bug", that everybody starts using a new format for cookies that completely remove the problem. First discussed here.

draft-pettersen-cache-context-03.txt (archive)

This Draft describes a method for giving sites a method to tell the client that a group of webpages are related, which can be used to better organize logouts. First discussed here.

draft-pettersen-dns-cookie-validate-04.txt
draft-pettersen-subtld-structure-04.txt
draft-pettersen-cookie-v2-03.txt
draft-pettersen-cache-context-03.txt

The W3C's Web Security Context Working Group have just released the Last Call version of its "User Interface Guidelines" document, which is a set of recommendations for the security related UI in Web User Agents.

This specification deals with the trust decisions that users must make online, and with ways to support them in making safe and informed decisions where possible.

This document specifies user interactions with a goal toward making security usable, based on known best practice in this area. Subsequent testing of this specification will include conformance, interoperability, and usability testing.

If you want to comment on the document you are welcome to do so:

The W3C Membership and other interested parties are invited to review the document and send comments to public-usable-authentication@w3.org (with public archive) through 15 September 2008. We appreciate if comments follow these guidelines for writing good issues.

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.