Last Comment Bug 662996 - OCSP requests leak cookies
: OCSP requests leak cookies
: privacy
Product: Core
Classification: Components
Component: Security: PSM (show other bugs)
: unspecified
: All All
-- major (vote)
: mozilla18
Assigned To: Nobody; OK to take it and work on it
: David Keeler [:keeler] (use needinfo?)
: 703020 786229 (view as bug list)
Depends on:
Blocks: 703024
  Show dependency treegraph
Reported: 2011-06-08 18:16 PDT by Stefan Arentz [:st3fan]
Modified: 2012-09-04 18:50 PDT (History)
15 users (show)
bzbarsky: in‑testsuite?
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

wild guess (858 bytes, patch)
2011-06-08 18:41 PDT, :Gavin Sharp [email:]
brian: review+
kaie: superreview+
kaie: feedback+
Details | Diff | Splinter Review

Description User image Stefan Arentz [:st3fan] 2011-06-08 18:16:35 PDT
During testing of some OCSP server side code I saw Firefox do the following OCSP request:

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Content-Length: 115
Content-Type: application/ocsp-request
Cookie: v1st=YX32X24T8E9X; __utma=136232671.83772523.1; __utmz=1369032.23772523.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)

What worries me is that the Cookie header is included.

I think this is a security problem because because it is identifying me to the owner of the OCSP server.

Not only does the owner of the OCSP server now know what site I am visiting (through the SSL certificate hash in the OCSP request body), it can also identify me.

This can be further exploited by OCSP server owners by somehow getting cookies setup for the domain. For example by embedding ads. (I know this is a stretch but it is certainly possible)

Since these OCSP requests are basic API requests, I think they should be as minimal as possible, which means leaving out any headers that are not required. In my opinion that should also include the User-Agent header.
Comment 1 User image :Gavin Sharp [email:] 2011-06-08 18:41:02 PDT
Created attachment 538159 [details] [diff] [review]
wild guess

I don't know that this is the right fix, but it seems to be the only place where NSS code creates a necko channel (via trySendAndReceiveFcn, which is certainly used by PKIX OCSP code). Also it's untested :)
Comment 2 User image Brian Smith (:briansmith, :bsmith, use NEEDINFO?) 2011-06-10 00:14:11 PDT
Stefan, do you know what the STR are? I was not able to reproduce this, even after visiting several URLs on and then going to

Gavin, thanks for the patch. I will take a look at it once I am able to reproduce the bug.
Comment 3 User image Stefan Arentz [:st3fan] 2011-06-10 07:44:50 PDT

Go to
Browse around for example change to another language
Validate that a cookie has been set
Quit Firefox (to force OCSP since I don't think it is fully cached?)
Go to

Go to
Validate that a cookie has been set (should be for
Quit Firefox (to force OCSP since I don't think it is fully cached?)
Go to (my domain that has a godaddy cert)

It might be easier to enable ocsp.require but you don't have to.
Comment 4 User image Kai Engert (:kaie) 2011-06-28 06:02:37 PDT
I did this:
- enable strict ocsp
- start debug build with NSPR_LOG_MODULES="cookie:5"
- go to verisign (gets a cookie)
- quit firefox
- start firefox
- go to
- look at trace output, search for ocsp,
  a cookie was sent for an ocsp request

I agree we should not do this.

I applied the patch, and I repeated the above.
I no longer see a cookie being sent to the ocsp server.
Comment 5 User image Kai Engert (:kaie) 2011-06-28 06:04:35 PDT
Comment on attachment 538159 [details] [diff] [review]
wild guess


Gavin, thanks for this patch. Do you want to take the bug and drive it in, or should we?
Comment 6 User image :Gavin Sharp [email:] 2011-06-28 14:45:57 PDT
I can take the bug, though I'm not really familiar with the test situation for this code. Are there any automated OCSP tests that a test for this bug could easily be added to?
Comment 7 User image Brian Smith (:briansmith, :bsmith, use NEEDINFO?) 2011-06-28 16:14:05 PDT
Comment on attachment 538159 [details] [diff] [review]
wild guess


Unfortunately, we don't have any automated tests for OCSP in Firefox--partly because we don't have any way of generating OCSP responses. Kai's manual test procedure will have to do for now.
Comment 8 User image Boris Zbarsky [:bz] (still a bit busy) 2011-07-12 09:03:31 PDT
Please do NOT add the checkin-needed keyword in the future for patches without metadata.

I took a guess as to what that should be in this case, but next time I'll just remove the keyword...
Comment 9 User image Boris Zbarsky [:bz] (still a bit busy) 2011-07-12 09:09:07 PDT
Comment 10 User image Kai Engert (:kaie) 2011-07-12 09:32:39 PDT
Ok, thanks a lot Boris!
Comment 11 User image :Gavin Sharp [email:] 2011-07-12 09:59:09 PDT
Sorry - I intended to land this myself, I just forgot about it.
Comment 13 User image Brian Smith (:briansmith, :bsmith, use NEEDINFO?) 2011-11-16 11:40:46 PST
*** Bug 703020 has been marked as a duplicate of this bug. ***
Comment 14 User image :Gavin Sharp [email:] 2012-06-14 13:48:06 PDT
This was backed out in bug 703024.
Comment 15 User image Jo Hermans 2012-08-28 08:17:47 PDT
*** Bug 786229 has been marked as a duplicate of this bug. ***
Comment 16 User image Stefan Arentz [:st3fan] 2012-08-28 08:54:06 PDT
Can we apply Gavin's patch again now that the dependencies for this bug have been resolved?

I still think this is a major privacy concern: CAs can effectively use this to track someone.
Comment 17 User image :Gavin Sharp [email:] 2012-08-28 13:01:54 PDT
Yeah, looks like bug 627616 means that the old patch should work as-is (it won't affect proxy authentication).
Comment 18 User image Patrick McManus [:mcmanus] 2012-09-04 09:32:38 PDT
I relanded this
Comment 19 User image Stefan Fleiter (:sfleiter) 2012-09-04 10:01:47 PDT
This looks suspicious:

     1.1 --- a/security/manager/ssl/src/nsNSSCallbacks.cpp
     1.2 +++ b/security/manager/ssl/src/nsNSSCallbacks.cpp
     1.3 @@ -72,16 +72,18 @@ nsHTTPDownloadEvent::Run()
     1.4    nsCOMPtr<nsIChannel> chan;
     1.5    ios->NewChannel(mRequestSession->mURL, nullptr, nullptr, getter_AddRefs(chan));
     1.6    NS_ENSURE_STATE(chan);
     1.8    // Disabled because it breaks authentication with a proxy, when such proxy
     1.9    // had been setup, and brings blue UI for EV certs.
    1.10    // chan->SetLoadFlags(nsIRequest::LOAD_ANONYMOUS);
    1.12 +  chan->SetLoadFlags(nsIRequest::LOAD_ANONYMOUS);

The comment seems to be outdated by the fix in bug 627616 and thus should be removed, shouldn't it?
Comment 20 User image Patrick McManus [:mcmanus] 2012-09-04 10:20:35 PDT
comment removed

Note You need to log in before you can comment on or make changes to this bug.