title: "Trouble with OCSP"
tags: ocsp, tor, security, privacy
> This is a post about side channel information leakage that was present in OnionBrowser in some OCSP flows. This post omits a lot of details about OCSP protocol.
Digital certificates are issued for a longer timespan. It reduces maintenance overhead. Most of the cases CAs issue a certificate and they are valid until the expiration time.
But what are we to do when a certificate is compromised? We can
re-issue a certificate, but the old one is still in the wind. That's
where Online Certificate Status Protocol comes in. It defines a way to
check validity of a certificate in a timely[^1] manner.
OCSP[^2] works roughly as follows in an https connection:
1. Client looks up the OCSP responder server from `AuthorityInfoAccess`section in the certificate.
2. Client crafts a OCSP request and sends it to OCSP responder.
3. Responder returns the current status of the certificate, one of `good`, `revoked` or `unknown`
There are many other interactions defined in the OCSP ecosystem. Maybe
the most important one is [OCSP
Stapling](https://en.wikipedia.org/wiki/OCSP_stapling). In stapling
the original request server sends back OCSP validation message with
the certificate itself, removing the need for another seperate
## Dissecting an OCSP Request
If the request is <255 bytes, OCSP allows it to be passed as a GET path. A typical request looks like this
The request is `URL-Encoded > BASE64 encoded > ASN-1` data. After decoding, one can use `ocsptool` from [GnuTLS](https://www.gnutls.org/) to read it.
echo -n "MFgwVqADAgEAME8wTTBLMAkGBSsOAwIaBQAEFH7maudymrP8%2BKIgZGwWoS1gcQhdBBSoSmpjBH3duubRObemRWXv86jsoQISA6D%2BPqgUVCy3wtolHIxq%2Bk0e" \
| python -c "import sys, urllib.parse as ul; print(ul.unquote(sys.stdin.read()));" \
| base64 -d \
| ocsptool -i
OCSP Request Information:
Hash Algorithm: SHA1
Issuer Name Hash: 7ee66ae7729ab3fcf8a220646c16a12d6071085d
Issuer Key Hash: a84a6a63047dddbae6d139b7a64565eff3a8eca1
Serial Number: 03a0fe3ea814542cb7c2da251c8c6afa4d1e
.. and then lookup the cert parameters
Issuer: (CA ID: 16418)
commonName = Let's Encrypt Authority X3
organizationName = Let's Encrypt
countryName = US
Not Before: Mar 29 00:08:51 2019 GMT
Not After : Jun 27 00:08:51 2019 GMT
commonName = check.torproject.org
## Privacy Takes a Backseat.
Careful examination of above workflow will reveal that the OCSP flow
is happening over HTTP. Most issuers seem to stick to http; possibly
to avoid cyclical dependencies. This means man-in-the-middle leakage
of certificates a user is validating is happening, and by extension
leakage of websites user is accessing.
## Onion Browser
iOS has inbuilt mechanism for checking revocations. They seem to be
only enforced for
certificates though. This is not a bad thing at all, but it creates a
weird situation where it leaks urls with EV certs from [Onion
(as far as I can tell) Tor browser on iOS.
Whenever Onion Browser accesses a website with EV cert, (for e.g
<https://check.torproject.com>), the OCSP request is routed via
**regular** transport, not via onion network as one would assume.
I stumbled upon this accidently while inspecting requests from my
iPhone with [mitmproxy](https://mitmproxy.org/). The bug was reported
to Onion Browser team and [they have a nice write up of the
it is hard to fix. :-(
[^1]: Opposed to checking against a [Certificate Revocation List](https://en.wikipedia.org/wiki/Certificate_revocation_list).
[^2]: Familiar readers will note that this is plain OCSP, the non-stapling kind.