Does your browser rejected revoked certificates?

https://revoked.grc.com

by yaur • 12 years ago

68 71 12 years ago

revoked.grc.com

In my testing, the latest (Desktop) Chrome, Opera, and IE do but on Android neither "Browser" or Chrome do. The upshot being that even with Heart Bleed patched and everyone revoking their potentially exposed certificates there is still a problem.

jasoncrawford2• 12 years ago

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

sirsar• 12 years ago

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

federalemployee• 12 years ago

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

jasoncrawford2• 12 years ago

Yeah, I just found that setting. That works.

dean• 12 years ago

Chrome 34.0.1847.116 m Windows rejects it even with the "Check for server certificate revocation" _disabled_

train_robber• 12 years ago

Version 33.0.1750.152 on Ubuntu rejects with default settings for me.

http://i.imgur.com/aQdu7GO.png

jhurwitz• 12 years ago

It looks like, as of February 2012, Chrome requires an update to receive a new revocation list: https://www.imperialviolet.org/2012/02/05/crlsets.html

tjohns• 12 years ago

Even though this is the default behavior, you can still ask Chrome to check directly for revoked certificates:

Settings > HTTP/SSL > Check for server certificate revocation

mikerg87• 12 years ago

Interesting about safari. Mobile safari on my iPad let me pass right on to the page

computer• 12 years ago

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

MatmaRex• 12 years ago

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

mivok• 12 years ago

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

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

TwoBit• 12 years ago

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

dublinben• 12 years ago

Firefox on Android rejects it properly.

sirdogealot• 12 years ago

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• 12 years ago

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.

iamtew• 12 years ago

Indeed, I'm getting the following in Firefox:

An error occurred during a connection to revoked.grc.com. Peer's Certificate has been revoked. (Error code: sec_error_revoked_certificate)

dredmorbius2• 12 years ago

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

...

themartorana• 12 years ago

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

mahmud2• 12 years ago

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.

wnevets2• 12 years ago

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

shadearg3• 12 years ago

He's definitely adamant about the ongoing exclusion of raw sockets on Windows and alleges malware would absolutely abuse it if it were available. He still talks about it once and a while and certainly does not regret that stance.

enneff5• 12 years ago

http://attrition.org/errata/charlatan/steve_gibson/

MichaelGG• 12 years ago

... Been around as a joke. Like read this one:

https://www.grc.com/ssl/ev.htm

You'd think it's an odd mix of satire and CA salesmanship with a healthy dose of not understanding how anything works, but apparently he's serious.

shadearg3• 12 years ago

Just about everything he writes is MASM. He talked once briefly about a custom packet rewriter that sits on his edge to assure that any packet reaching GRC or his internal network is properly formed. He didn't divulge much else about it.

He did take up Javascript a couple years ago because of a new-found value in client-side processing and canvas[1] for animation.

He's currently working on SpinRite 6.1 with modern I/O support and an authentication mechanism he came up with out of the blue called SQRL[2].

[1] https://www.grc.com/animation.htm [2] https://www.grc.com/sqrl/sqrl.htm

exiva• 12 years ago

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.

pstrateman5• 12 years ago

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

iancarroll• 12 years ago

I remember a month back GoDaddy's OSCP server would always fail to respond to the first query you gave it. I had to disable OSCP checking because of it.

pstrateman5• 12 years ago

I should note that blocking OCSP requests will not cause revoked.grc.com to function.

The server is using OCSP stapling, which means the OCSP certificate is being sent directly by the https server, an attack would obviously not be sending an OCSP response indicating the certificate was revoked....

eurleif• 12 years ago

Why does OCSP stapling even exist?

nullc• 12 years ago

OSCP also leaks which sites you're visiting when to the CA (or anyone on the network path who can intercept the OSCP request). Some people point out that DNS leaks this information too, but DNS has extensive caching which reduces the leak.

jervisfm• 12 years ago

I'm wondering how do you reconcile:

Certificate revocation does not work. [...] OCSP is susceptible to a MitM attack (exactly the scenario in which you want it to work!).

with

The only way to effectively revoke certificates in the numbers necessary after heartbleed is for the CAs to revoke their intermediary certs.

That is, how are the intermediate certificates supposed to be revoked if certificate revocation does not work relibably ?

Also, I'd note that certification revocation can be made to work by the browser simply refusing to continue if it's unable to check certification revocation status (either due to an active MITM or other genuine network errors). Granted this comes at the cost of great user inconvenience, but that's almost always the tradeoff with increased security.

pstrateman5• 12 years ago

That is, how are the intermediate certificates supposed to be revoked if certificate revocation does not work relibably ?

It's a much smaller amount of information, so a normal CRL can be used effectively.

You really cannot use a CRL to revoke millions of certs, but you can use them to revoke a few hundred.

PeterWhittaker2• 12 years ago

CRL lists do not scale at all

Please elaborate. The CDP (CRL Distribution Point) allows for multiple strategies, some of which can scale quite well.

The Canadian government runs several PKIs with tens of thousands of active certs, many thousands of revoked, no problems at all, because of CDPs.

(Full disclosure: I worked for several years for the company that invented the CDP. I was not involved in the invention.)

(BTW, FF 28 detected the revoked cert just fine.)

pstrateman5• 12 years ago

The Canadian government runs several PKIs with tens of thousands of active certs, many thousands of revoked, no problems at all, because of CDPs.

Because thousands is off by several orders of magnitude.

Real public CAs are going to have to contend with revoking millions of certificates.

Each revocation cert is about 1KiB, so that's 1GiB of revocation data per CA.

That obviously does not scale.

gojomo2• 12 years ago

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• 12 years ago

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.

dvdkhlng• 12 years ago

Certificate revocation does not work.

I have to second this. Just days after the Heartbleed disaster struck, my Firefox (v24; Debian "Iceweasel") sometimes takes more than 30 minutes (!) to load SSL-encrypted websites, as it first downloads some 50MB of CRLs from ocsp.comodoca.com (verified what it is doing using tcpdump). Disabling OCSP certificate checks fixes the problem.

I haven't encountered the issue under Ubuntu 12.04, maybe newer Firefoxes have some timeouts built in, or the certificate database works faster on my Ubuntu PC (the Debian system uses NFS which may slow down the sqlite database a lot.)

This is like single point of failure designed into a protocol. Unbelievable.

vertex-four• 12 years ago

Could you build a certificate revocation system on a blockchain? At least it should be obvious if someone is MITMing you (you don't get new blocks for ages), and other than that, you have a permanent record of all revoked certificates. The people who keep the chain running also get compensated.

Doesn't necessarily help mobile, due to the blockchain's size... but perhaps there's workarounds for that.

SmileyKeith• 12 years ago

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

ama729• 12 years ago

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.

e12e3• 12 years ago

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

dredmorbius2• 12 years ago

No, man, you've got to curl straight to bash. As root.

God I fucking hate that.

e12e3• 12 years ago

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

__david__2• 12 years ago

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

wanderr• 12 years ago

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

enneff5• 12 years ago

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

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.

unlimitedbacon• 12 years ago

I listen to his Security Now podcast on a regular basis and have always found it be be extremely thorough and informative. However, I have to agree with you that his website and writing style look like something you'd expect from someone who wears a tin foil hat. I also understand that he doesn't have much credibility in the wider security community.

So I guess my question is, what do you guys think of the show and are there any alternatives you would recommend?

danra• 12 years ago

Post heartbleed, the right way to go is for all browsers to deny https access in case the OCSP check fails, not just ignore the failure. The CAs are those who should scramble to fix whatever doesn't work. Captive networks have to be configured to allow CA access, or just disallow https.

nomailing2• 12 years ago

exactly. if access to a CA is blocked it is not good and I want a big red warning sign in my browser. what chrome is doing with their high profile website revocation by browser update is all bullshit.

borplk• 12 years ago

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.

enneff5• 12 years ago

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.

Perseids• 12 years ago

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.
Perhaps he made some mistakes or took controversial positions like ... when? 10 years ago? and people wont let it go.

According to archive.org [1] the password haystack page [2] is from June 2011. He hasn't changed his "controversial" opinion on that matter yet.

[1] http://web.archive.org/web/*/https://www.grc.com/haystack.ht...

[2] https://www.grc.com/haystack.htm

keehun• 12 years ago

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

maccard• 12 years ago

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.

pajtai• 12 years ago

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

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

---

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

nomailing2• 12 years ago

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.

enneff5• 12 years ago

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.

leni536• 12 years ago

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

chacham15• 12 years ago

The real solution here is 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."

rasz_pl• 12 years ago

Secure connection: fatal error (44)

Opera 12.16 Build 1860

Does your browser rejected revoked certificates?

Related Stories