From d831e32fcc21624a60eee58071b93cdab7aec7aa Mon Sep 17 00:00:00 2001 From: Dhananjay Balan Date: Fri, 9 Aug 2019 15:13:31 +0200 Subject: [PATCH] Some small edits. Maybe I need to get an editor. --- blog/2019-08-06-trouble-with-ocsp.markdown | 50 ++++++++++++++-------- 1 file changed, 32 insertions(+), 18 deletions(-) diff --git a/blog/2019-08-06-trouble-with-ocsp.markdown b/blog/2019-08-06-trouble-with-ocsp.markdown index 981c798..b1ab382 100644 --- a/blog/2019-08-06-trouble-with-ocsp.markdown +++ b/blog/2019-08-06-trouble-with-ocsp.markdown @@ -6,30 +6,32 @@ comments: true 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 @@ curl https://crt.sh/?serial=03a0fe3ea814542cb7c2da251c8c6afa4d1e ## 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 +. + +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 @@ Whenever Onion Browser accesses a website with EV cert, (for e.g ), 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