HTTPS pinning and other SSL hacks are making situation worse

2011-05-08 00:00:00 +0100

Current trends in “improving” disfunctional PKI mechanisms - like HTTPS pinning - are actually making the situation even worse. For the first time I couldn’t believe my eyes back in March, when Mozilla and Chromium hardcoded the blacklisted fake Comodo certyficates down in the source code of the browser. Isn’t that why CRL and OCSP was invented for?

Not that Mozilla started the trend - back in 2001 it was Microsoft that created their blacklist certificate storage in Windows, when VeriSign issued fake certificates for some Microsoft domains.

Why not CRL or OCSP? From the discussions on browser certificate validation that started after Comodo hack it looks like that certificate validation just doesn’t work. Either because CRLs are issued in too long intervals, or because OCSP servers don’t work reliably enough. And I’m seeing this for GoDaddy certs on Github quite often.

So the situation is that one of the most important mechanisms of X.509 based PKI is in large scale disfunctional and instead of fixing it, we are coming up with technical ad hoc hacks like the hardcoded blacklists, or now even better HTTPS pinning. Let me repeat this: because the X.509 validation doesn’t work for large-scale Internet users, browser developers are forced to treat these failures of validation as expected behaviour. That’s ridiculous.

While hardcoded blacklists may make some sense from functional point of view (we want these certs to be blocked now, and fixing PKI takes long time), the HTTPS pinning concept is just another ad hoc hack and a step in wrong direction. This is a whitelist, extracted from another whitelist (EV), extracted from another whitelist (WebTrust), extracted from general SSL websites population. And this particular whitelist is going to be controlled by a browser vendor and hardcoded into an application. Logically, after some time there will be yet another “extended pinning” and so on.

I consider X.509 standard confusing (keyUsage and extendedKeyUsage chaos), incomplete (authorisation) and written in unreadable language. It’s absurd that XML based encryption or digital signature formats are still embedding opaque DER blobs, aliens from completely different times and assumptions.

Does OCSP or CRL make any sense in today’s web world? Not much. With CPU-intensive and centralised OCSP lookups and CRLs that are often large and thus issued rarely, it’s just not going to work in billions-sized user base of global web.

So maybe it’s now time to start replacing X.509 with something that would be based on exisiting alternatives both in field of identity (e.g. SPKI/SDSI) and validation (e.g. Novomodo)? Ad hoc hacks, like the ones described above, are not going to make the on-line authentication work for sure.