Hacker News Reader

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?

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.

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

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

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

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.

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.

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

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

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.

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.