151271 - Allow browsing sites after OCSP validation failure

Status: RESOLVED WONTFIX

(Core Graveyard :: Security: UI, enhancement, P2)

Description

[Stephen Ostermiller]

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.

Comment 1

[Alfred Kayser]

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...

Comment 2

[John Unruh]

Upgrading priority and severity.

Comment 3

[John Unruh]

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

Comment 4

[John Unruh]

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 

Comment 5

[Tim Olsen]

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)

Comment 6

[Tim Olsen]

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

Comment 7

[Alfred Kayser]

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.

Comment 8

[John Unruh]

OCSP does not work through a proxy - bug 111384. Marking dependent on that bug.

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

This bug is not blocked by bug 111384.  
Rather it is an enhancement request to work around bug 111384.

Comment 10

[John G. Myers]

Mass reassign ssaux bugs to nobody

Comment 11

[Josh Birnbaum]

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

Comment 12

[Kai Engert (:KaiE:)]

changing obsolete psm* target to --- (unspecified)

Comment 13

[Bob Lord]

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.

Comment 14

[Aleksey Nogin]

(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.

Comment 15

[Bob Lord]

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)

Comment 16

[Aleksey Nogin]

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.

Comment 17

[Bob Lord]

(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. 

Comment 18

[roland]

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.