Certificate revocation (or not)!

Certificate revocation is a cat and mouse game.

I was recently reading about Online Certificate Status Protocol (OCSP) and Certificate Revocation List (CRL) and decided to check the OCSP calls using Wireshark. I couldn't find any calls while using Chrome. I found out that Chrome doesn't do live OCSP checks. I opened Firefox to check if they do live OCSP checks. Here, I found a glimmer of hope when I saw an OCSP request on Wireshark.

alt

I started wondering how slow is this OCSP live check.

Steps involved in doing a OCSP check:
1> Get the OCSP responder URL
2> Resolve the OCSP domain
3> Go through the 3 way handshake process to establish a TCP connection.
4> Fetch the OCSP status data

The whole process (resolving to fetching OCSP status) can sometimes consume close to 500 ms depending on the recursive DNS you are using and how fast the OCSP responder is.

Tip: If you are not doing OCSP stapling^[1], then you are slowing down your first time users significantly. This is because the browser needs to fetch the OCSP data from the OCSP responder of the certificate. The OS has it's own cache for OCSP responses. The caching time differ from OS to OS.

You can download the actual PcapNG file from here.

After seeing the OCSP domain being resolved, I wondered what will happen if I block this OCSP check request?

So I opened my /etc/hosts file and added an entry to point the OCSP responder domain to my localhost.

127.0.0.1 ocsp.godaddy.com

Then I cleared my OCSP cache and DNS cache on my Mac.

$ sudo sqlite3 ~/Library/Keychains/*/ocspcache.sqlite3 'DELETE FROM responses;'; 
$ sudo sqlite3 ~/Library/Keychains/*/ocspcache.sqlite3 'DELETE FROM ocsp;';
$ sudo killall -HUP mDNSResponder;

And restarted my browser.

Now the query should fail and ideally the browser should block the website. Right? No. Firefox doesn't block the website if the OCSP request fails! We have to explicitly enable this behaviour by opening about:config and changing the security.ocsp.require setting to enable.

Let's assume a hypothetical situation:

Some state sponsored hacker compromises infra of a company and makes a copy of the certificate/private key of the company's domain. The company finds out about the breach and revokes the certificate. But now the hackers have the old certificate. Is it right to believe the hackers can't do anything with it? Nope.

A state sponsored hacker/telecom authority can hijack the DNS response to point the domain to a fake server which has the old certificate installed on it^[2]. And, to make sure that the OCSP doesn't ruin the party they can block the OCSP responder domain also.

Now a regular user which doesn't have security.ocsp.require enabled will land on the fake server without any warnings issued for the expired certificate!

Chrome and Firefox have a CRL mechanism to overcome these kind of issues, but the lists are not all inclusive.

Chrome doesn't include all the revocations^[3]

For size reasons, the list doesn't include all CRLs - EV CRLs and CRLs with good reason codes are taken in preference. CRLs which cover intermediates are typically small and valuable so we try to take as many as possible.

Firefox only pushes intermediary certificate revocations in their list^[4]

To test these steps I registered a certificate and later revoked it. I then installed the revoked certificate on an HAProxy server (with no active backend servers). If you go to URL https://ocsp.test.shrey.io/ you will see a SEC_ERROR_REVOKED_CERTIFICATE error.

alt

I pointed the OCSP responder domain to my localhost. How do you find the OCSP responder domain? You can either use the openssl command on terminal or check it on your browser.

alt

After pointing the OCSP responder domain to the localhost, I cleared the DNS and OCSP cache as described at the beginning of this post. I was again able to access the website without any warnings after restarting the browser.

This local DNS hack which I did can easily be done by telecom companies on a very large user base.

Here is a bash script which can be used to check the OCSP URI and status of a domain (tested on Debian).

$./ocsp_fetcher ocsp.test.shrey.io;
OCSP URI: http://ocsp.godaddy.com/
OCSP status: Revoked

Watch for my next post where I will discuss how to minimise potential damage from faulty certificate revocation system.

Menu