Opened 8 years ago

Closed 8 years ago

#3754 closed defect (fixed)

SafeCache implementation breaks OCSP validation

Reported by: gk Owned by: mikeperry
Priority: High Milestone:
Component: TorBrowserButton Version: Torbutton: 1.4.0
Severity: Keywords: MikePerryIterationFires20110911
Cc: Actual Points: 1
Parent ID: Points: 1
Reviewer: Sponsor:

Description

If one configures Firefox to fail hard if there occurs an error while validating certificates using OCSP the SafeCache implementation leads to failures that do not exist without it. Steps to reproduce:

1) Configure Firefox properly (check "Use the Online Certificate Status Protocol (OCSP) to confirm the current validity of certificates"; Use "Validate all certificates using the following OCSP Server" and take the first one (in my case: https://rca.e-szigno.hu/ocsp); check "When an OCSP connection fails, treat the certificate as invalid"

2) Restart Firefox and surf to e.g. https://anonymous-proxy-servers.net/forum/ if that does not already break the validation then open in a second tab https://ssl.scoogle.org and it breaks always.

3) Do the same without Torbutton installed and it works fine.

The problematic code is (for whatever reason, I am currently debugging it as JonDoFox is affected as well):

if(!this.readCacheKey(channel.cacheKey)) {
        this.setCacheKey(channel, channel.URI.host);
      } else {
        SSC_dump("Existing cache key detected; leaving it unchanged.");
      }

If you comment that code everything works fine in Torbutton again.

Child Tickets

Change History (5)

comment:1 Changed 8 years ago by mikeperry

Keywords: MikePerryIterationFires20110911 added

comment:2 Changed 8 years ago by mikeperry

My current plan is to move us to using a string, and solve both this issue and #3666 at the same time.

comment:3 Changed 8 years ago by mikeperry

Ok, the string did not solve the issue...

Monitoring about:cache definitely shows that without safecache, the ocsp requests are getting a postID prepended, and it is a very high value (the internal use of mPostID increments starting from 0). Perhaps the OCSP support is also abusing the cacheKey for internal use? But that still doesn't explain why leaving it alone and appending a different string at the end of the cache key makes a difference...

comment:4 Changed 8 years ago by mikeperry

Oh snap. Prepending the domain=key value seems to be working. I as appending it before.

comment:5 Changed 8 years ago by mikeperry

Actual Points: 1
Points: 1
Resolution: fixed
Status: newclosed

Ok, this is fixed using the #3666 patch. Fix is pushed to origin, will appear in the TBB that supports Torbutton 1.4.2.

Note: See TracTickets for help on using tickets.