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.
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?
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.
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.
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.
How do you figure? Each revocation is by certificate serial number, which typically run 4 to 20 bytes, and the revocation date, with possible extensions for more information.
Add a little overhead for the signature on the list, etc.
Exaggerate wildly and call that 100 bytes per revocation: we're down to at most 100MB of revocation data for the million user case; that's not a lot of data.
It's probably closer to 20 or so bytes per revocation, ~20MB of revocation data. Spread out over as many CDPs as the CA wants to maintain.
The system used in the Canadian federal government creates one CDP per 375 users, so that CDPs are capped at roughly 750 certs each (each user has two key pairs, one for verification, one for encryption). At 20-100 bytes per revocation, that's 15KB to 75KB per CDP.
That's not much at all. And given that any given user interacts with a subset of all possible users, they won't have anywhere near all of the CRLs downloaded.
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.
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.
> 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.
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....
More importantly, it removes the privacy leak from client to CA, since the client is no longer speaking to the CA directly (it just has to look at the signature).
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.
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:
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.
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.
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.
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.
> 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.
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.
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.
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?
"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.
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?
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.
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:
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.
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.
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.
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.
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].
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."
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...
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..
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.
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.".
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.
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