One thing that’s very surprising about PKI infrastructure is the fact that a lot of the mechanisms put in place don’t work, or don’t work as they should. Often this is driven by sheer necessity, and the need to keep the internet working no matter what. One example of this is certificate revocation. If you are setting up a domain and requesting a new certificate, you would assume that once issued the certificate can be revoked in the case of a security breach.
But you’d be wrong. Even when you revoke the certificate attackers can still use it to enable MIIM attacks. Read on to see why….
Up until recently, browsers and other internet clients relied primarily on two mechanisms to check wether a certificate presented by a server had been revoked or not. One way was to use a Certificate Revocation List, literally a list of revoked certificates. These would be published periodically and clients would download them. However, they suffered from two problems; one, as the internet grew, these lists became massive and troublesome to maintain, and secondly, they relied a lot on best practices being implemented, with lists being updated and downloaded diligently. To the best of my knowledge Chrome still uses them, so they must still hold some value, but Firefox phased them out a good while ago.
So CRL’s were gradually replaced with the Online Certificate Status Profile. With this method, the client would verify the certificate’s status via a specialist OCSP servers, which CA’s and other bodies maintain. Simple really, and quite effective.
In fact, too effective.
You see, it turns out that OCSP servers are not particularly high up on the list of services to maintain (remember that a lot of the PKI infrastructure is maintained by companies whose main goal is to make money). Often, in the past at least, servers would be down, or take too long to respond. In the meantime, any user that needed to access a HTTPS site (ie. pretty much everyone) would find the site blocked.
This became a big problem, so the browsers that relied on OCSP came up with an ingenious solution.
They simply ignored it.
That’s right, if Firefox (and some other browsers) tries to verify a certificates revocation status, and the OCSP server doesn’t respond in time, Firefox will just ignore the fact that the certificate check is effectively broken, and load the page anyway. Which kind of makes sense from a practical perspective -we can’t have half the worlds e-commerce, governmental and social media sites grind to a halt due to a few dodgy OCSP servers. But this does mean that a revoked certificate can be passed off as legitimate.
Think about it, the whole point of certificates is to protect against someone who is already on the network, and who can intercept your traffic. If an attacker is already in this position, and can see network and manipulate traffic, all they have to do is respond with a revoked certificate, listen out for the clients request to OCSP and block it. The browser will abandon the certificate revocation check, and accept the attackers certificate as legitimate.
This is why you can’t rely on CRL’s and OCSP to reliably revoke your certificate. So what can you do to protect yourself and minimise damage in the event of a certificate private key breach? Stay tuned to find out!