71–80 of 547 posts
This doesn't sound like "responsible disclosure" to me - how can Codenomicon dump this news when all the major Linux vendors don't have patches ready to go ?
Given the severity of this bug, the UX of the site is failing anyone who isn't a fulltime sysadmin. Suggestion: big, bold TLDR ("The sky is falling. Check your OpenSSL version right now") with a link on what to do sorted by OS vendor. Step 1: Here's a command to spit out your OpenSSL version. If it is the following string, go to step 2. Step 2: Here's how to update your OpenSSL. Here are links to guides on reissuing…
On my CentOS boxes I ran 'yum list | grep openssl'
$ openssl version
> OpenSSL 1.0.1f 6 Jan 2014As of now (21:04 UTC) this isn't fixed in Debian https://security-tracker.debian.org/tracker/CVE-2014-0160 nor Ubuntu http://people.canonical.com/~ubuntu-security/cve/2014/CVE-20... Got a long night ahead :/
What popular SSL client software uses the vulnerable OpenSSL? (Any web browsers, for example on popular linuxes? How about 'curl' when connecting to HTTPS sites?)
Email clients may be more vulnerable — Thunderbird doesn't, Mail.app doesn't, but I'm unaware what most use.
How to build openSSL statically into a source build of Nginx, just finished running this with nginx-1.4.7 and openSSL-1.0.1g and it compiled just fine. You'll have to tweak it to your environment of course.
As of now (21:04 UTC) this isn't fixed in Debian https://security-tracker.debian.org/tracker/CVE-2014-0160 nor Ubuntu http://people.canonical.com/~ubuntu-security/cve/2014/CVE-20... Got a long night ahead :/
I just installed update openssl_1.0.1e-2+deb7u5 and libssl1.0.0_1.0.1e-2+deb7u5 on debian wheezy, so it seems the fix is now available.
libssl1.0.0 openssh-client openssh-server openssl ssh
Using a tls-auth key may help mitigate this (especially if you use UDP) since it should stop anything reaching the TLS handshake layer. https://openvpn.net/index.php/open-source/documentation/howt...
Given the severity of this bug, the UX of the site is failing anyone who isn't a fulltime sysadmin. Suggestion: big, bold TLDR ("The sky is falling. Check your OpenSSL version right now") with a link on what to do sorted by OS vendor. Step 1: Here's a command to spit out your OpenSSL version. If it is the following string, go to step 2. Step 2: Here's how to update your OpenSSL. Here are links to guides on reissuing…
I've just shut down the webservers running SSL that I can control. If you are vuln and don't want to build openssl from source and can afford the outage. I'd reccomend to do the same.
OTHERWISE BUILD FROM SOURCE IMMEDIATELY, PATCH, AND GET NEW KEYS!
Let's hope CA's don't get swamped by all the CSR's. Or rather let's hope they do so we see people are doing something...
For me right now these are just my hobby projects. So I don't care if they're down. But I imagine it will be fun tomorrow.
And when it's fixed, get new keys.
Btw: I'm a dev. Not a sysadmin though :P
Edit: Debian is patched. I'm online again \o/
Earlier quoted context omitted.
Worse, it's retroactively unfixable: Even doing all this [revoking certs, new secret keys, new certificates] will still leave any traffic intercepted by the attacker in the past still vulnerable to decryption. So it would be a good idea to change all your passwords to critical services like email and banks, once they have issued new certs and updated their openssl.
Shouldn't Perfect Forward Secrecy protect against exactly this kind of scenario where the server's primary keys are compromised?