My Opera
New CNNIC EV Root, pubsuffix update, and some blacklisted certificates
By Yngve Nysæter Pettersenyngve. Thursday, March 31, 2011 6:32:21 PM
Today, we have updated the Rootstore with the following:
Additionally, the "major" update is due to the recent attack on the CA Comodo1,2, where an attacker was able to hack into an account and trigger the issuance of 9 certificates for major communication sites (a few other accounts have apparently also been compromised, though no certificates have been issued from these accounts according to our information). Rumors are flying about who was behind the attack, and why, but I will let those rest.
We learned of the attack late evening March 16th, and, by then, the issued certificates had already been revoked by Comodo for more than 24 hours (Comodo detected the attack within a few hours).
I evaluated whether to update the Rootstore Untrusted list of certificates with those certificate already that week, but decided not to do so at the time, in particular since Opera's blacklist could not blunt any attack within the 2 days remaining of the pre-revocation OCSP response validity, and there had been no accesses for the revocation information in the open window.
Also, after the (possible) pre-revocation OCSP responses had expired, any attempt to block revocation checking would remove the secure indication of the site when loaded by Opera, so any users that are keeping an eye on the padlock (we know that a lot you do) would be protected, so after that time the certificates could not in any way have been used to flag pages as secure in Opera.
Another consideration is that the Untrusted list is not intended to be an extra revocation list for normal certificates; it is only intended to include problematic certificates that cannot be revoked in any other fashion, such as the MD5 collision cert a few years ago or a renegade Root CA.
Adding fraudulently issued certificates is not among the list's intended uses, except in special situations. The reason is that revoking those certificates is what the revocation lists (CRLs and OCSP) are for.
At present, however, we have a situation where it is not practical to refuse access to a secure site because the browser cannot access up-to-date revocation information, particularly since the responders have occasional momentary down periods. Opera removes the padlock if we can't get the revocation information, as far as I know Chrome puts a (Golden? Shouldn't that have been red?) warning triangle over the padlock, others give no indication at all that there was a problem.
In the aftermath of the Comodo incident, several participants in the discussion, including me, have suggested that we should move towards stricter requirements regarding having revocation information available before allowing a secure connection to complete.
There are several downsides to this, particularly that it requires exceedingly high stability for the revocation servers, and there is also an implied requirement that all browsers need to do this policy change at the same time, to provide the same user experience.
The stability requirement can be worked around by requiring secure servers to implement TLS OCSP stapling, an extension to the TLS protocol where the TLS server caches its own OCSP response and sends it to the client when it connects. This saves the extra roundtrip for the client when it retrieves it directly, and provides an up-to-date status. There are two problems at present: 1) only 3% of servers support the extension and 2) to be truly useful, all the revocation info for all the certificates in the server's chain needs to be included, and that is currently not possible; but I have submitted a proposal to the TLS WG that would allow that (although there are some concerns that the extra data will cause performance issues for big sites).
In the meantime, using a blacklist may be the best option for limiting impact, but it is also an option that does not scale in the long run, and it also has a relatively long deployment time, compared with revocation. Excluding time for users to update, it took the browsers that shipped blacklist updates last week a week to ship their updates, and that was probably achieved by pushing their release cycles to the limit. Even this Rootstore update took a week to prepare.
In this case we have decided to follow the other browsers, and update our Untrusted list with these certificates, and we might continue to do so in the short term, should there be more incidents, but in the long term other solutions will have to be found.
The are some things to note, even though I hope none of you will ever encounter any of these certificates in the wild:
This update will propagate to all Opera versions that support the online Rootstore during the next week; if you are impatient, just use Menu->Help->"Check for updates" to fetch it (The CNNIC EV-site mentioned above can be used to test that you got the update).
Summary: Opera users who consult the security indication could not have been tricked into believing a site with the fraudulent certificates was secure once the Comodo revocation lists became authoritative, the addition to the blacklist is an extra security measure that strictly speaking is not necessary. No action is needed by our users to download this update.
- CNNIC, the Chinese Registrar and CA have been EV enabled. As
part of this, a new EV-enabled Root was added (the old is not EV-enabled). Testsite - An update of the Public Suffix list, adding the suffixes gob.ec
and bv.nl. Version 1.5 is available for download from our source repository.
Additionally, the "major" update is due to the recent attack on the CA Comodo1,2, where an attacker was able to hack into an account and trigger the issuance of 9 certificates for major communication sites (a few other accounts have apparently also been compromised, though no certificates have been issued from these accounts according to our information). Rumors are flying about who was behind the attack, and why, but I will let those rest.
We learned of the attack late evening March 16th, and, by then, the issued certificates had already been revoked by Comodo for more than 24 hours (Comodo detected the attack within a few hours).
I evaluated whether to update the Rootstore Untrusted list of certificates with those certificate already that week, but decided not to do so at the time, in particular since Opera's blacklist could not blunt any attack within the 2 days remaining of the pre-revocation OCSP response validity, and there had been no accesses for the revocation information in the open window.
Also, after the (possible) pre-revocation OCSP responses had expired, any attempt to block revocation checking would remove the secure indication of the site when loaded by Opera, so any users that are keeping an eye on the padlock (we know that a lot you do) would be protected, so after that time the certificates could not in any way have been used to flag pages as secure in Opera.Another consideration is that the Untrusted list is not intended to be an extra revocation list for normal certificates; it is only intended to include problematic certificates that cannot be revoked in any other fashion, such as the MD5 collision cert a few years ago or a renegade Root CA.
Adding fraudulently issued certificates is not among the list's intended uses, except in special situations. The reason is that revoking those certificates is what the revocation lists (CRLs and OCSP) are for.
At present, however, we have a situation where it is not practical to refuse access to a secure site because the browser cannot access up-to-date revocation information, particularly since the responders have occasional momentary down periods. Opera removes the padlock if we can't get the revocation information, as far as I know Chrome puts a (Golden? Shouldn't that have been red?) warning triangle over the padlock, others give no indication at all that there was a problem.
In the aftermath of the Comodo incident, several participants in the discussion, including me, have suggested that we should move towards stricter requirements regarding having revocation information available before allowing a secure connection to complete.
There are several downsides to this, particularly that it requires exceedingly high stability for the revocation servers, and there is also an implied requirement that all browsers need to do this policy change at the same time, to provide the same user experience.
The stability requirement can be worked around by requiring secure servers to implement TLS OCSP stapling, an extension to the TLS protocol where the TLS server caches its own OCSP response and sends it to the client when it connects. This saves the extra roundtrip for the client when it retrieves it directly, and provides an up-to-date status. There are two problems at present: 1) only 3% of servers support the extension and 2) to be truly useful, all the revocation info for all the certificates in the server's chain needs to be included, and that is currently not possible; but I have submitted a proposal to the TLS WG that would allow that (although there are some concerns that the extra data will cause performance issues for big sites).
In the meantime, using a blacklist may be the best option for limiting impact, but it is also an option that does not scale in the long run, and it also has a relatively long deployment time, compared with revocation. Excluding time for users to update, it took the browsers that shipped blacklist updates last week a week to ship their updates, and that was probably achieved by pushing their release cycles to the limit. Even this Rootstore update took a week to prepare.
In this case we have decided to follow the other browsers, and update our Untrusted list with these certificates, and we might continue to do so in the short term, should there be more incidents, but in the long term other solutions will have to be found.
The are some things to note, even though I hope none of you will ever encounter any of these certificates in the wild:
- Only 7 of the 9 certificates are included, due to the ID of two certificates colliding with a third certificate; the ID is based on the certificate's subject name and public key. This problem is due to a design error in the repository handling; plans are under way to fix the problem.
- The blocked certificates are only pushed to Opera 9.5x and 9.6x versions, since they are not able to use the newer dynamic system. The above point means that two certificates are not installed in those version and are not blocked. In all other versions, there is no visible indication of the list having been updated.
- In newer versions the blocked certificates are only downloaded if they are ever needed. If the download fails, the certificate will still be blocked, which also means that the two certificates not in the list will actually be blocked anyway.
- In Opera 10.x before 10.50, the certificates will be blocked in the way the functionality was designed, by displaying a message that the certificate is untrusted.
- In Opera 10.50 and later, including 11.10, there is a bug. While the blocking works, it works by either showing a blank page or a "Could not connect" message. We are looking into this.
- If the blocked certificates are ever encountered, by Opera 10.0 or later, revocation is checked first, and only if the certificate is not revoked (or the information could not be retrieved) will the untrusted list be consulted.
This update will propagate to all Opera versions that support the online Rootstore during the next week; if you are impatient, just use Menu->Help->"Check for updates" to fetch it (The CNNIC EV-site mentioned above can be used to test that you got the update).
Summary: Opera users who consult the security indication could not have been tricked into believing a site with the fraudulent certificates was secure once the Comodo revocation lists became authoritative, the addition to the blacklist is an extra security measure that strictly speaking is not necessary. No action is needed by our users to download this update.
