New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 35 users

Issue metadata

Status: Fixed
Closed: May 2014
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

  • Only users with EditIssue permission may comment.

Sign in to add a comment

Check For Server Certificate Revocation checkbox is confusing

Project Member Reported by, Apr 9 2014 Back to list

Issue description

(See screenshot.)

The recent "Heartbleed" security adventure convinced many people that they need to re-key/re-CSR and revoke, and many "power users" believe that Chrome is less safe because the checkbox is unchecked by default. They then advise people to turn it on, thinking it will significantly help.

Of course, in reality, OCSP does nothing (soft-fail is "nothing"). And it cannot plausibly be made to be hard-fail for performance and reliability reasons.

And then there are the privacy concerns of turning on OCSP.

Can we more meaningfully/accurately label this checkbox?

Or, can we remove it? (Perhaps too radical; just throwing it out there.)
5.4 KB View Download

Comment 1 by, Apr 9 2014

Why is this checkbox there to begin with if it is never a good idea to check it?

Comment 2 by, Apr 9 2014

 Issue 361696  has been merged into this issue.

Comment 3 by, Apr 9 2014

+1 to #1. Get rid of it. It is confusing because it sounds useful... but checking it does effectively nothing.
 Issue 361230  has been merged into this issue.
So. I'm trying to understand.  Chromium removed the soft OCSP, which is fair, that does nothing.  Does this mean it removed the equivalent of (in Firefox about:config):
security.OCSP.require;true  (force a hard fail if OCSP server can't be contacted - reasonable in a MITM)
or... far more useful for most.
security.ssl.enable_ocsp_stapling;true  (use OCSP stapling where onus of resigning and revalidating continually is put on the remote site - supported in IE9+, Firefox 28, and, supposedly, Chrome 12+)

The 2nd one is the one I'm more concerned about.  Is that still automatically done in Chromium?
 Issue 361230  has been merged into this issue.
Chromium has never exposed an option to require OCSP (hard fail).

Chromium has supported OCSP stapling on (Windows Vista+, Linux, ChromeOS), and that's always been enabled (independent of the checkbox).

Comment 8 by, Apr 10 2014

 Issue 361696  has been merged into this issue.

Comment 9 by, Apr 10 2014

Re #5: The problem with the hard fail is that the OCSP servers are pretty flaky/slow. So it would be pretty frustrating / impossible to actually use.

Comment 10 by, Apr 12 2014

I'm not sure I agree that enabling OCSP soft-fail is equivalent to "nothing" and therefore should not be an option. 

In some attack scenarios, OCSP soft-fail is indeed useless. The obvious example of this is a MITM attack on the client's network. If the attacker has enough control over the network to intercept the client's traffic to the server, then the OCSP traffic can also be intercepted and blocked -- rendering it useless to have it enabled.

But it is not useless in all attack scenarios. In situations where the attacker is not "near" the client, the attacker may not have the ability to block OCSP. Consider an attack through the domain registrar, which seems to have become a somewhat common attack vector recently. The attacker may change the nameservers for the domain, which will cause clients to be directed away from the real server. But this will not give the attacker any ability to block OCSP. Clients with OCSP enabled would have the possibility of detecting the attack. Granted, having OCSP enabled does not *guarantee* that the client will detect the attack since the OCSP request could fail for any number of other reasons. But it's still a certain amount of protection, and I would be disappointed if I could no longer choose to have it enabled.

In my opinion, the interface should offer certificate revocation checking in both soft and hard fail modes, allowing the user to make their own decision about what trade-off they want between security and usability.

Comment 11 by, Apr 12 2014

king4lex: if a site's DNS gets hijacked then the attacker can pass DV checks and get numerous, new certificates for the site issued to themselves. Having revoked an old cert doesn't help in that situation.
But what about EV certificates? If a site's DNS gets hijacked, new EV certificates can't be issued via domain validation.

Comment 13 by, Apr 13 2014

EV and DV certificates share the same origin. Thus an attacker can hijack one of the connections to the origin, even in the background, poison the cache etc and control the origin. EV doesn't provide that kind of security.

There was a "evonly" tag in HSTS for a while, but it got dropped along the way and no browser implements anything like it.

Comment 14 by, Apr 13 2014

Even if it's not different technically, it feels like Chrome is less secure when you see Firefox/IE blocking the page by default. I had to read this thread to understand why CRL check doesn't mean anything at all. 

Existence of checkbox and the behavior change caused by it makes that even more confusing. If checkbox gets removed at least people would need to look for justification. 

Comment 15 by, Apr 14 2014

Re #14: are you familiar with

Comment 16 by, Apr 14 2014

I agree this checkbox needs a better explanation. The help files don't explain it at all. Also I agree an option to make it hard-fail is required. I agree that it might not be a good option for the average user, but I would very much like to get a warning. Then I could decide whether it is probably OK (e.g. bad CA on a trusted network) or probably not (e.g. reliable CA while connected through public wifi). Even nicer would be if one could make it hard-fail for some CA's (known to have good uptime) but not all.

My open questions to what the checkbox exactly does:
- Does it enable CRL or OCSP (direct - stapling is on by default) or both?
- Do CRL results get cached? If so for how long?
- If they are cached why is it useless? Even if the DNS is hijacked I have my cached copy of the CRL from an earlier connection and I still get warned while connecting over a risky (e.g. public wifi) connection. Of course it still woudn't help for the 1st connection.
- Does it also enable checks on intermediate certificates or only the server certificate itself?
- Does it enable CRL or OCSP (direct - stapling is on by default) or both?


- Do CRL results get cached? If so for how long?

Up to the underlying certificate verification library (read: the OS on Windows/Mac). On other platforms, it's a variety of factors, but primarily gated by the HTTP cache.

- If they are cached why is it useless? Even if the DNS is hijacked I have my cached copy of the CRL from an earlier connection and I still get warned while connecting over a risky (e.g. public wifi) connection. Of course it still woudn't help for the 1st connection.

For a variety of reasons that are captured on the previous blog posts

- Does it also enable checks on intermediate certificates or only the server certificate itself?

The chain.

Comment 18 by, Apr 15 2014

>> Does it enable CRL or OCSP (direct - stapling is on by default) or both?
>  Both
Does that mean if a certificate provides both options that it works correctly if at least one of them is currently available?

> For a variety of reasons that are captured on the previous blog posts
I searched for it and couldn't find it. Could you please link to them?

> Up to the underlying certificate verification library 
Again I wasn't able to find it. Do you have a link for Windows?

According to Chrome 12 showed the same warning symbol if revocation check wasn't possible as for mixed-content. Is that still the case if the checkbox is enabled? This seems like a good compromise between hard and soft fail especially given that the checkbox isn't on by default (warning might confuse novice users) and without any warning useless (as discussed above).

What happens with OCSP stapling? Chrome doesn't support multi-stapling yet, right? Does the checkbox enable regular OCSP/CRL checks for the rest of the chain (which isn't verified by the stapling)?
Status: Assigned (was: NULL)
#18: Here is a link to agl's blog post about CRLSets and the non-usefulness of (non-stapled) OCSP:

Comment 21 by, May 6 2014

I created a test page to check how different browsers handle revocation check: What I noticed about Chrome is
1) Chrome sometimes warns if the OCSP/CRL isn't available but it does so randomly/unreliably. At least I cannot detect a pattern of when it shows the warning. Also the warning is easy to overlook (it is the tiny yellow triangle also shown for mixed content).
2) Under Linux activating the box only enables OCSP but not CRL.
Project Member

Comment 23 by, May 8 2014

The following revision refers to this bug:

commit 12884f6987a0d766f8bea1018980f434a89c12e1
Author: <>
Date: Thu May 08 00:58:29 2014 +0000

Remove the confusing certificate revocation checkbox.

BUG= 361820 

Review URL:

git-svn-id: svn:// 0039d316-1c4b-4281-b951-d872f2087c98

Comment 24 by, May 8 2014

You really want to remove the option?!? And thus have no certificate revocation check for any site not covered by the crlset (most after heartbleed)? The correct solution should be to keep the option, and make warning for failed ocp/crl check reliable and noticable. And document it correct (e.g. that no crl check happens on Linux).
Labels: M-36
Status: Fixed (was: NULL)
Personally, I am for a hard fail OCSP option in HSTS or certificate plus OCSP stapling. Default to soft fail with a warning message for now. Remember captive portals can use OCSP stapling too.
The OCSP hard fail rational is simply not born out by reality.

OCSP with hard fails works fine in Firefox and there do not seem to be any significant performance or other penalties associated with it.

Some OCSP is better than none; the ability to turn this on if required and requested is important and a fully working OCSP with hard fail would be even better.

I would urge that the Chromium Team not remove or depreciate this option. Indeed I would urge you to implement OCSP hard fail as soon as possible.

CRLsets is a best a very poor and partial solution to revocation and clearly is not scalable to support all revoked certificates. OCSP with soft or hard fail   


Comment 28 by Deleted ...@, May 8 2014

Please don't remove this... this is a very important option.
So now Chrome won't even have the already weak revocation checking? This makes no sense at all. Chrome should be looking to add a hard-fail option not remove revocation checking altogether. 

As has been pointed out above, there are attack scenarios where it is not possible for an attacker to intercept request to OCSP server, in these cases even a soft-fail option would be effective. 

Every other major browser has this feature, it will not go well for Chrome if they remove it. 
Chrome should really implement OCSP hard-fail. I've been using it with Firefox for 10 days, and didn't notice any false positive. If there are problems with some web sites, browsers can implement some form of white-listing (just like with self-signed certificates).

I don't have a clear opinion for the soft-fail option. Very often it is rather useless (e.g. when connecting to an open wifi hotspot, for which one doesn't know anything about the owner). But just improving the description, making clear that it is useless in various cases, would be better than nothing.

About privacy concerns, OCSP stapling would solve that (web sites that care about privacy enable it). But even if conventional OCSP is used, remember that most people also provide much more private information to Google, Facebook, and so on, so that favoring security should be better.
No browser that I know of has OCSP hard-fail by default, for good reasons already explained.

The case against OCSP with only soft-fail is definitive, I'm afraid. The presence of the checkbox implied a promise that cannot really be meaningful; additionally, Chrome has a strong bias toward not punting confusing choices to users.

Stapled OCSP with the Must Staple option (hard-fail if a valid OCSP response is not stapled) is a much better solution to the revocation problem. CAs and browsers are working toward that solution. It's probably more useful to work toward Must Staple than to add a new hard-fail user option or enterprise policy setting. (I can't seem to find a more recent document at the moment.)

That said, you can still use enterprise policies; only the checkbox is removed.
Here is the updated Must Staple draft:

Comment 33 by, May 9 2014

It is sadly true that no mainstream browser shows warnings for unreachable OCSP by default. But there is an exception: Aviator (a chromium derived browser) has it on by default. 

What has been explained is why making it truly hard-fail (show a fatal error if OCSP is unavailable) is not a good option. What hasn't been explained is why the Aviator solution of showing a warning (the same as Chrome does for mixed-content) is a bad idea by default. If you believe showing warnings to users which some don't understand, then you should get rid of the mixed-content warning too. And do you truly believe that the mixed-content warning is more important or less often a false positive than the OCSP unreachable one?

And showing a warning for unreachable OCSP is helpful as we hopefully move to must-staple. Any website which staples doesn't have any of the disadvantages of OCSP. And the must-staple flag (which will require most likely several year until it is standardized and supported by all CAs), is less important if the browser warns for unreachable OCSP. Given that the reason for must-staple is that a hacker cannot simply use the same cert without stapling (and thus circumvent the user getting the OCSP response), the user would still get the warning about the unreachable OCSP.
No one is saying that OCSP Hard Fail or Must Staple are not better options.

Many people have been using OCSP Hard Fail in Firefox for a long time with very little ffects so that argument is a straw man I'm afraid.

OCSP soft fail be better than no OCSP checking at all. Not all failure cases will automatically cause a OCSP soft fail.

It is well known that CRLsets are very incomplete as a solution to revocation checking:

There is a lot of commentary on-line already about the decision to remove this option from the UI not the least of which is the CA Security Council:

Leaving users vulnerable to huge numbers of revoked certificates is not a tenable position.

Please reconsider; at the very least leave the UI option in for now and seek other opinions on this matter.

Revoked requests are cached for a time.  So if you visit your bank's website daily  you may with sof-fail get a notification that a certificate has been revoked. For several days thereafter the browser will not accept that cert because it knows it to be invalid. So even if you're redirected to a spoofed site with the invalid cert your browser will reject it. 

Soft-fail is very weak but it is not completely useless. If the checkbox is ambiguous rename it to "attempt to verify certificate validity".  Or better yet, have soft-fail checking on by default, like all other browsers do, and remove the checkbox.  That way the user is not confused and the weak protection soft-fail offers is available. 

I've been browsing with hard-fail on in firefox for a month and I've yet to encounter an error. I see no reason why Chrome cannot add an option to do this in their browser. This can tide us over until the Must-Staple extension is finalized (which may be a long time).If you're in a captive portal you can always temporarily disable.  In any case I don't access my bank's website or PayPal on public wifi. 
Labels: Restrict-AddIssueComment-EditIssue
People can disagree on whether the security benefit of soft-fail OCSP is 0 or marginal-if-the-attacker-is-confused (i.e. marginal and unverifiable), but I hope we can all agree that the privacy implications of non-stapled OCSP are clear and not marginal.

On the topic of proliferating "power user" options in the UI, my colleague pkasting has said:

"""For the people wanting options: there are many problems with adding options, but one of the biggest ones is that they allow us to feel good about bad solutions.

In this world, we now tend to believe that we've solved everyone's problems.  Complaints can be brushed off with a "just go change this option" reply. Those users won't toggle any options — they won't even know that there is an option, or whether they'd be better off with it flipped one way or the other. Remember that only a tiny percentage of users ever open their browser's settings page even once — and most of those never change a single setting."""

Note that you do still have the power user settings: enterprise policy (links in previous comment).
Labels: TE-Verified-37.0.1987.1
Tested the same on Win8 chrome version 37.0.1987.1 (Official Build 269719) canary - Fix works as expected.

The confusing certificate revocation check box is removed under "Manage Certificates" button a s shown in the screenshot.
1.9 KB View Download
Components: -Security>UX
Labels: Team-Security-UX
Security>UX component is deprecated in favor of the Team-Security-UX label

Sign in to add a comment