How does one know which version of Openssl generated which keys/certs? It doesn't seem to say in the certificates or keys themselves, nor the index.txt file. I really can't remember which version I was using back in Dec. 2012 when I made them. By openssl.org's release dates, it was possibly openssl-1.0.1c. I really, really don't want to regenerate an entire root CA, all the keys, the requests and the certs after revolking the old ones for about a dozen services!

The heartbeat issue is only for implementations using the secure stream program. Key generation was not compromised.

The reason for regenerating keys is due to servers using the vulnerable library _may_ have leaked the key information when being used. Since there is no trace of if/when the library used may have leaked key information, the safe bet is to regenerate keys in case someone may have used the heartbeat vector and copied private key information from an existing session.

Again - it has nothing to do with what library was used to generate keys - only when keys were used by the vulnerable library.

1 members found this post helpful.

I got an email today from Dynadot about Heartbleed and they urged me to change my password. I only have my domain names there and no website hosting; do I really need to create a new password?

Here is a good wiki about the bug.

Does anyone know if this is relevant for all of us using APACHE and Linux?

http://gizmodo.com/how-heartbleed-wo...-se-1561341209

http://www.bostonglobe.com/business/...YTJ/story.html

http://www.cnbc.com/id/101566234

It's relevant to anyone who is using https on apache that has a vulnerable versions of OpenSSL.

There are numerous sites available that can test if your server is vulnerable.

If it is then you will need to patch appropriately, have new SSL certs issued by your provider and have any users that authenticated to the website change their passwords.

Thanks for clearing that up. It saves alot of time.

I'm confused ( again )!! Some are advising to not to be in a rush to change passwords.
http://www.theguardian.com/technolog...y-experts-warn

My understanding from the reading is that it can also be used against the client side, too.

I think the best thing to do is wait until they ask you to change the password, that is after they have fixed the vulnerability. Changing your password before they fix the vulnerability is worse than keeping your current one.

Basically, users should not rush into anything.. It's the sysadmins that should rush to implement the fix.. Come to think about it, considering the certificate key is vulnerable, phishing scams are also possible until the certificate has been revoked.. So not rushing does make sense..

I think it's best to wait until the service asks you to change your password (for example, I'm a volunteer supporter in an online game.. Sure enough, yesterday all volunteers and employees found themselfs with expired passwords and a request to change them) .. That's basically what every service affected by this should do, I think

Altough, keep in mind that while this is a very important update and very critical exploit, people would have started noticing strange logins from different places.. It's also very unlikely to get compromised on systems that have double authentication if your logins are from a different computer or from different countries or regions... Even if your password is found, they still couldn't get passed the second step of auth..

Basically, while this could have been exploited in the silence to gather scattered data (and of that we can't be sure if it was or not).. But it's very unlikely that it was not exploited on large scale without trying to compromise authentication and leaving traces..

Also, and this is a definite don't do it is to click on links from received e-mails that asks you to change the password... Like I've mentioned above, phishing scams are possible right now

Hey LQ,

My server is vulnerable, my OpenSSL version is 1.0.1 dated March 2012. How can I patch this? Apt-get isn't offering me any updates.

Not all versions in the "1.0.1 series" have the `Heartbleed bug'.

I think the vulnerable versions are listed in one of the current Heartbleed threads:
http://www.linuxquestions.org/questi...ed-4175500917/
* http://www.linuxquestions.org/questi...ty-4175500994/

Here is the original commit that introduced the bug:
http://git.openssl.org/gitweb/?p=ope...2116ad75f822b1

7pm on Dec 31st - I imagine not many eyes on it at that time or the next day.
If I wanted to hide a vulnerability in a system, that's the time I would do it.

1 members found this post helpful.