Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OpenSSL Heartbleed Security Update

blog.heroku.com

Post reply on HN
Print view View original

11–20 of 33 posts

Re: OpenSSL Heartbleed Security Update

#11

Post by dpiddy »

gojomo wrote: post #2

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 cl…

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.

Re: OpenSSL Heartbleed Security Update

#13

Post by erichurkman »

danielpal wrote: post #7
aetherson wrote: post #5

Earlier quoted context omitted.

64k, not 64.

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?

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.

[1] https://www.mattslifebytes.com/?p=533

Re: OpenSSL Heartbleed Security Update

#14

Post by gojomo »

dpiddy wrote: post #11
gojomo wrote: post #2

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 cl…

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.

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.

Re: OpenSSL Heartbleed Security Update

#15

Post by craigkerstiens »

gojomo wrote: post #14
dpiddy wrote: post #11

Earlier quoted context omitted.

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.

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.

Thanks for the feedback, we have updated the blog post to include some information regarding this.

Re: OpenSSL Heartbleed Security Update

#16

Post by makomk »

danielpal wrote: post #7
aetherson wrote: post #5

Earlier quoted context omitted.

64k, not 64.

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?

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.

Re: OpenSSL Heartbleed Security Update

#17

Post by smw »

dpiddy wrote: post #11
gojomo wrote: post #2

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 cl…

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?

[1] http://news.netcraft.com/archives/2013/05/13/how-certificate...

Re: OpenSSL Heartbleed Security Update

#18

Post by orblivion »

dpiddy wrote: post #11
gojomo wrote: post #2

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 cl…

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.

So is there a simple way to check if an arbitrary site updated their certs?

Re: OpenSSL Heartbleed Security Update

#19

Post by tlrobinson »

mixedbit wrote: post #9

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 coul…

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.
Post reply on HN