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 []

URL Rewrite Examples

Rewrite Right - Flickr PhotoOne of the most common Webmaster task is to use mod_rewrite Apache module.  It’s a flexible and efficient way to redirect URLs.  It is useful to redirect non-functional URLs, moving domain names or renaming directories.

Below is a list of some of the frequently used mod_rewrites.

Note the [R=301] entries for 301 Permanent Redirect directive on the rules.  It’s a popular use to preserve SEO rankings of an older site that has been moved to a new one.

Simple redirect:

RewriteRule ^/sub/dir/home.html$ /sub/dir2/page.html [R=301,L]

Redirect http://domain.com to http://www.domain.com.  This is especially useful for an SSL certificate that’s already registered to www.domain.com name.  Note, the rule captures the query string and redirects with it:

RewriteCond     %{HTTP_HOST}    ^domain.com$      [NC]
RewriteRule     ^(.*)$          http://www.domain.com$1      [R=301,L]

To capture more than one variables in the query string, use the following.

RewriteRule ^([^/]*)/([^/]*)/([^/]*)$  /sub/program.jsp?arg1=$1&arg2=$2&arg3=$3 [L]

For redirects based on the URL’s query string, use QUERY_STRING to capture it for comparison.  Note the destination URL may use spaces if enclosed in quotes.

RewriteCond %{QUERY_STRING} ^id=2234$
RewriteRule ^/sub/dir/product.html$ “/sub/dir3/description.html?prodid=vac pro” [L,R=301]

Redirects can also be conditional.  For example, redirect everything except with a certain keyword.

RewriteCond %{REQUEST_URI} !/sub/dir/important.html$
RewriteRule ^/sub/dir/.*$ /main/dir/home.html [L,R=301]

With the above rule, it’s possible the original URL may have a query string.  To get rid of it, just add “?” to the end of target RewriteRule. For example:

RewriteCond %{REQUEST_URI} !/sub/dir/important.html$
RewriteRule ^/sub/dir/.*$ /main/dir/home.html? [L,R=301]

There are more examples out there.  Writing a comprehensive mod_rewrite guide is a full time job, so this list will continue to grow.  Here are some other useful references:

Photo Credit: Luke Seeley

Custom 404 Page Using JBOSS

Missing PuzzleHaving a custom “page not found”, or 404 page, is an important modification for any website.  It’s used to enhance the user experience by presenting an easy to understand message.

Setting up a user friendly error page is simple enough using Apache web server.  Just modify the line in httpd.conf and point it to a static HTML document:

ErrorDocument 404 /the404_page.html

With JBOSS (or Tomcat-like Java container) application server, it’s slightly trickier.  It has to be handled per web application basis.  The change is done on the web.xml file, with these entries:




For the root directory, modify the web.xml in the ./deploy/jboss-web.deployer/ROOT.war/WEB-INF directory.

Testing this setup in Firefox and Opera, the custom 404 page will automatically show up properly.

However, with Internet Explorer, a “The Webpage Cannot Be Found” message comes up instead.  This is a feature of IE to show Microsoft’s version of a “friendlier error message”.  In this case, we want to disable it, so the custom 404 page will show up.  It can be done via Internet Options -> Advanced tab :

Option in IE to Supress Custom 404 Error Page

Update: Microsoft Help & Support site states if the 404 error page is greater than 512 bytes, then IE will not show the friendly message.  So the page size must be a bigger one, not just a simple one liner.

Now that the applications are setup to serve up custom error page, here are some examples of beautiful 404 page designs to improve the user experience.

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: