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 18 users
Status: WontFix
Owner:
Closed: Feb 2015
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment
Missing warning on revoked certificate
Reported by mic...@bentkowski.info, Apr 11 2014 Back to list
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.116 Safari/537.36

Steps to reproduce the problem:
1. Go to https://revoked.grc.com/ whose SSL certificate is purposely revoked.

What is the expected behavior?
Chrome should warn the certificate is revoked.

What went wrong?
The site opened without any warning.

Did this work before? N/A 

Chrome version: 34.0.1847.116  Channel: stable
OS Version: OS X 10.9.2
Flash Version: Shockwave Flash 13.0 r0

Attached two screenshots, one of them shows that everything looks fine to Chrome, the other one shows OS certificate information with a label "Certificate has been revoked" ("certyfikat został unieważniony" in Polish).
 
Zrzut ekranu 2014-04-11 o 21.23.15.png
64.4 KB View Download
Zrzut ekranu 2014-04-11 o 21.23.24.png
60.1 KB View Download
Comment 1 by meh...@chromium.org, Apr 12 2014
Labels: Cr-Security
Labels: Needs-Feedback
Unable to reproduce the issue on 34.0.1847.116, please review attached screenshot. Can you try on other machine and see if this issue is still reproducible. 
Screen Shot 2014-04-14 at 13.43.16.png
282 KB View Download
Comment 3 by gbelvin@google.com, Apr 14 2014
Reproduced bug on both this and another website with a revoked certificate.
Comment 4 by gbelvin@google.com, Apr 14 2014
Screen Shot 2014-04-14 at 12.55.39 PM.png
87.6 KB View Download
Comment 5 by f...@chromium.org, Apr 14 2014
Labels: Cr-Internals-Network-SSL
Comment 6 by f...@chromium.org, Apr 14 2014
Owner: agl@chromium.org
agl@, have you seen this? It seems some clients aren't doing revocation checking but others are.
Comment 7 by agl@chromium.org, Apr 14 2014
This isn't quite a duplicate of 361820 but the discussion there is relevant.

CRLSets push 1576 (I think) contains the revocation for revoked.grc.com. (See chrome://components.)
On OS X, the OS settings (sometimes - exact conditions are complicated) will override the API settings, thus forcing a (blocking) revocation check. However, all of the explanations on https://www.imperialviolet.org/2011/03/18/revocation.html and https://www.imperialviolet.org/2012/02/05/crlsets.html (regarding revocation in the presence of an attacker) apply.
Comment 9 by f...@chromium.org, Apr 14 2014
Cc: gbelvin@google.com f...@chromium.org
Re #8: I don't understand. If it was in the CRLSets push, shouldn't it be showing as blocked regardless?
Comment 10 by agl@chromium.org, Apr 14 2014
felt: revoked.grc.com was in the CRLSets push for the first time last night. Some clients might not have >= 1576 yet.
felt: Not every revoked certificate is included in a CRLSet (see http://dev.chromium.org/Home/chromium-security/crlsets )

On all platforms that perform revocation checks as a system-level component (eg: on Windows and OS X), we always pass flags to allow cached revocation checks. That is, if another application has caused a revoked certificate to be known, we (Chrome) will treat it as revoked. Additionally, we pass flags to disable online revocation checks. However, in certain circumstances, the OS will ignore those flags and force an online revocation check. In those cases as well, the revocation will be picked up.

Absent both of those cached settings, however, we utilize CRLSets, the contents of which are described at a previous link and, by design, do not contain *every* revoked certificate.
Comment 12 by gbelvin@google.com, Apr 14 2014
How does the browser report what CRL set it has?
Comment 13 by gbelvin@google.com, Apr 14 2014
My client is reporting CRLSet - Version: 1577

Comment 14 by f...@chromium.org, Apr 14 2014
But this one *was* included in a CRLSets push (see #7). Gary has 1577 so I don't see why he isn't seeing a block for revoked.grc.com.
Comment 15 by agl@chromium.org, Apr 14 2014
gbelvin: restart Chrome to make sure that your verification cache is flushed and try revoked.grc.com again.
Comment 17 by f...@chromium.org, Apr 14 2014
OK, a restart seems to have fixed it for him. I assume the cloudflarechallenge one isn't on the CRLSet list.
Comment 18 by agl@chromium.org, Apr 14 2014
https://www.cloudflarechallenge.com/heartbleed is revoked for me.
Comment 19 by gbelvin@google.com, Apr 14 2014
And now https://www.cloudflarechallenge.com<https://www.cloudflarechallenge.com/heartbleed>
is
blocked for me as well. Are CRLset checks cached between browser restarts?
Status: Untriaged
Moving the status to "Untriaged" as per comment # 3&4.
Just for the record, my CRLSet is now version 1578 and both revoked.grc.com and cloudflarechallenge.com are blocked now.
Issue 363327 has been merged into this issue.
Comment 23 by dxie@chromium.org, Apr 17 2014
Labels: M-36
Status: Assigned
I reproduced this with my own server (Apache 2.4/OpenSSL/Ubuntu) and Chrome 34.0.1847.116/Mac.
Comment 25 by r...@mybasis.com, Apr 28 2014
I can reproduce this; the most troubling aspect is that Chrome *simultaneously* displays a green lock, but if you click through to the certificate information, it will tell you that the certificate has been revoked.

A revoked cert should *never* display a green lock. Displaying the site automatically is risky enough.

(Compare to Firefox, which refuses to display the site at all, and refuses to allow it to be overridden.)
chrome-revoke.png
33.8 KB View Download
Comment 26 by felt@google.com, Apr 28 2014
roy, I think you've misunderstood. in that screenshot, what's happening is that Chrome does not think the certificate is revoked, but the OS does. that is why the lock does not match the OS dialog.
More specifically, the OS dialog will attempt to (blocking-ly) fetch the revocation status of the resource, even though Chrome has explicitly asked it not to (in order to match the behaviour as observed over the network). This behaviour - which cannot be disabled as of OS X 10.7.2, has itself caused a variety of issues - such as 'freezing' Chrome for between 15 - 60 seconds while the OS does its fetch, highlighting exactly why such revocation checking behaviour is not ideal nor desirable for the web.
Labels: -M-36 M-37 MovedFrom-36
Moving all non essential bugs to the next Milestone.
Labels: -M-37 MovedFrom-37
This issue has already been moved once and is lower than Priority 1,therefore removing mstone.
CRLSet - Version: 1797
https://revoked.grc.com/ - no warning
https://www.cloudflarechallenge.com/heartbleed - Warning (expired 40 days ago)
chromium Version 38.0.2114.2 (287444) (64-bit)

42.0.2288.6 (Official Build) dev-m (32-bit)

So is this all intentional to make people switch to other browsers or some kind of joke? https://revoked.grc.com was revoked 9 months ago.
Both Internet Explorer and Mozilla Firefox don't allow me to see this:

--------------------------------------------------
Here's what we know:
Google's Chrome browser is the least certificate-secure browser on the Internet. It puts speed before security, so it is the only browser on the Internet to disable certificate checking by default.
--------------------------------------------------
revoked-chrome-002.png
137 KB View Download
revoked-chrome-001.png
171 KB View Download
So this has been silently fixed. How can CRLSet be reliable when it fails with 9-month-old revokations?
revoked-chrome-003.png
75.7 KB View Download
Comment 33 by Deleted ...@, Feb 5 2015
Same issue for me with chromium 40.0.2214.94 (archlinux)

chrome.png
131 KB View Download
Comment 34 by agl@chromium.org, Feb 5 2015
Status: WontFix
This is an FAQ: http://www.chromium.org/Home/chromium-security/security-faq#TOC-What-s-the-story-with-certificate-revocation-

I just failed to close the bug previously.
Sign in to add a comment