Closed Bug 151271 Opened 21 years ago Closed 6 years ago
Allow browsing sites after OCSP validation failure
This report stems from bug 130885 which was closed after changing the error message. The error message used to be "Error trying to validate certificate from flagship5.vanguard.com using OSCP - corrupted or unknown response. Error Code: -8073" or code -5961. The new message is "error trying to validate certificate from flagship5.vanguard.com using OSCP - unauthorized request" After the message, mozilla does not allow you to browse the site. Verisign issues certificates with an AIA extension that points to the Verisign OCSP responder even if the customer has not bought OCSP service from Verisign. All of the web sites will fail to load in Mozilla if OCSP is enabled. (As a workaround for this bug you can disable OCSP in Edit -> Preferences -> Privacy & Security -> Validation) Mozilla should allow such sites to be browsed after alerting the user. 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.
This bug is blocked access to 'secure' site, so severity should be higher than 'enhancement', at least 'normal', but this is a 'major' thing, as access is really blocked (so it is even a blocker?). Let's hope that bugs blocking access are really not considered to be 'enhancements' to a software package which primary purpose is to access sites...
Upgrading priority and severity.
Severity: enhancement → major
Priority: P3 → P2
*** Bug 168162 has been marked as a duplicate of this bug. ***
Marking works for me. I have no problem reacing https://flagship5.vanguard.com with OCSP turned on. Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021106
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
Target Milestone: --- → 2.4
Version: 2.3 → 2.4
try clicking on "log on" I get "Error trying to validate certificate from flagship5.vanguard.com using OSCP - response contains a date which is in the future" with no option to continue loading anyway. (but I can get around it by turning off OSCP in Preferences)
nevermind. that was with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826 works for me too using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021016
Still doesn't WORKFORME! Tested with Mozilla 2002110610, W2K, Thinkpad, PIII, 512MB, etc...: With OCSP turned on (checked 'use OCSP with sites that specify an OCSP service ULR): Error Message: Error establishing an encrypted connection: Error Code -5981. With OCSP set to 'Use OCSP ... using this URL and signer: 'Builtin Object Token: ValiCert OCSP Responder': Error trying to validate certificate from flagship5.vanguard.com using OCSP - directory lookup error. After both, the browser refuses the load the page at all. With OCSP turned off: it loads as it should. Note that IE5.5 is also able to load the page. Probably the difference is the our 'proxy', being an employee at a large enterprise, I'm forced to work behind a proxy, which is normally not a problem, but it could be the cause of the failing OCSP. Note, the failing OCSP is one thing, reducing the security level because the certification is not OCSP validated (like IE5.5 apparently doesn't do?), but Mozilla refusing to load the page at all is 'officially' a blocking problem. Having a stricter security policy is nice, but when the implementation fails, and users have to turn off the extra security the user perception may be that Mozilla is less secure than the 'standard' browser.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
This bug is not blocked by bug 111384. Rather it is an enhancement request to work around bug 111384.
Severity: major → enhancement
No longer depends on: 111384
Summary: Allow browsing sites after warning when OCSP validation failure occurs, -8073, -5961 → Allow browsing sites after OCSP validation failure
Mass reassign ssaux bugs to nobody
Assignee: ssaux → nobody
Status: REOPENED → NEW
*** Bug 310575 has been marked as a duplicate of this bug. ***
changing obsolete psm* target to --- (unspecified)
Target Milestone: psm2.4 → ---
Target Milestone: --- → mozilla1.9alpha
Version: psm2.4 → Trunk
I'm not sure I like this idea. If the CA has revoked the server's certificate, you should not get to visit the site. Revoking a cert is a *very* strong action. Further, allowing people to browse a site with a revoked certificate will help phishers more than it will help average users.
(In reply to comment #13) > If the CA has revoked the server's certificate, > you should not get to visit the site. Nobody argues against that. This bug is about what happens when the validation process itself fails, not about what happens when it succeeds, but finds out that the cert is revoked.
How does the client distinguish between a failed OCSP transaction (OCSP responder is offline, reponder gives a nonsense reply, etc.) and an attack where the attacker compromises the key material of the web site, and then blocks your access to the OCSP responder? If the CA populates the AIA extension, they intend for clients to use it. A failure to get a proper response is also a serious issue. The client is online, afterall. (At least in the case of the browser)
Well, the "the URL does not match the certificate" is currently just a warning and allows to connect to the web site anyway, even though this could easily be a man-in-the-middle attack. I do not see why a failed OCSP transaction should be considered more serious than a potential man-in-the-middle attack.
(In reply to comment #16) > Well, the "the URL does not match the certificate" is currently just a warning > and allows to connect to the web site anyway, even though this could easily be > a man-in-the-middle attack. I do not see why a failed OCSP transaction should > be considered more serious than a potential man-in-the-middle attack. I completely agree, which is why I want to limit the user's ability to connect to such sites as well. As phishers start using SSL more, we need to be ahead of the curve and make sure we don't give users enough rope to hang themselves.
There is no reason why this error should be more severe than the error for self signed certificates (or the non-matching CN mentioned before). And as has been discussed in the last few weeks in detail (e.g. http://arstechnica.com/security/2014/04/how-heartbleed-transformed-https-security-into-the-stuff-of-absurdist-theater/) soft-fail OCSP is completely useless. Without enabling hard-fail in Firefox OCSP checking is broken/useless and with hard-fail enabled, this bug makes it impractical.
Status: NEW → RESOLVED
Closed: 20 years ago → 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.