The bug was introduced in version 1.0.1, released 14 Mar 2012. Aren't most of Snowden's documents older than that? And we certainly don't know what the NSA has been doing since Snowden collected his files late 2012 / beginning 2013.
In case the bug was really actively exploited on Heroku, updating private keys and changing Heroku password can be not enough. SSL endpoints forward all HTTPS traffic, so according to my understanding cookies, application specific passwords, basic auth credentials could have been potentially compromised.
Another potential vector are add-ons that use encrypted connections (for example Heroku Postgres). These also could have been targeted, in which case add-ons credentials would need to be regenerated.
That is my understanding as well. Any memory in the same process as OpenSSL could be compromised. In the case of Heroku that includes any traffic to/from your app, but not dynos' memory, so internal application credentials should be ok, unless those services were also vulnerable. Hopefully Heroku is coordinating with add-ons to determine that and automatically regenerate affected credentials.
Loading an https://APPNAME.herokuapp.com page, I'm seeing a certificate (sn:"0E:3E:94:7F:C0:64:D7:4A:52:B1:38:D7:71:90:88:1F") with an "Issued Date" of "1/20/14"... which doesn't sound like it's been regenerated in the last 24 hours.
Am I interpreting the certificate info wrong? [edit per official answer below: YES] (Are fresh certificates sometimes given much older start times? [edit: YES])
This blogpost doesn't clearly address *.herokuapp.com HTTPS service, as opposed to the custom-domains "ssl:endpoint" service.
Hi, Heroku engineer here. We rekeyed our certificates, including the one for *.herokuapp.com, meaning we resent our original certificate requests (CSR) to our CA but signed with new private keys. This is why the dates didn't change.
Our CA will eventually revoke the previous incarnations of our certificates, signed with the old private keys, making them invalid.
Am I missing something, or doesn't the browser have to explicitly check for key revocation? I know the checkbox was off in my version of Chrome. Maybe I set it, but I'm not sure.
This [1] Seems to suggest that Firefox, for instance, only checks for EV certs?
Thanks! It might be reassuring to others who see the same mixed-signals if the official blogpost made specific mention of APPNAME.herokuapp.com HTTPS, and that the certificates may look older but really are fresh.
This is completely the wrong approach. Your private key might have been compromised and you're generating another certificate for the same compromised private key? What is that supposed to do?
We generated new CSRs, with new private keys, but with the same dates and details as the originals. This let us get fresh certs without going through a full renewal.
Yep, I was just hassling our billing SaaS provider about this, but then I looked into their SSL vendor heartbleed post, and their customers mention this in the comments:
Excerpt: "Also, Busy IT Guy is right; it's a little disheartening to be listed as Unsafe after having done all the right things, just because the issue date didn’t get updated."
I'm pretty sure if you're using herokuapp.com then you're not using your own cert and Heroku will update it for you. If you're using ssl:endpoint then you will have had to submit your own cert, and that will need replacing.
However, this blogpost says, "As of Tuesday, April 8 at 15:55 UTC, all Heroku certificates and infrastructure have been updated and are no longer vulnerable"... while the certificate still superficially looks like it's almost 3 months old. Something isn't as it seems, I hope it's just the certificate age.
"This vulnerability can be remotely exploited to leak encryption secrets from Heroku applications, allowing an attacker to retrieve the private key used for SSL encryption and decode data obtained by intercepting traffic"
Does anyone know if this is "actually" true?. By looking at the bug it seems you can dump up to 64 bytes at a time from the stack. Given that the attacker doesn't control were from the stack at all and looking at the code the top of the stack is probably holding some random structure, is it really possible for the attacker to retrieve the private key?
I just want to be sure before spending a bunch of money to replace re-issue all certs.
It has been repedately demonstrated that it is possible to get private key from the server using this vulnerability, as well as user login details. You don't have only one shot - you can query the server multiple times (and every time you will receive slightly different data) until you have everything you want. So yeah, the issue was/is very serious.
See this post for a trivial example of session theft from JIRA [1]. You may not get the memory chunk you want the first time, but you can repeat it until you do.
It's from somewhere on the heap not the stack. You can influence where on the heap the data comes from by adjusting the size of your request, amongst other tricks.
If they had, there wouldn't be any talk of HTTPS being a barrier in their leaked presentations.
That said, all of that encrypted traffic they've got stored up can now, thanks to this bug, be decrypted.