Closed Bug 130885 Opened 23 years ago Closed 22 years ago

OCSP validation failure, -8073, -5961

Categories

(Core Graveyard :: Security: UI, defect)

1.0 Branch
x86
All
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: gaborliptak, Assigned: KaiE)

References

()

Details

(Keywords: regression, relnote)

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.
Assignee: mstoltz → ssaux
Component: Security: General → Client Library
Product: Browser → PSM
QA Contact: bsharma → junruh
Version: other → 2.2
Confirming.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
OS: Windows 2000 → All
nsbeta1
Keywords: 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
Assignee: ssaux → kaie
Keywords: nsbeta1nsbeta1+, regression
Whiteboard: [adt2 RTM]
*** 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.
Depends on: 141256
No longer depends on: 141256
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. ***
Depends on: 141256
Keywords: relnote
Changing summary from OSCP to OCSP.
Summary: OSCP validation failure → OCSP validation failure
*** 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.
Summary: OCSP validation failure → OCSP validation failure, -8073, -5961
*** 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.
Blocks: 143047
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".
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → VERIFIED
Keywords: adt1.0.0
removing adt1.0.0 keyword, since we don't have any patch to check in within this
bug.
Keywords: adt1.0.0
*** 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.
Keywords: nsbeta1+
Whiteboard: [adt2 RTM]
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.
Product: PSM → Core
Version: psm2.2 → 1.0 Branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.