http://www.extremetech.com/article2/...2305570,00.asp
Ubuntu made a fix last fall that inadvertently broke OpenSSL's encryption strength and reduced it to only 32768 possible keys. They didn't mention where the bug is, but I have the feeling it's in the openssl program used to generate the keys, or a supporting library because you need to generate new certificate requests for your cert and have Verisign or whoever regenerate the cert, once the software is patched.
32768 combos is extremely easy to brute force so this is serious.
Look for the patch. If you have a production site running on this, it might be good to get your apache, openssl and php compile-from-source chops sharpened and install apache and openssl from source so you can get it fixed right away.
If you install it all in /usr/local/apache2, and /usr/local/lib/openssl (default) it won't stomp your existing packages or break anything when the upgrade packages come out.
Remember, you need to compile every service you run which uses ssl and link it to the new openssl installation. In configure do a ./configure --help | grep -i ssl to see the ssl options. In these guides, assume /usr/local/bin/openssl wherever you see openssl being run, or you'll just create another weak cert.
The author says "Expect tools to come along soon to help". The "tools" are included with openssl. ROFL
Here's a link on
building a production ssl certificate using openssl.
And... here's one for mail
that uses openssl for encrypted mail communication
So you can do your thing when the patch comes. Make sure you install gcc and related tools on your system before starting.
I am not sure about how fast they patch something like this at Ubuntu, but if it's going to be weeks, it would be very bad to wait.
I've been compiling my lamp setups for a long time and it's not hard once you've done it. It can be scary if you haven't. Just remember you aren't breaking anything while compiling, and the resulting code will be ignored until you kill Ubuntu's apache and start it manually from /usr/local/apache2, so stay calm. It's pretty hard to mess up a system as long as you stick to /usr/local...
You can even start it on a nonstandard port on your production machine to stand it up for testing before you damn the torpedoes and cut over.
Once patch is released, you patch, kill the one you compiled and cut back, then clean out the apache2 directory or whatever you want to clean up.
To get your current php configure line, make this script:
<?
phpinfo();
?>
Near the top you'll see the compile options. Just give the php source's configure the same option set(with paths adjusted for openssl and apache), aim openssl link to /usr/local and the world will turn. In configure point php to the php.ini ubuntu is using.
I started doing it in 2002 when the 0.9.x version was vulnerable to a worm and the patch hadn't been done in a week. I had to because our ISO VP was in my cube telling me he was shutting down our server farm if ssl wasn't patched by 5PM that day. I got one server done, switched all traffic to it by 5PM. I was there til 10AM the next morning. Red Hat got their package done about 6 weeks later.
To this day I keep the latest source ready to distribute and compile on a moments notice and compile all exposed services so I can patch minutes after it's released. The only way to stay on top of all the changes in compiling is to do it all the time. Once bitten, 20x shy.
-Viz
