A couple of days ago Adam Langley from Google published a blog entry [1] where some interesting statements are made; the most eye candy one is “we're currently planning on disabling online revocation checks in a future version of Chrome”. This is done as Google’s Chrome will include an alternative to the current OCSP and CRL methods of verifying a certificate’s revocation status (so called “online revocation checks”) .
What this means to you?
It means that Google will decide if a certificate was revoked or not. Not that Google can revoke certificates, but for some functionality issues -*fine irony here*- will likely not maintain a list of all revoked certificates; I mean all from all CAs. So assuming one revokes a certificate for other reasons than private key loss/theft, very likely this certificate will not appear as revoked in Google’s list(perhaps it will, if it belongs to a major company or so). The end result will be that Google Chrome’s users will be indefinitely MITM-able till that certificate expires in case the private key will be stolen(the admin does not care anymore as he did revoke that certificate isn't it ?).
It’s up to Google’s strategy and implementation of this to decide what will be included on the revocation list; knowing that there are some many CAs, finger crossed.
Furthermore, if you run your own internal PKI and you use Google Chrome you need to figure it out how do you plan to revoke certificates.
OCSP and CRL don’t work
We know that, but neither does Google’s strategy. It’s still a soft-fail blacklist mechanism; in fact can be worst than CRL in some aspects related to security.
What OCSP offers better in terms of security is its dynamicity. Remember the Diginotar breach, they did not know what certificates they issued; OCSP can help in this case but CRL and Google’s approach don’t(unless the intermediate CA cert is revoked).
Google’s pushing revocation list approach
For example Opera can push some PKI updates(e.g. remove a CA trust) dynamically without releasing a new version of Opera; Google could not do so till now. Pushing a list of revoked certs on-the-fly is an aid to the current revocation status mechanisms but does not necessarily replace them.
Google’s pushing revocation list approach is a soft-fail blacklist mechanism because in case the update mechanism fails, e.g. connection issues -*fine irony here*- , I doubt Chrome will block access to *all* SSL sites; mega single point of failure-*fine irony here*-.
In case of a MITM attack, Chrome will very likely rely on an old and expired revocation list:
- First because it’s a blacklist approach so one must known about the rogue certificate and revoke it; yawn.
- Second, Google must retrieve the needed CRL and push a new revocation list; sigh.
- Furthermore even when the above two are true, the end user’s Chrome must have received the updated revocation list; dreaming.
Similar with OCSP and CRL an attacker still has an opportunity window even after the rogue certificate was discovered. Is this smaller or not, only “practice” can tell.
Blacklist Push vs Pull: is there any difference ?
In the most important aspect, not really, as both require a connection initiated by the client. It’s an ask for push or pull.
OCSP and CRL are pull(with some differences); Google’s approach is push.
Blacklist pull works for what you know and for what you may not know(OCSP case) whereas blacklist push only works for what you specifically know.
It is assumed that the attacker has full MITM capabilities over client; as we have seen in the past, attacks using rogue certificates can be targeted. So very likely the attacker controls both the pull and push channels(precisely the ask channel). And both are soft-fail; here comes the opportunity window.
The captive portal dilemma
If all the browsers fail such sites I believe it’s trivial to imagine who really has to change. We want to blacklist major root CAs but we cannot “blacklist” some captive portals.
Comparing the three
- None will currently work in case of a serious MITM attack.
- The most secure is OCSP if implemented properly; e.g. not using time-based freshness, issue a failed response for an unknown cert and drop the SSL connection when the check fails. Note that “simple” OCSP stapling can aid the MITM when the attacker replays old good OCSP responses.
- Google’s approach can provide better freshness compared to CRL, but uses a selective list.
- OCSP can be improved; CRL and Google’s approach not, or at least I don’t see how.
- Google’s approach can be a good add-on to OCSP till the later is improved.
References
[1] Revocation checking and Chrome's CRL
http://www.imperialviolet.org/2012/02/05/crlsets.html