SSL Certificates

How to handle the Heartbleed threat?

How to handle the Heartbleed threat?

The Heartbleed bug allows anyone to read the memory of the OpenSSL software. It causes the private keys, the keys that encrypt your internet traffic, to no longer be secure. As a result, this can cause the following:

  • Login names are no longer secure.
  • Passwords are no longer secure.
  • Encrypted data can be read by attackers.
  • Attackers can pose as normal users.
  • Previously recorded data can be decoded, making history records vulnerable to attackers.

In other words: when an attacker has your private key, they can read any encrypted data you send out.

Am I vulnerable?

If you are using Apache, Nginx, Linux/Unix, or any other webserver based on DirectAdmin/C-panel, there is a significant chance you are vulnerable to the Heartbleed bug. If you are using IIS (Windows), you are secure. But beware: if you are using the same certificate on multiple places, for instance on both an IIS (Windows) server and a Linux server, you will still be vulnerable to the bug. OpenSSL is used on almost every Linux distribution. Below, we will show you the steps that you need to follow in order to secure your server.

What can I do?

Please note: the following steps must be followed in the order as they are described!

Step 1:

First, you must check the version of your OpenSSL software. Use the following commando. It may be that your version is only given as 1.0.1, without the letter. In this case it is still wise to update your installation to the latest version.

Option 1:
Arch Linux:
Input: pacman -Q | grep "openssl"
Output: openssl 1.0.1.g-1

Debian and Ubuntu:
Input: rpm -q -a | grep "openssl"
Output: ii openssl 1.0.1e-2+deb7u6 amd64 Secure Socket Layer (SSL) binary and related cryptographic tools

Fedora and CentOS:
Input: dpkg -l | grep "openssl"
Output: openssl-1.0.1e-16.el6_5.7.x86_64

Option 2:
SiteCheck (check here if your server is secure.)

All versions of 1.0.1 up to and including 1.0.1f are vulnerable to the Heartbleed bug. The bug is fixed in version 1.0.1g. Some Linux distributions have released a patch for version 1.0.1e. Earlier versions (such as 0.9.8 and 1.0.0) are not vulnerable to the bug.Almost all Linux distributions from December 2011 and onwards use one of the vulnerable versions of OpenSSL. It is recommended to follow the update process for all these versions. If your version of OpenSSL is vulnerable, you must update your version to the latest, safe, version of OpenSSL, 1.0.1g, or a patched version 1.0.1e

Step 2:

After checking your version of OpenSSL, you must update your installation to the latest, safe, version of OpenSSL, version 1.0.1g, or a patched version 1.0.1e Because the exact update process can vary between distributors, it is recommended to look up the website of either OpenSSL or of your distributor for the best update or patch process for your version.
Below are the commands for some distributors of Linux distributions:

Arch Linux:
sudo pacman -Syu

With these commands you can recall recent updates, including the updates for OpenSSL. In order to successfully recall the updates for OpenSSL, the link must be correct.

Don’t forget to restart your server after running the update:
sudo shutdown -r now

Ubuntu and Debian:
sudo apt-get update
sudo apt-get dist-upgrade

CentOS and Fedora
yum update

For Fedora 19, the latest stable repositories have not been updated yet. You can also run a manual update with the following command:

64 BIT system:
yum -y install koji
koji download-build --arch=x86_64 openssl-1.0.1e-37.fc19.1
yum localinstall openssl-1.0.1e-37.fc19.1.x86_64.rpm

32 BIT system:
yum -y install koji
koji download-build --arch=i686 openssl-1.0.1e-37.fc19.1
yum localinstall openssl-1.0.1e-37.fc19.1.i686.rpm

Step 3:

After updating your installation of OpenSSL, please remember to restart all services and processes, such as the mailservers. It is also recommended to execute “step 1” again to ensure that the update was successful.

Below you will find an overview of the different Linux distributions and to which version of OpenSSL they must be upgraded to:

Arch Linux:
openssl 1.0.1.g-1

Ubuntu:
Ubuntu 10.04: No update required, this version still uses an old version of OpenSSL.
Ubuntu 12.04: 1.0.1-4ubuntu5.12
Ubuntu 12.10: 1.0.1c-3ubuntu2.7
Ubuntu 13.04: Is no longer supported.
Ubuntu 13.10: 1.0.1e-3ubuntu1.2

Debian:
Debian 6 (Squeeze): No update required, this version still uses an old version of OpenSSL.
Debian 7 (Wheezy): 1.0.1e-2+deb7u6
Debian (Jessie): 1.0.1g-1
Debian (Sid): 1.0.1g-1

CentOS:
CentOS 5: No update required, this version still uses an old version of OpenSSL.
CentOS 6: openssl-1.0.1e-16.el6.5.7

Fedora
Fedora 17: No update required, this version still uses an old version of OpenSSL.
Fedora 19: openssl-1.0.1e-37.fc19.1

OpenSSL commando’s:
hhttps://www.networking4all.com/en/support/ssl+certificates/manuals/openssl/openssl+commands/

Step 4:

After the update process is complete, you must generate a new private key and CSR. This can be done by using the following command:

openssl req -out CSR.csr -new -newkey rsa:2048 -nodes -keyout privateKey.key

The required information for the CSR can be extracted from your current certificate. To find this, click on the lock, go to 'Connection', 'Certificate information'. Here you can find the details for your certificate.

Step 5:

After generating your new private key and CSR, you can request a reissue from Networking4All. For this, go to “My account”, “SSL Certificates”, (this will show you an overview of all certificates), click the certificate in question. Towards the bottom, you will see a tab called “Replace Certificate”. Paste your CSR here and click 'Replace Certificate'.

After following these steps, your current certificate will be replaced by a new certificate.

Step 6:

When the new certificate has been issued by the CA, you can install your new certificate on the server.

Tuesday 8 April 2014
Follow Networking4all on Twitter
Twitter Hyves Facebook Google Buzz MySpace LinkedIn Bookmark and Share