Closed
Bug 662996
Opened 13 years ago
Closed 12 years ago
OCSP requests leak cookies
Categories
(Core :: Security: PSM, defect)
Core
Security: PSM
Tracking
()
RESOLVED
FIXED
mozilla18
People
(Reporter: st3fan, Unassigned)
References
Details
(Keywords: privacy)
Attachments
(1 file)
858 bytes,
patch
|
briansmith
:
review+
KaiE
:
superreview+
KaiE
:
feedback+
|
Details | Diff | Splinter Review |
During testing of some OCSP server side code I saw Firefox do the following OCSP request: POST / HTTP/1.1 Host: evsecure-ocsp.verisign.com 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.
Updated•13 years ago
|
Component: Security → Security: PSM
QA Contact: toolkit → psm
Updated•13 years ago
|
OS: Mac OS X → All
Hardware: x86 → All
Comment 1•13 years ago
|
||
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 :)
Attachment #538159 -
Flags: feedback?(kaie)
Comment 2•13 years ago
|
||
Stefan, do you know what the STR are? I was not able to reproduce this, even after visiting several URLs on verisign.com and then going to paypal.com. Gavin, thanks for the patch. I will take a look at it once I am able to reproduce the bug.
Keywords: privacy
Reporter | ||
Comment 3•13 years ago
|
||
STR: Go to http://www.verisign.com 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 https://twitter.com Go to http://www.godaddy.com Login Validate that a cookie has been set (should be for godaddy.com) Quit Firefox (to force OCSP since I don't think it is fully cached?) Go to https://sa.tk (my domain that has a godaddy cert) It might be easier to enable ocsp.require but you don't have to.
Updated•13 years ago
|
Attachment #538159 -
Flags: feedback?(bsmith)
Comment 4•13 years ago
|
||
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 https://twitter.com - 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•13 years ago
|
||
Comment on attachment 538159 [details] [diff] [review] wild guess sr=kaie Gavin, thanks for this patch. Do you want to take the bug and drive it in, or should we?
Attachment #538159 -
Flags: superreview+
Attachment #538159 -
Flags: review?(bsmith)
Attachment #538159 -
Flags: feedback?(kaie)
Attachment #538159 -
Flags: feedback?(bsmith)
Attachment #538159 -
Flags: feedback+
Comment 6•13 years ago
|
||
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•13 years ago
|
||
Comment on attachment 538159 [details] [diff] [review] wild guess r+. 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.
Attachment #538159 -
Flags: review?(bsmith) → review+
Updated•13 years ago
|
Keywords: checkin-needed
Comment 8•13 years ago
|
||
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...
Updated•13 years ago
|
Assignee: nobody → gavin.sharp
Comment 9•13 years ago
|
||
http://hg.mozilla.org/integration/mozilla-inbound/rev/70634342ce16
Flags: in-testsuite?
Keywords: checkin-needed
Comment 12•13 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/70634342ce16
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla8
Comment 14•12 years ago
|
||
This was backed out in bug 703024.
Assignee: gavin.sharp → nobody
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: mozilla8 → ---
Reporter | ||
Comment 16•12 years ago
|
||
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•12 years ago
|
||
Yeah, looks like bug 627616 means that the old patch should work as-is (it won't affect proxy authentication).
Comment 18•12 years ago
|
||
I relanded this https://hg.mozilla.org/integration/mozilla-inbound/rev/da6a55f4fdae
Target Milestone: --- → mozilla18
Comment 19•12 years ago
|
||
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.7 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.11 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•12 years ago
|
||
comment removed https://hg.mozilla.org/integration/mozilla-inbound/rev/c861b47cd0ff
Comment 21•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/da6a55f4fdae https://hg.mozilla.org/mozilla-central/rev/c861b47cd0ff
Status: REOPENED → RESOLVED
Closed: 13 years ago → 12 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•