build 2002031303 I verified this with a new profile. 1. Create a new profile 2. Set Edit/Preferences/Privacy & Security/Validation/Use OSCP to validate only certificates which specify an OSCP service URL This above maybe the default setting. 3. Surf to https://swww.canada.etrade.com/login.shtml 4. Receive the following error message: Error trying to validate certificate from swww.canada.etrade.com using OSCP - coorupted or unknown response. Error code: -8073. Page is fine in IE

->PSM.

Confirming.

cc relyea and nelsonb. We do see an awful lot of this error 8073 when doing OCSP. Is the response really corrupted or we just fail to parse it correctly?

*** Bug 132344 has been marked as a duplicate of this bug. ***

*** Bug 129264 has been marked as a duplicate of this bug. ***

Dup of bug 122165?

Actually, Bug 123114 and Bug 122165 are both duplicates of this one. Or the other way around, depending on how you look at these things :-)

*** Bug 123114 has been marked as a duplicate of this bug. ***

*** Bug 122165 has been marked as a duplicate of this bug. ***

There has also been a change in the code causing paypal to show this. This site did work previously... I think about 2-3 weeks ago, that's when the broken OSDN banners on sourceforge started working again instead of returning the OSCP failure. https://www.paypal.com

*** Bug 134193 has been marked as a duplicate of this bug. ***

Updated OS since this occurs on other OS's.

nsbeta1

*** Bug 135933 has been marked as a duplicate of this bug. ***

*** Bug 137672 has been marked as a duplicate of this bug. ***

I just bothered looking up this bug. It has occured on Win32 and Linux (Intel) since 0.9.8, when connecting with Wells Fargo online banking: "Error trying to validate certificate from banking.wellsfargo.com using OSCP – corrupted or unknown response. Error Code: -8073" It used to work prior to 0.9.8. The only bits of new info I can offer are: 1. Galeon releases commensurate with Moz 0.9.9 have no problem (don't know how that works!) navigating this site. 2. If I nav this site with IE 5, it dosen't complain, but when you click the padlock it says "This certificate has failed to verify for all of its intended purposes". I did some investigation of banking.wellsfargo.com's certs, and it turns out

I just bothered looking up this bug. It has occured on Win32 and Linux (Intel) since 0.9.8, when connecting with Wells Fargo online banking: "Error trying to validate certificate from banking.wellsfargo.com using OSCP – corrupted or unknown response. Error Code: -8073" It used to work prior to 0.9.8. The only bits of new info I can offer are: 1. Galeon releases commensurate with Moz 0.9.9 have no problem (don't know how that works!) navigating this site. 2. If I nav this site with IE 5, it dosen't complain, but when you click the padlock it says "This certificate has failed to verify for all of its intended purposes". I did some investigation of banking.wellsfargo.com's certs, and it turns out

Still seeing this in Linux RC1 on PayPal links. I think this should have higher priority since it cripples one of the most common web commerce mechanisms.

(Following on my truncated comments in Comment #16 and #17, sorry for the duplicate comments, must be this dodgy browser I'm using :-P) Unfortunately my investigation of banking.wellsfargo.com OSCP problems doesn't seem relevent now - for a while I was having a dialogue with their support guys trying to convince them their certificate had expired (which it was, according to IE, which happily used it anyway!!). However, they have a new cert in their now, and Moz still refuses to touch the page, so I guess it's the beast's fault after all! So in the meantime I'm going to contact the Galeon guys and try and find out why Galeon 1.2 (based on Moz 0.9.9) has no problems... And finally, what can we do to get this bug on the "make RC2 not suck" list (bug 138000)?

The problem with the etrade certificate is exactly the same as the problem with banking.wellsfargo.com, and as the remaining problem I have reported yesterday on bug 54104. These two entities have a certificate issued by Verisign with a AIA extension that points to the Verisign OCSP responder, but they have not bought OCSP service from Verisign, therefore all the request bounce with a unauthorized error, that Mozilla seems to have problems to parse. To solve this issue, Mozilla needs first to be able to correctly parse this answer (it's a 5 byte unsigned response). Now the best behaviour is hard to define. It seems that many people have a certificate with the AIA extension, but did not pay Verisign for the OCSP service and will be in this situation. Right now, it's not possible to connect to their site if OCSP is enabled wich is really annoying. It means that "Use OCSP to verify only certificate that specify an OCSP service URL" is not a setting that can be set for a convenient navigation. I see two solutions : - The wrong way : Do as IE and allows access to the site without warning. The user will be aware of the problem only if he checks the certificate details. - The right way : Display a security warning that certificate for this site reference an OCSP responder, but that the OCSP responder does not want to give an OCSP status for this site. Have a check box below "warn me when the referenced OCSP responder refuses to give a status for the site" that can be unchecked by the user if he doesn't want to see the warning. This behaviour will exactly similar to the warning for low grade security sites.

There are lots of dupes to this bug. Instead of adding one more I'll add another strange observation. This is happening with Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.0+) Gecko/20020427. Go to http://www.consors.de/cgi-bin/nph-smartbroking.cgi?type=html (this will redirect to on of a set of https-sites). Interesting enough, this page always works for me with severeal version under Linux. pi

*** Bug 140493 has been marked as a duplicate of this bug. ***

taking

*** Bug 135614 has been marked as a duplicate of this bug. ***

Assuming the analysis in comment 20 is correct (thanks Jean-Marc), I think the work for this bug consists of three steps: 1) NSS must properly handle the response and provide the application with a more informative error code. I filed bug 141256 on NSS. Dependent on the new code, Mozilla can have special handling to ignore the error, or do what the user prefers. I suggest. 2) Once bug 141256 is fixed, we implement the strategy to simply ignore this kind of failure, and connect anyway. The bug will be fixed then. 3) We can file a new bug, depending on this one, for implementing the warnings and preferences suggested in comment 20.

Just to help people find this bug. The error message it gives is sometimes: "Error establishing an encrypted connection to www2.postbank-banking.de. Error Code: -5985." Since bug 135614 has been marked a dupe of this bug.

Changing summary from OSCP to OCSP

*** Bug 134499 has been marked as a duplicate of this bug. ***

Changing summary from OSCP to OCSP.

*** Bug 142552 has been marked as a duplicate of this bug. ***

*** Bug 143183 has been marked as a duplicate of this bug. ***

I'm updating the summary to include the error code. Whenever I tried, I saw the error code -8073. However, some people report -5961, for example bug 141903, and their problems go away, too, if they disable OCSP. However, while the reporter of 141903 sees -5961, I see -8073 when I try to reproduce.

*** Bug 141903 has been marked as a duplicate of this bug. ***

*** Bug 140936 has been marked as a duplicate of this bug. ***

One thing should be sure - if the OCSP request is not successful, the user should be alerted. The reason for this is to prevent an Denial of Service attack on the OCSP responder. Blocking access to the OCSP service, or creating a proxy OCSP service which just returns an invalid respone should not cause the browser to treat everything as trusted.

One big problem, as noted in 141256, is that some CAs have been including the OCSP URL in their certs even though they refuse to service them because their customers didn't pay them for it. While popping-up a dialog every time for all Verisign certs that the request is unauthorized is intrusive, I don't see much else of a solution, and I agree with Steve here. The fact that OCSP runs over an insecure HTTP link makes it very easy to compromise as you point out. The real solution probably involves running OCSP with SSL (however that would work, cf recursion problem) or having the OCSP responses be signed, like CRLs (the recursion problem exists here too).

http://www.faqs.org/rfcs/rfc2560.html According to RFC2560 "definitive responses from the OCSP responder SHALL be digitally signed..." (definitive responses are "good", "revoked" or "unknown"). I don't see why we need to transport them over SSL. VeriSign's practice of including OCSP responder information for non-subscribing customers is just a plain bad decision.

Somebody on IRC told me, he/she also sees -5981, connection refused. We obviously need to give better UI feedback when there are problems with OCSP validation.

I get -8073 when trying to login at www.vanguard.com (the login link under Personal Investors) the full message is "Error trying to validate certificate from flagship5.vanguard.com using OSCP - corrupted or unknown response. Error Code: -8073"

*** Bug 141973 has been marked as a duplicate of this bug. ***

Bill, I was suggesting to use SSL merely to authenticate the OCSP source. The way we are doing it now, we just connect to the TCP port and get an unsigned response. Someone could intercept the TCP port and send a faked good response. My suggestion for resolving that was to either use SSL for the transport - which would check the OCSP responder's certificate and authenticate the source, or have each OCSP response be signed - which would accomplish the same thing for this purpose. I checked the RFC - it is unfortunate that this only says "SHALL" rather than "MUST". I think this is a major flaw in the OCSP protocol. Verisign responses - at least the unauthorized ones - do not comply with that suggestion. They are plain unsigned HTTP responses. I think we should talk to Verisign about this. Perhaps we could also add some options in NSS and the client to be more strict with OCSP and only trust signed responses.

*** Bug 144720 has been marked as a duplicate of this bug. ***

*** Bug 54104 has been marked as a duplicate of this bug. ***

The NSS fix has been checked in to the tip, for NSS 3.5 . NSS will now correctly detect if the responder refuses to validate. Kai, it is now up to you to decide what PSM should do with the SEC_ERROR_OCSP_UNAUTHORIZED_RESPONSE error.

*** Bug 146857 has been marked as a duplicate of this bug. ***

*** Bug 149231 has been marked as a duplicate of this bug. ***

The NSS fix is now in the Mozilla trunk (NSS_CLIENT_TAG).

This bug is fixed by 141256. The fix is to correctly report the unauthorized response from the OCSP responder. The user will still not be able to connect to the site, but that's the correct behavior. We will work to have the fix to 141256 landed on the branch.

Marking fixed as per Stephane's comment. More info: When using a trunk build (having the patch from 141256), one does no longer see a "corrupted or unknown response" error message. Instead, one will see the error message "error trying to validate ... using OCSP - unauthorized request".

Verified on 6/12 trunk.

Since this bug has been marked as fixed, I have filed bug 151271: "Allow browsing sites after warning when OCSP validation failure occurs, -8073, -5961"

Verified on trunk.

removing adt1.0.0 keyword, since we don't have any patch to check in within this bug.

*** Bug 152776 has been marked as a duplicate of this bug. ***

Since there is no patch in this bug and no plan to do something on the branch, removing this bug from the branch radar.

Removing the item for this bug from the release notes for 1.1beta and beyond.

I still do get Error codes -5961 and the sites are refusing the work. I use "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6)" and Firefox v0.8 The bug seems to trigger only if I use autoproxy script (autoproxy.pac), which tries to forward most of the connections through a proxy which uses different tcp port than 80. Outgoing traffic to port 80/tcp is blocked by a firewall. When autoproxy is used and I have OCSP valdiation enabled, and I try to connect to some HTTPS-site, the Firefox/Mozilla do not use somehow the proxies I have set in autoproxy.pac for OCSP. Instead it tries to open a direct TCP connection bypassing the proxy, so firewall reports something like this: Aug 11 11:54:42 localhost kernel: IT out rej rest IN= OUT=eth0 SRC=<my_host_ip_here> DST=12.166.243.30 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=4096 DF PROTO=TCP SPT=45975 DPT=80 WINDOW=5840 RES=0x00 CWR ECE SYN URGP=0 12.166.243.30 is one of Verisign's IP addresses. So autoproxy settings are not used in OCSP? A bug or a feature? For example trying with the mentioned settings to connect to the URI in this bug's examples, I get this dialog window: Error establishing and excrypted connection to swww.canada.etrade.com. Error Code: -5961 When [OK] is hit, I get this dialog window: The Document contains no data. (Cannot reopen the bug, but hopefully the message gets through this way also. Maybe there is a new bug concerning this issue, but didn't find.)

zimon, please open a new bug and refer to this bug there.