

Does your browser rejected revoked certificates? - yaur
https://revoked.grc.com
In my testing, the latest (Desktop) Chrome, Opera, and IE do but on Android neither &quot;Browser&quot; or Chrome do.  The upshot being that even with Heart Bleed patched and everyone revoking their potentially exposed certificates there is still a problem.
======
pstrateman
Certificate revocation does not work.

There are two methods of revoking a certificate, Certificate Revocation Lists
and OCSP (Online Certificate Status Protocol).

CRL lists do not scale at all and are almost universally do not include all
revoked certificates (startssl implements this correctly which is why they
charge $25 to revoke a certificate).

OCSP is susceptible to a MitM attack (exactly the scenario in which you want
it to work!).

An attacker can simply block OCSP requests and nearly all current browsers
will silently ignore the failure.

They ignore such a failure because they are actually very common. The CA has
to run an OCSP server that is queried continuously at high volume for no
additional revenue, a model that doesn't exactly encourage robust operation.

The only way to effectively revoke certificates in the numbers necessary after
heartbleed is for the CAs to revoke their intermediary certs and have
everybody get a new cert free of charge.

Edit: for example here is the digicert CRL
[http://crl4.digicert.com/DigiCertHighAssuranceEVRootCA.crl](http://crl4.digicert.com/DigiCertHighAssuranceEVRootCA.crl)

~~~
gojomo
I see these mechanisms are broken — but why?

Broadcasting a signed blacklist shouldn't be that hard, given both a wide
variety of sites that all want the latest version to be available, and the
example of peer-to-peer networks. Also, 'Google Safe Browsing' reliably, and
in a semi-privacy-protecting manner, informs multiple browsers of a blacklist
of scam/malware sites.

I can see the problem has some tricky parts to it... but it doesn't seem any
parts are thorny, intractable problems.

Have CAs prepare a digest (maybe bloom filter?) of revocations regularly. Sign
the hash of this digest, and make the digest available via many redundant
paths (mirrors, CDNs, P2P networks). Interested servers – perhaps every server
reliant on a certain CA – gossip via headers (or even DNS) about the latest
and greatest CRL versions they've seen.

Then browsers can be reasonably sure they've got the latest, or that it's
somehow being kept from them (gossip from third parties says there's a signed
later one, but all usual sources are unreachable) – without an extra, slow,
privacy-compromising poll every new TLS session.

Pirates have no problem flooding the world with fresh media files, against
active legally-privileged interdiction efforts, with each such file much
larger than all revocations ever. Why can't certificate/TLS professionals and
"cyber infrastructure authorities" match that?

~~~
shog
Maybe instead of failing silently, the browser should cease to function at all
if it can't reach its OCSP data source for a public CA, and complain loudly -
providing we can make revocation lookups cheap and highly available.

It could be available via anycast akin to DNS, or p2p as gojomo suggests. Lots
of places use DNS to operate blacklist/RBLs - some with very large datasets
which would break the internet if they ever become unavailable.

~~~
gojomo
Yes, if you're so encircled by bad guys that you can't reach any blacklist
providers, but have received a gossipy hint (via a leak in the blockade) that
there's a new version you don't yet have, blatant alarms should go off.

You're no longer on "the internet", you're on some attacker-chosen & time-
lagged subset... and you need to know that before connecting to sensitive
sites.

------
enneff
Steve Gibson at it again.

Lots of exclamation points, all caps, and colored text, but not a lot of
substance.

Chrome disabled cert revocation checks because they are easily bypassed: a
MITM attacker can just block access to the CA's servers and the revocation
check fails open. They instead opted for a more reliable method of pushing
high profile revocations to the browser with software updates. These decisions
are documented here:

[https://www.imperialviolet.org/2012/02/05/crlsets.html](https://www.imperialviolet.org/2012/02/05/crlsets.html)

Notice how GRC doesn't give any actual details about how revocation checks are
performed and the various advantages and disadvantages of doing them. In
typical Gibson style, he is hyperbolic and cites no prior discussion. But of
course these tactics do what they are designed to do: generate hysteria to get
maximum page views.

~~~
borplk
Bullshit.

Firstly the cert revocation check does work.

You are assuming an arbitrarily advanced adversary who is assumed to pull both
an MITM and also attempt to block access to the CA's servers. When in reality
that may very well not be the case. Just because someone is doing an MITM does
not mean that they will also block access to the CA's servers.

Secondly the MITM can happen at different levels. If the server that is
sending you the response is being MITM'd but you are not, then you can safely
access CA's servers and check for revocation. The MITM does not necessarily
affect the client in a manner as to guarantee the failure to access the CA's
servers.

And finally these personal attacks and Steve Gibson bashing really gets old.

Perhaps he made some mistakes or took controversial positions like ... when?
10 years ago? and people wont let it go.

The exclamation points and all caps and colored text and the ugly web pages is
just his utilitarian and old-school style.

I listen to his weekly Security Now podcast and without failure he is well-
prepared, thorough, accurate and correct. Even when he makes a small mistake
next week he comes along, specifies the exact mistake and apologises and
corrects it.

Instead every time he is mentioned someone comes along and says "ew hurr durr
10 years ago he said something about raw sockets in XP".

My point is, no one is perfect, and he certainly has not done anything to
deserve these personal bashings and attacks from the community, if anything he
is a long-time contributor, has put many tools available online and is now
developing the SQRL login systems in the public ... so ... give him a break.

~~~
enneff
By far the most common MITM attack is through untrusted WiFi networks. That's
when SSL is most valuable to the user, and also when it's easiest for an
attacker to block access to CA servers. Other kinds of MITM attacks are so
much less common they're barely worth talking about in this context.

IMO, an adversary that can extract a cert using Heartbleed and set up a MITM
should also be advanced enough to block some IP addresses.

I'm confused by the rest of your comments about Gibson. All I said about him
was that he continues to generate hysteria without providing details or citing
prior discussion. The only things I'm accusing him of are things he is still
doing today.

~~~
shadearg
He has announced that the current state of cert revocation will be covered in
detail on the next upcoming episode of Security Now. The current page is wordy
and lacking, and I will be very surprised if he doesn't update it with real
substantiating information soon.

~~~
enneff
Oh so it's an ad for the podcast? I was wondering about the angle.

------
dredmorbius
"Cannot connect" from Chromium 33.0.1750.152 Debian jessie/sid (256984).

Using w3m I get a page beginning with the following text:

    
    
                                 Security Certificate                               
                               Revocation Awareness Test                            
                   If you can see this (and apparently you can), you                
                      are using a revocation UNaware web browser!                   
                                                                                    
        The SSL/TLS security certificate for this special website has been          
        deliberately revoked.  Since you are seeing this page, we know that         
        this web browser is allowing a site with a known invalid certificate        
        to display its pages. This is likely not the behavior you would choose.
    

...

------
mivok
Explanation of exactly why chrome doesn't have 'Check for server certificate
revocation' checked by default:
[https://www.imperialviolet.org/2012/02/05/crlsets.html](https://www.imperialviolet.org/2012/02/05/crlsets.html)

The short version is that it's slow and not as effective as it might seem.

------
TwoBit
FireFox (desktop and mobile) and Internet Explorer reject it. Chrome and
Dolphin on Android fail to reject it.

~~~
dublinben
Firefox on Android rejects it properly.

------
jasoncrawford
Wow, latest version of Chrome (Mac) apparently is unaware of revoked certs.
Firefox and Safari are aware.

~~~
sirsar
Chrome 33.0.1750.154 Windows rejects it with the "Check for server certificate
revocation" setting enabled.

~~~
federalemployee
Mac version has that setting too.

Here is a write up stating why Chrome doesn't do this by default:

[http://arstechnica.com/business/2012/02/google-strips-
chrome...](http://arstechnica.com/business/2012/02/google-strips-chrome-of-
ssl-revocation-checking/)

------
sirdogealot
Chromium tells me:

Cannot connect to the real revoked.grc.com

Something is currently interfering with your secure connection to
revoked.grc.com.

Try to reload this page in a few minutes or after switching to a new network.
If you have recently connected to a new Wi-Fi network, finish logging in
before reloading.

If you were to visit revoked.grc.com right now, you might share private
information with an attacker. To protect your privacy, Chrome will not load
the page until it can establish a secure connection to the real
revoked.grc.com.

I pressed reload a few times after a few minutes and still see the same page.
Am I doing it right or what?

~~~
yaur
This what you should see in a secure browser. The site was apparently
provisioned with a pre-revoked certificate, so you shouldn't be able to
connect to it. Though some browsers can.

------
SmileyKeith
Works in Chrome 34.0.1847.116 on OS X once "Check for server certificate
revocation" is checked (off by default as others have said).

------
pajtai
Seems like the browser should at least give a warning if it thinks the cert
was revoked. You can see the green padlock AND the revocation in Chrome.

[http://s27.postimg.org/6cub79gbn/Screen_Shot_2014_04_13_at_1...](http://s27.postimg.org/6cub79gbn/Screen_Shot_2014_04_13_at_10_19_21_PM.png)

or through:

openssl s_client -connect revoked.grc.com:443

I mean from an end user perspective - irrespective of google's stance on
revoked certs - it's very unexpected that the browser info about the cert is
that it is revoked but the padlock is green

\---

oh okay, as some of the other comments points out, this puts it into some
perspective:

[https://www.imperialviolet.org/2012/02/05/crlsets.html](https://www.imperialviolet.org/2012/02/05/crlsets.html)

\---

In Safari it won't let me get to the page w/o dire warnings.

------
themartorana
GRC.com has been around for so long and it is just awesome. Don't know if this
is still the case, but Steve Gibson either used to - or still does - write all
of his software in assembly[1]. As a young comp sci college student in 1997, I
can remember how insanely, blazingly fast his software and scanners seemed to
run on my computer compared to all my other programs. He wrote about why he
wrote in assembly and it was a huge inspiration to me as a young programmer.

Yes, this is totally a fanboy post :) But it's cool to see Steve still popping
up in relevant security news almost 20 years later.

[1] [https://www.grc.com/smgassembly.htm](https://www.grc.com/smgassembly.htm)

~~~
mahmud
Oh yes, he has been around for long. But he lost a bit of credibility after
his wolf-cry when he campaigned _against_ the inclusion of raw-sockets in
Windows XP, alleging hackers might use it.

~~~
wnevets
you do realize that he was right and MS removed them right?

~~~
nuxi7
microsoft removed it, but that doesn't mean he was right.

Last I checked, the internet did not end while XP had raw sockets, and windows
server retains this capability.

~~~
wnevets
So why did MS remove them?

~~~
mahmud
Responding to the public hysteria; they couldn't take their chances, they
would have been crucified if even a single incident was reported, because they
had "forewarning".

Steve Gibson did to raw-sockets what Jenny McCarthy did to vaccines.

------
chacham15
The real solution here is OCSP Stapling
([http://en.wikipedia.org/wiki/OCSP_stapling](http://en.wikipedia.org/wiki/OCSP_stapling)).
It allows a server to present (i.e. 'staple') a signature specifying that the
cert is still valid at the SSL handshake. Therefore, a legitimate connection
with the server will also have the staple. The problem is that we need to make
it standard to the point of "if the OCSP stapling is missing, then the cert
should be rejected."

------
ama729
Interestingly, both Lynx and Wget don't throw any warning at all.

It's really surprising for Lynx, you would think THE nerd browser would be a
bit better security wise.

~~~
e12e
I can't seem to find any command line tool (including openssl s_client) that
will automatically "do the right thing". Curl, wget, w3m and lynx and "openssl
s_client -connect revoked.grc.com:433" all happily connect without warning.

So much for downloading install scripts over ssl...

~~~
e12e
I guess that's one more reason to install an ssl unwrapping proxy -- allows
you to log what comes sailing in over ssl (if you should be so inclined) --
and at least the proxy could make sure to drop connections to sites with
revoked certs.

It would make it more difficult to connect to sites that use alternative
CAs/self-signed certs, though..

~~~
e12e
Ok, so gnutls-cli from libgnutls 3.2 has a --ocsp parameter, that turns on
ocsp. And it sort of "works":

    
    
        $ gnutls-cli -p 443 --ocsp revoked.grc.com
        (..)
        Resolving 'revoked.grc.com'...
        Connecting to '4.79.142.205:443'...
        - Certificate type: X.509
        - Got a certificate list of 2 certificates.
        - Certificate[0] info:
        (...)
        - Status: The certificate is trusted.
        Connecting to OCSP server: ocsp.digicert.com...
        Resolving 'ocsp.digicert.com'...
        Connecting to '93.184.220.29:80'...
        *** Verifying OCSP Response: Failure, Signature failure.
        *** OCSP response ignored
                          ^^^^^^^ ! WTF?
    

So, by working, I mean that it doesn't work.

------
wanderr
Chrome 36.0.1933.0 dev-m correctly complains even though I do _not_ have
"Check for server certificate revocation" enabled.

------
exiva
Opera 20.0.1387.91 on OS X displays "The server's security certificate is
revoked!" and won't let you through it seems. IE 10 on WP8.0 says "the
certificate wasn't issued by a trusted certificate authority" but gives you
the option to throw caution to the wind.

------
__david__
Safari on iOS loaded the site with no warnings. Ouch—that's a lot of people.

------
keehun
Firefox that I'm running seems to block the website.

------
maccard
Safari 7.0.2 warned me, but let me proceed. Nightly 31.01a flat out blocks it.
Don't have any other browsers to hand.

------
leni536
Is it a problem that curl and wget do not reject it?

------
computer
The site doesn't load here, what does it say?

~~~
MatmaRex
I think that's the point. My browser (Opera 12) says "Unable to complete
secure transaction" and "The certificate has been revoked by its issuer. It is
no longer valid. In the worst case it may be used by criminals for fraudulent
purposes. The website owner must immediately replace the certificate.".

------
rasz_pl
Secure connection: fatal error (44)

Opera 12.16 Build 1860

------
nomailing
the revocation check cannot easily get bypassed. if you block the Ca, then the
check should definitely fail. this is not the same as saying it is bypassed.

~~~
enneff
So you're not even vaguely concerned about the privacy implications of telling
the CA about every HTTPS connection you make?

You don't care that if the CA goes down then the entire encrypted web stops
working?

Think.

