Heartbleed: A Scrambled Egg with Lots of Ham

CVE-2014-0160The sensational headline news this week was “Heartbleed” security flaw, which was covered by most mainstream and tech sites.  It was an old bug that was accidentally introduced, and just discovered recently1. The report got IT professionals scrambling to fix their systems.

At first glance, the bug is benign enough, with chances of hacking the passwords or SSL keys rather slim. However, like any other hacking issues, if someone is determined (and clever) enough to exploit this bug, they may just get a bunch of useful data. Whether or not they can use the hacked data to steal client information, or use it for a phishing site, it’s unclear. Just the thought of the potential leak scares the daylights out of everyone! It’s also proof that the marketing behind this bug was very effective.

Regardless, the actions need to be taken are as follows:

  1. Check with Qualys SSL Analyzer to determine if your site is vulnerable.
  2. If vulnerable, upgrade OpenSSL to version 1.0.1g, or alternatively recompile OpenSSL without the “heartbeat” option (-DOPENSSL_NO_HEARTBEATS).
  3. Recompile or restart the web server to reload the latest OpenSSL libraries.
  4. Test the site(s) with the Qualys SSL Analyzer again.  Also check if site is functional.
  5. With the new OpenSSL, generate a new SSL key, and re-key a new certificate.  Install the new key/certificate in the web server(s).
  6. Urge the users to change their passwords – which they occasionally have to do, anyway.  This step is tricky considering the PR scare that it’s going to generate when admitting the site is vulnerable.  However, the notification is the responsible thing to do.

When the dust settles, we can look back and use this as an important reminder how fragile the Internet is.  Customers are expected to be cautious of their data being transmitted over the Internet, no matter how secure a company claim they’re being kept.

  1. Introduced in 2011 and found out in February 2014 []

SSL From Java Client

java_sslI’ve described a way to install a self-signing SSL certificate using OpenSSL for testing purposes.  When connecting to a web server using a web browser client, it is straight forward to add the “fake” certificate (just follow the instructions on the browser screen).  However, in a Java application, it’s a little bit more work.

The procedure is the following:

  • Obtain the SSL certificate from the website administrator.  Alternatively, use the browser:
  1. Browse the URL, for example:  https://www.testmachine.com
  2. When the security window popup appears, just click ‘continue’.
  3. The browser has an option to view the certificate.  With Internet Explorer 7, next to the Address Bar there’s a “Certificate Error” button.  Press that and view certificate.  With Firefox, click on the yellow lock at the bottom of the screen.
  4. Go to the Details tab.
  5. Click on “Copy to File”.  In Firefox, click on the “Export” button.
  6. Save the file as “website.cert”
  • Copy the Cert file to where the Java client is going to be executed.
  • Go to the JRE (Java Run Time) library under lib/security, for example: /usr/local/jdk_1.4.3/jre/lib/security/
  • The certs are stored in a file called “cacerts”.
  • Run the keytool app to import the “website.cert” file that was exported earlier from a web browser:

keytool -import -alias websiteAlias -keystore cacerts -file website.cert

  • Enter the default password: changeit
  • Check the content of the new “cacerts” file using:

keytool -list -keystore cacerts

  • Test it.   If it’s a web container (i.e. Tomcat), restart the JVM.

Webapper site has a short Java client test code, and a quick procedure to compile/run a client to test it.

Setting Up Apache Web Server With Secure HTTP

Incorporating the use of Secure Socket Layer (SSL) library is straight forward with Apache web server.  This is the library I always use for all of my Apache web servers installations.  From one robust open source software to another, they’re a perfect fit.  They make deployment quick and easy.  Here’s are the steps for Apache HTTP and OpenSSL:


Assuming the OpenSSL installation in /usr/local/ssl, the Apache web server source code compilation will require the configure option:

–enable-ssl –with-ssl=/usr/local/ssl

I use the following:

./configure –prefix=/usr/local/apache2 -enable-ssl –with-ssl=/usr/local/ssl

Then just run:

make install

On Unix platforms like Solaris and Linux, the configure and compilation should work without a hitch.


Go to the configuration directory and edit the httpd.conf file (in my example /usr/local/apache2/conf) and uncomment this line:

include conf/extra/httpd-ssl.conf

Then proceed to the /usr/local/apache2/conf/extra directory and edit the httpd-ssl.conf:

  1. Specify the machine’s IP address to “listen” on port 443.  Specifying an IP address is useful if the machine has multi-homed (multiple IPs configured).
  2. Ensure the Signed SSL Certificate is on this machine.  Store it in /usr/local/apache2/conf/www.website.com.cert pathname.  It can be anywhere that’s accessible from the web server level.
  3. The SSL key for the host needs to be available also, and stored in the same /usr/local/apache2/conf directory.
  4. For the <VirtualHost> tags, edit the _default_ with the IP address, and may look something like this:

<VirtualHost IPAddressNum:443>

ServerName www.website.com

SSLEngine On


SSLCertificateFile “/usr/local/apache2/conf/www.website.com.cert”
SSLCertificateKeyFile “/usr/local/apache2/conf/www.website.com.key”

<FilesMatch “\.(cgi|shtml|phtml|php)$”>
SSLOptions +StdEnvVars

<Directory “/usr/local/apache2/cgi-bin”>
SSLOptions +StdEnvVars

BrowserMatch “.*MSIE.*” \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0

CustomLog “/usr/local/apache2/logs/ssl_request_log” “%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \”%r\” %b”



Further options and settings for SSL are available from the Apache.org site:

Creating SSL Certificates for Secure HTTP

ssl_padlockThe use of Secure HTTP (or HTTPS) is essential to avoid getting my browser communication hijacked, or hacked.  For savvy web users, browsing a site with HTTPS is a must to protect login and other private information.  As a Web Application administrator, the way to accomplish this is to use the Secure Socket Layer (SSL) library in combination with an Apache web server.

The widely used SSL library is by OpenSSL.  It’s constantly updated, and it’s freely available.  I use it because it also compiles well on Linux and Solaris operating systems.   The source code is portable and has been tested in many flavors of Unix.  Windows install is available also.  Compiling the source code is as straight forward as running the “configure” script and run “make”.  The default install for OpenSSL is usually in /usr/local/ssl directory.

Once installed, the first step is to create a Key Pair:

/usr/local/ssl/bin/openssl genrsa -des3 -rand <anyfile1>:<anyfile2>:<anyfile3> -out www.website.com.key 1024

  • The anyfile1, anyfile2, or anyfile3 can be any file in the system.  There has to be at least one file specified.
  • Specifying a pass phrase is required in this case.  But for convenience, I might opt to do it without specifying a password.  To disable the password prompt, remove the “-des3” option.

Next create a Certificate Signing Request:

/usr/local/ssl/bin/openssl req -new -sha256 -key www.website.com.key -out www.website.com.csr

Fill in the requested information.  At the end of the questionnaire, a “challenge password” is usually not required.

Updated September 10, 2014: Due to SHA-1 weakness, it’s imperative to let the intermediate cert provider generate a cert without SHA-1 encryption.  Hence the -sha256 option when generating the CSR.

Submit the CSR to a CA such as Thawte or Verisign.  After payment is processed, they will send an email with directions how to get the certificate file.  It might require cut and paste of the cert code into a file, usually with  a .crt or .cert suffix (such as www.website.com.crt).

For development or QA environments, where a valid signed certificate is not required, I can create a self-signing one.  To create a “fake” (aka Snake Oil) certificate, use the following:

/usr/local/ssl/bin/openssl x509 -req -days 999 -in www.website.com.csr -signkey www.website.com.key -out www.website.com.cert

Both the cert and key files are required for the web server.  I’ll cover Apache web server installation in the next post.