New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
I'm actually more amazed by the fact that heartbleed.com was available as a domain this whole time.
And I was just about to roll out my website with full HTTPS.
Thanks for this!
It wasn't.
http://www.domaintools.com/research/whois-history/search/?q=heartbleed.com
"The oldest record dates back more than 6 years."
Looks like it was some kind of emo blog back in 2007-2008, then the usual link farms after that.
Crap, this bug has been out for 2 years!
Looking at archive.org, I can't tell if it was run by an angsty 14 year old emo girl or if this is satire.
...and after you update openssl, make sure to rebuild everything using openssl on your system (that is, everything you initially built against the vulnerable one).
What shall I do with my cPanel servers? They are on the "release" branch for updates and still run 1.0.1e-fips... Any hints?
This is crazy!!! I'm assuming CA's are gonna be busy with revocations and re-issues for a while!
I don't use a webpage with https but of course I use SSH. Does a simply apt-get update and apt-get upgrade fix the problem for me?
If you're using Arch Linux and have this problem, enable the testing repo and update OpenSSL.
Also, make sure to reboot after the update to make sure the old version isn't in the memory anymore
If you're on Debian Wheezy, that should do the job.
Check if you're running OpenSSL 1.0.1g or higher though.
And again, reboot.
@xBytez
I did a restart on all my vps as well. Futhermore I checked and I only use libssl not openssl. Does this change anything?
openssl 1.0.1.g-1 is in the regular repo since yesterday, it seems.
Restart on 27 Boxez and installing updates thankz!
By the way, OpenSSH is NOT vulnerable to this. Because it does not use the TLS protocol. So you don't need to worry about changing keypairs, etc.
CentOS have announced an update fix which is now syncing to mirrors (http://lists.centos.org/pipermail/centos-announce/2014-April/020249.html).
It's a bit confusing for the update to contain 'e' (openssl-1.0.1e-16.el6_5.7.i686.rpm) when a lot of reports are saying that versions OpenSSL 1.0.1 through 1.0.1f (inclusive) are vulnerable?
Relevant changelog for Ubuntu openssl package:
https://launchpad.net/ubuntu/+source/openssl/+changelog
Run "apt-get update; apt-get upgrade" to see other software that have been updated in the Ubuntu repos. Before doing that, make sure you have "deb http://security.ubuntu.com/ubuntu ... " in your "/etc/apt/sources.list".
For Debian: http://www.debian.org/security/2014/dsa-2896
Also see: http://seclists.org/bugtraq/2014/Apr/34
For CentOS: https://rhn.redhat.com/errata/RHSA-2014-0376.html
Server vulnerability test: http://filippo.io/Heartbleed
(credit for link goes to @tchen)
After updating OpenSSL, check which services use it and will need restarting with command:
lsof -n | grep ssl | grep DEL
(credit goes to @George_Fusioned)
In case of doubt a full system restart is recommended.
Ironic that HTTP is in some ways safer than HTTPS here.
Am I right in thinking that even after you patch OpenSSL you have to re-generate any private keys (and CSRs) generated by the vulnerable version?
Am speaking to a provider who's telling me that the patch and restart is sufficient, and that there's currently no need to re-key any certs.
I know cloudflare is currently speaking to their CA's about the logistics of re-keying all their certs!
That's from the heartbleed.com FAQ
Another scary thing, is that currently, it doesn't look as though you can tell (Or at least it's not very easy) whether you've been hit by this vulnerability.
If the keys are suspected to have been leaked, then, of course, certs ought to be regenerated ASAP... which is going to be a major inconvenience for CA certs provider and for everyone else really.
^ That confirms that certs with new keys should be generated.
Ah I see.
So I guess there's no need to re-generate keys unless you suspect foul play. But with no (current) way of telling if you've been exploited, would it not be safer to regenerate existing keys anyways?
Although I understand for large scale operations (like cloudflare) this is no mean feat.
EDIT: Read in the cloudflare blog comments, that they're checking their logs to see whether they've been affected. So they may have a way of identifying whether they've been hit.
How does all this affect OpenVPN keys? Do they need to be replaced.
Guys i have having an issue to update openssl via yum
yum update
shows package not foundCan someone come in with a tutorial
How does all this affect OpenVPN keys? Do they need to be replaced.
Yes.
What do you see when you run, 'openssl version -a' ?
Note: Even after the update on CentOS, Fedora and RHEL, the OpenSSL (short) version will still show 1.0.1e.
Run 'openssl version -a' and check the build date. It should be April 8th.