Does your browser rejected revoked certificates?(revoked.grc.com)
revoked.grc.com
Does your browser rejected revoked certificates?
https://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.
73 comments
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
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
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?
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.
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.
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.
> 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.
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.
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.)
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.)
> 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.
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.
Each revocation cert is about 1KiB
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.
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.
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.
> 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.
> 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.
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.
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....
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....
Why does OCSP stapling even exist?
Because querying the OCSP servers directly results in a crazy amount of traffic.
Implemented in the most paranoid manner possible every https request would result in an OCSP request.
That would be millions of requests per second for a large CA.
They have effectively no financial interest in actually supporting that.
Implemented in the most paranoid manner possible every https request would result in an OCSP request.
That would be millions of requests per second for a large CA.
They have effectively no financial interest in actually supporting that.
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.
Doesn't necessarily help mobile, due to the blockchain's size... but perhaps there's workarounds for that.
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.
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.
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.
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.
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.
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.
Oh so it's an ad for the podcast? I was wondering about the angle.
> 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
> 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
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?
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:
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.
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.
The short version is that it's slow and not as effective as it might seem.
Wow, latest version of Chrome (Mac) apparently is unaware of revoked certs. Firefox and Safari are aware.
Chrome 33.0.1750.154 Windows rejects it with the "Check for server certificate revocation" setting enabled.
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...
Here is a write up stating why Chrome doesn't do this by default:
http://arstechnica.com/business/2012/02/google-strips-chrome...
Chrome 34.0.1847.116 m Windows rejects it even with the "Check for server certificate revocation" _disabled_
Version 33.0.1750.152 on Ubuntu rejects with default settings for me.
http://i.imgur.com/aQdu7GO.png
http://i.imgur.com/aQdu7GO.png
Yeah, I just found that setting. That works.
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
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
Settings > HTTP/SSL > Check for server certificate revocation
Interesting about safari. Mobile safari on my iPad let me pass right on to the page
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?
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?
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.
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)
An error occurred during a connection to revoked.grc.com. Peer's Certificate has been revoked. (Error code: sec_error_revoked_certificate)
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).
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.
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.
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
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
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.
you do realize that he was right and MS removed them right?
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.
Last I checked, the internet did not end while XP had raw sockets, and windows server retains this capability.
... 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.
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.
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
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
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."
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.
It's really surprising for Lynx, you would think THE nerd browser would be a bit better security wise.
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...
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..
It would make it more difficult to connect to sites that use alternative CAs/self-signed certs, though..
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?
No, man, you've got to curl straight to bash. As root.
God I fucking hate that.
God I fucking hate that.
Chrome 36.0.1933.0 dev-m correctly complains even though I do not have "Check for server certificate revocation" enabled.
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.
Safari on iOS loaded the site with no warnings. Ouch—that's a lot of people.
Firefox that I'm running seems to block the website.
[deleted]
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.
Is it a problem that curl and wget do not reject it?
The site doesn't load here, what does it say?
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.".
Secure connection: fatal error (44)
Opera 12.16 Build 1860
Opera 12.16 Build 1860
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.
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.
You don't care that if the CA goes down then the entire encrypted web stops working?
Think.