
OpenSSL Heartbleed Security Update - robin_reala
https://blog.heroku.com/archives/2014/4/8/openssl_heartbleed_security_update
======
diminoten
The one thing that might be of some small comfort to others is the fact that
at least the NSA didn't know about this bug.

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.

~~~
maxerickson
I would think that when they discover a superpower they compartmentalize that
information.

You could make the inference that, if they did have it, they were not making
broad use of it.

~~~
mpyne
They _did_ compartmentalize. They still do.

That's why having an insider with sysadmin access and prestige for social
engineering purposes is so dangerous.

~~~
maxerickson
Yeah. We should still take Rumsfeld's advice about what we don't know.

~~~
mpyne
Sure, the advice is still as sound as it ever was.

So was the advice about going to war with the Army you had, not the one you'd
wished you had.

------
higherpurpose
Everyone should be adopting perfect forward secrecy in their TLS connections.
No excuses at this point.

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

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

------
gojomo
Loading an [https://APPNAME.herokuapp.com](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.

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

~~~
grittygrease
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?

~~~
dpiddy
As discussed on twitter
([https://twitter.com/grittygrease/status/453606054698692608](https://twitter.com/grittygrease/status/453606054698692608)),
I should have said:

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.

Thanks for the prod.

~~~
grittygrease
Thanks for the update. Happy revocation day!

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

~~~
aetherson
64k, not 64.

~~~
danielpal
OK fair, 64K. But is it actually possible to control were you get the 64K from
or is it just off the top of the stack?

And is it actually possible that the top of the stack has your private key?

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

