WWW Prefix Is Superfluous

HTTP WWW

When Tim Berners-Lee made famous the “World Wide Web” by introducing the HTTP protocol, he set the standard that all web sites would start with “www” as a host name prefix. It was supposed to indicate it’s a web site, for everyone who hadn’t seen this new way of using the Internet.

That was the early 90’s.

Now, 20+ years later, the World Wide Web is as ubiquitous as e-mail or postal code addresses. Everyone knows what to do when they open a browser.  Even better, when someone receives an email with a web link (URL) in it, even though it’s not safe to click on any random links via email if source of information is not checked.

So why do web developers and content managers still tag on the prefix www into their host names?  Perhaps, out of habit because that’s how they learned to use the Internet from 20 years ago.  Maybe the fault is with e-mail servers, like Microsoft Exchange, creating automatic hyperlinks whenever “www.” is in the text, which makes it easier for mailing list managers to create content without deliberately hyperlinking URLs.

Whatever is the reason, people need to stop adding the prefix www when entering a web address. It’s a pain to setup on the server and network sides because DNS have to contain both entries (as alias or A records), web servers need to accept both host names, and SSL certificates have to be requested with www as a common name.

Besides, without the www prefix, it’s easier to tell someone (written or verbal) of the website’s shorter address. Nowadays, the prefix is superfluous and unnecessary.

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

IE6 Still Lingering

W3CSchools has stats for IE6 usage at about 15%, as of May 2009.  IE6 in Enterprise environment is still being used,

It’s steadily dropping because of the wide acceptance of Firefox, and Corporations are proactively upgrading to IE7 or IE8.   This number will change dramatically when Enterprise favors Windows 7 as the new standard for productivity machines.

Some websites have already taken steps to prevent IE6 from loading their site.  I can only applaud their efforts.

IE6 Denial Image

IE6 Denial Image

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

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.