
Heartbleed is about to get worse, and it will slow the Internet to a crawl - aburan28
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
======
falcolas
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.

~~~
gvb
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...](http://news.netcraft.com/archives/category/web-server-survey/)

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

~~~
mpyne
No, presenting a certificate that has been rekeyed does not mean that the old
certificate stopped being cryptographically valid.

In fact the old cert will always be cryptographically valid, which is why a
separate revocation list has to be created as a positive acknowledgement that
the old cert, though valid, should not be trusted.

~~~
lmz
Do the browsers actually use revocation checking?

~~~
falcolas
Firefox does. Found that out in my development box which I hadn't updated with
the new certs, the old certs showed up as revoked and Firefox wouldn't let me
proceed.

------
mballantyne
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://blog.spiderlabs.com/2011/04/certificate-revocation-behavior-in-
modern-browsers.html) [http://dev.chromium.org/Home/chromium-
security/crlsets](http://dev.chromium.org/Home/chromium-security/crlsets)
[https://www.imperialviolet.org/2011/03/18/revocation.html](https://www.imperialviolet.org/2011/03/18/revocation.html)

------
matt__rose
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...](http://www.theglobeandmail.com/technology/mounties-chasing-
viable-lead-in-cras-heartbleed-breach/article18002731/)

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

------
001sky
_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
Would it be possible to use a probabilistic data structure (e.g. Bloom filter)
to create a privacy-enabled CRL as a service?

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

~~~
mygrant
We had certs that were only used and present on machines that were not
vulnerable, and therefore did not replace or revoke them. Please don't do
this.

~~~
nathanvanfleet
Furthermore servers that weren't even using OpenSSL or the particular
version(s) that were susceptible. What is the actual percentage of servers
that needed to react to this?

------
kijin
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
This is OCSP. Chrome removed their support for it, but I think Firefox might
check it.

------
sitkack
1)

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.

2)

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.

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

------
justinhj
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?

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

