d831e32fcc21624a60eee58071b93cdab7aec7aa — Dhananjay Balan 9 days ago 7d95467 ocsp deploy-2019-08-09
Some small edits.

Maybe I need to get an editor.
1 files changed, 32 insertions(+), 18 deletions(-)

M blog/2019-08-06-trouble-with-ocsp.markdown
M blog/2019-08-06-trouble-with-ocsp.markdown => blog/2019-08-06-trouble-with-ocsp.markdown +32 -18
@@ 6,30 6,32 @@ 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.
+ > This is a post about side channel information leak present in OnionBrowser OCSP requests. 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.
+ Digital certificates usually have long expiration, to reduce
+ maintenance overhead. Most of the cases CAs issue a certificate for
+ few years.
  
  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.
+ re-issue a certificate, but compromised certificate is still in the
+ wind. Online Certificate Status Protocol (OCSP) is designed to help
+ with this exact situation. 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.
+ 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 (server provided by the CA).
  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
- request.
+ > Note: 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
+ > request.
  
  ## 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
+ If the request is less than `255 bytes`, OCSP allows it to be passed as a GET path. A typical request looks like this
  
  ```bash
  GET http://ocsp.int-x3.letsencrypt.org/MFgwVqADAgEAME8wTTBLMAkGBSsOAwIaBQAEFH7maudymrP8%2BKIgZGwWoS1gcQhdBBSoSmpjBH3duubRObemRWXv86jsoQISA6D%2BPqgUVCy3wtolHIxq%2Bk0e


@@ 76,10 78,14 @@ ## 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.
+ is happening over HTTP. With the above dissecting example, an attacker
+ will know that it is highly probable that user is accessing
+ <https://check.torproject.org>.
+ 
+ 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


@@ 94,6 100,14 @@ <https://check.torproject.com>), the OCSP request is routed via
  **regular** transport, not via onion network as one would assume.
  
+ An attacker observing network can see any of the OCSP requests, and
+ thus know a subset of sites user is visiting, even if they are on Tor.
+ 
+ A weird detail is that the [**`.onion` endpoint of NYTimes has
+ an EV certificate**](https://crt.sh/?id=939411753). The ocsp request
+ for it is send via plain transport and gets leaked, if you were using
+ OnionBrowser to access it.
+ 
  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