"Although this is painful for the security community, we can rest assured that infrastructure of the cyber criminals and their secrets have been exposed as well."
http://heartbleed.com/
Sounds like they may have scanned the whole internet themselves.
Google reissued their cert on 12 Mar. I assume that is when they discovered it?
I don't know how often they've reissued their certificate in the past, but the certificate's good for almost exactly 90 days. (89.6, to be exact.) Perhaps it was simply time to make another?
This submission should have a more attention grabbing headline! It's not just another SaaS asking users to change their passwords, this is actual (probable) evidence of the vulnerability being exploited weeks before being published.
Someone must have known about this and kept it secret for quite some time. And proceeded to scan huge parts of the internet.
Not surprising, considering the bug was found and published independently by two entities: Blackhats must also have found this one independently, too.
But now it's all that much harder to dismiss and delay password changes and key revocations.
> This submission should have a more attention grabbing headline!
Funnily enough, it looks like the mods changed the title to something more attention-grabbing. I left it with the original title because of HN's policies on titles, but apparently there is wiggle room.
Impressively, it got to #10 even with a bad title. Apparently people do read TFA!
Weird? Really? You want an article called i.e. "jQuery destroys your website" to get as much relevance as this one? people don't have time to read every single article, they want to skim and focus on the important ones (or at least important for them)
It's insane to expect rules to be set apart from their real-life priority: It would be like asking for the same journalistic standards from a war journalist and from fashion magazines for teenage girls.
It's insane to expect rules to be set apart from their real-life priority
But that is how the rules have been enforced, until recently. Expecting consistent behavior is not insane. Not knowing what the title of your submission will be after you submit it is insane!
Rules exist for the sake of organization (not the other way around), therefore they have exceptions, like when the police kills an armed criminal despite murder being a serious crime.
One interesting thing about Heartbleed that I don't think I've seen discussed enough is just how badly screwed anyone relying on SSL to protect against state-actor level monitoring is.
Assuming that state actors (at least NSA, possibly others) are engaging in bulk traffic collection against websites protected by HTTPS, and assume that the agencies used the heartbleed attack to grab as many private keys as they could.
Prior to Heartbleed you were protected. Now (unless the service used perfect forward) security the agencies can decrypt all your communications done under the old key (which usually means in the past 2 years).
Prior to Heartbleed you were protected. Now (unless the service used perfect forward) security the agencies can decrypt all your communications done under the old key (which usually means in the past 2 years).
If you aren't using perfect forward secrecy, then presumably you don't care about that. If you do care about that, then you must use perfect forward secrecy.
I doubt that PFS will protect against the aforementioned parties, though.
If you aren't using perfect forward secrecy, then presumably you don't care about that. If you do care about that, then you must use perfect forward secrecy.
Unfortunately, I think "you" that is affected by this and the "you" that needs to care enough to deploy PFS are two different people. And I suspect that in 99.999% cases the you that cares doesn't know about PFS or how to check if their service uses it.
I had to Google it, and knowing to look for "ECDHE" or "DHE" in the certificate information isn't something many would know.
I ordered something online yesterday, and checked the cipher settings. Turns out my bank doesn't have PFS, and a well-known French payment provider (Paybox) even uses the insecure RC4 cipher.
If the browsers let users who click on the padlock know that it's insecure, the providers would have an incentive to upgrade.
PFS is nothing new, IPsec introduced it in RFC 2412 (November 1998). Benefits of using PFS have been clear since that. Also SSLv3 supports PFS cipher suites. But just as usual, even if something is available, it doesn't mean it's generally adpoted for extended use.
Wow - this seems really big: It basically means that someone was scanning the Internet for this vulnerability on 23rd March 2014 already. Maybe even before. That's two weeks before the vulnerability was published.
edit: I guess I'll actually have to change all of my passwords.
Just make sure you change them AFTER the services are fixed, or you'll simply be delivering your new ones into the hands of ten thousand scriptkiddies instead of a few uberhaxors.
This sort of active exploitation, showing up in different teams' logs/honeypots, might help explain the nearly-simultaneous discovery by different researchers (Mehta at Google and others at Codenomicon) just recently.
Yes – https://news.ycombinator.com/item?id=7558015 – but not sure that wholly rules out the chance the audit of that code started because of other anomalies, which focused suspicion.
Would love more detail from each of the researchers, in their own words, even if the full story is still just a mundane variant of, "we're always reading code, we just happened to be reading this code this week, it looked buggy, we confirmed danger and reported to OpenSSL".
This is at least somewhat reassuring to me--it means that we do have enough expertise out there being vigilant against their server logs such that attacks with serious implications can be identified in a matter of days/weeks. If people start finding evidence of exploitation in logs dating back a year, then I would really worry.
This is not really the topic of the blog post, but two statements confuse me:
>SeaCat client for iOS and Java/Android is not affected since it is using other SSL implementation than OpenSSL (platform specific one)
Does this mean specific to SeaCat or to Android? If it's the latter: Android is using OpenSSL internally as its Java SSL provider, and Android 4.1.1 is vulnerable to Heartbleed.
>and it is running in a client mode.
Doesn't Heartbleed affect OpenSSL in client mode as well?
So, if it wasn't the researchers who found the bug scanning for it, and this started after they found the bug, they'll now know they are compromised by other means by someone with the know-how to make use of this... Possibly by a bad apple, possibly technically. Scary.
http://blog.erratasec.com/2014/04/no-we-werent-scanning-for-...