Heartbleed is about to get worse, and it will slow the Internet to a crawl

http://www.washingtonpost.com/blogs/the-switch/wp/2014/04/14/heartbleed-is-about-to-get-worse-and-it-will-slow-the-internet-to-a-crawl/?clsrd

by aburan28 • 12 years ago

26 34 12 years ago

washingtonpost.com

falcolas3• 12 years ago

Nothing really new here - just the acknowledgement that the ability to steal private ssl keys requires a massive effort to replace those keys.

"If anything is compromised, assume everything is compromised."

Our keys have been updated (and the old certs revoked), our servers patched, our sessions expired, and passwords expired. Mitigation more or less complete. Helps we're running a very small site, for sure, but the steps were clear from the beginning.

gvb2• 12 years ago

But have you revoked your old primary keys? Everybody that was vulnerable to Heartbleed should revoke their old primary keys so that web browsers no longer trust those potentially stolen keys. If they are not revoked and a Bad Guy stole your primary key(s), they can create a fake web site that identifies itself as your web site and all web browsers would trust it as legitimate, complete with the little green "you can trust me" padlock.

The CloudFlare challenge proved that the primary keys could be stolen.

There were millions of vulnerable sites (the internet is approaching a billion total web sites, and a significant number of them were vulnerable). The revocation list method used by browsers does not scale well with those kinds of numbers.

[1] http://news.netcraft.com/archives/category/web-server-survey...

schrodinger2• 12 years ago

Doesn't rekeying result in the old certificate based on the compromised private key being revoked?

falcolas3• 12 years ago

Yup, as part of the cert re-issue, we revoked the previous cert. Could have been more explicit there, sorry.

001sky• 12 years ago

According to Paul Mutton, a security consultant at the Web services company Netcraft. Checking a site’s identity will take vastly longer.

“If a certificate authority has to revoke 10,000 certificates, that entry will have 10,000 certificates on it,” Mutton said. “And if browsers have to download that . . . we’re talking hundreds of megabytes.”

It’s roughly the equivalent of having to download 30 minutes’ worth of standard-definition video just to view a single Web page.

is this accurate?

nitrogen• 12 years ago

Would it be possible to use a probabilistic data structure (e.g. Bloom filter) to create a privacy-enabled CRL as a service?

daeken• 12 years ago

I don't see why not, especially because you already have the old key signature/fingerprint to use when pushing it into the Bloom filter. Seems like a perfect case for it, actually.

gvb2• 12 years ago

You could distrust any certificate that was signed before April 7 (or some slightly later date). It might be easier to do that and whitelist the good "pre-apocalypse" certificates. The nice thing about doing this is that your whitelist will inherently go to zero as certificates time out and get renewed (typically 1-3 years?).

The hard thing would be to generate an accurate whitelist.

ams6110• 12 years ago

I don't know much about how CRLs work, or what the "authoritative" clearinghouse for the CRL list is (if any) but ideally your browser only needs to download the bulk list once, then based on checksums or timestamps should just download diffs since the last version it had.

Basically we need a git repo for CLRs.

PeterWhittaker• 12 years ago

It's not accurate: They are making the same mistake as in other recent HN articles, that the entire certificate (1k-2k) is listed on the CRL.

It's not. It's serial number, a timestamp, maybe one or two other things. 10,000 certs is maybe 40,000 bytes on a RL.

kijin2• 12 years ago

No, you won't have to re-download the revocation list every time you open a web page. That would be ridiculous.

But if you want to be really secure, you might want to check the revocation list every time you see a new certificate.

matt__rose• 12 years ago

This sentence: "No examples have surfaced of anyone actually exploiting the vulnerability" is incorrect. The Canada Revenue Agency revealed that 900 SINs (canadian equivalent of SSNs, but nowhere near as totemically identifying) were stolen due to the heartbleed bug. http://www.theglobeandmail.com/technology/mounties-chasing-v...

justinhj2• 12 years ago

In order to know this they must have stored and subsequently analysed the ssl traffic. Something that I would think is quite unusual. So the true scope of data theft is probably much larger.

simcop2387• 12 years ago

They might have turned on that logging when the bug was announced so that they'd have an idea of the threat they were under while updating.

thisisdave• 12 years ago

I thought that sentence was referring specifically to vulnerable certificates.

sitkack• 12 years ago

Lets just call a do-over, EVERYONE generate new private keys and request new certs. Any cert created before April 10 2014 will be considered suspect.

Create a bloom filter for revoked certs. Have a remote cert revocation server/cache so I don't need to have a 50MB file of revocations.

the_ancient• 12 years ago

while the problem is wide spread, it is no where near enough to say "all certs after 4/10 are suspect"

There are an ever larger number of certs not impacted by this event.

jerf2• 12 years ago

False positives are a problem for a Bloom filter. You could conceivably create one for a given registrar, though, which could in theory create a Bloom filter, iterate through all the certs it has issued, and then list out the certs that the Bloom filter issues false positives for, but are still valid. However, it's too late to put that into play. Nobody ever expected to have to revoke this quantity of certs. (In hindsight, that was obviously wrong. Something like this was going to happen someday. But this is exactly the sort of thing that's very easy to argue away, because nobody wants to be convinced that this amount of work will be necessary.)

justinhj2• 12 years ago

Question: with a stolen private key don't you still have the problem that is has the host name in it? So to truly spoof a browser you need to compromise the domain and serve a site from within it?

mpyne3• 12 years ago

It depends on what you're going after, but if you're just targeting a local subnet, that's what a "man-in-the-middle" attack is for.

What is probably easier is somehow redirecting the DNS entry for the target site to point to your malware-serving site, which has happened before as well.

kijin2• 12 years ago

The situation would be much more manageable if browser vendors provided an online service that quickly allows individual certificates to be checked against the latest revocation list from all trusted CAs. There should be no need for each user to download the full revocation list, since most people will never visit 99.9% of the websites in that list.

Until now, revocation lists were small enough that this was not a problem. But it's probably time to fix that.

There are already third-party add-ons like Perspectives that check the certificates you see against those seen by other people. Chrome already knows which Google certs are valid or not. There's no reason why Mozilla, for example, shouldn't make something like this an official security feature of Firefox, too.

astrange• 12 years ago

This is OCSP. Chrome removed their support for it, but I think Firefox might check it.

mballantyne• 12 years ago

Do CRLs even work? My understanding is that the only browser that hard-fails to load a page if OCSP is blocked is Chrome for certs in CRLSets. Everyone else is vulnerable to MITM if access to the CRL / OCSP servers is blocked.

I would love to be wrong. Does anyone know if anything has changed for the better since 2011?

http://blog.spiderlabs.com/2011/04/certificate-revocation-be... http://dev.chromium.org/Home/chromium-security/crlsets https://www.imperialviolet.org/2011/03/18/revocation.html

Heartbleed is about to get worse, and it will slow the Internet to a crawl

Related Stories