Drupal and SSL - Multiple Recipes to Possible Solutions

As Matt Cheney likes to say "Much like Scrabble, the S is an important letter on the internet." If you really care about the data you are sending across the internet you want to make sure you are using SFTP instead of FTP, SSH instead of Telnet, and HTTPS instead of HTTP. So, within a Drupal site how can you use HTTPS to secure the data sent to and from your site and prevent sessions from being hijacked?

There are four basic solutions, though each has its benefits and drawbacks. I'll try to describe each one and give some guidance on the problems. They are covered from what seem to be the most common to the most secure. Note that the third technique is somewhat novel.

Note: All of these assume that you have configured your webserver to use SSL which is well documented elsewhere - I don't think that's useful to try to cover here.

Use the Securepages Module to Encrypt Login and Admin Pages

The Secure Pages module is a relatively old module and quite popular. It's goal is to only make certain pages of the site use HTTPS by using two lists of urls which should either by HTTPS or not. The benefit of this module is that you can use regular old HTTP for most of the site and only encrypt the traffic where you really need it. By default it will encrypt traffic for adding content, editing content, anything related to users, and for the admin area.

SSL processing is taxing on a server. Using SSL on just the most important pages helps make sure that the data sent back and forth on those pages is encrypted. However, the session cookie is still unencrypted so a user who authenticates over HTTPS and then visits a non secure page sends their sesssion identifier in the clear which allows for an attacker to steal their session and login to the site which gives them the access to the very data that was supposed to be protected. This is largely "security theater" but it sure makes people feel good.

Pro: Reduces load on server compared to a full SSL solution while encrypting important data transmission.
Con: Doesn't protect against session hijacking so data can still be compromised.

Using Securepages and Securepages Prevent Hijack

Noticing this weakness, the user grendzy created the Secure Pages Hijack Prevention. This module creates and sends along a second cookie that is marked as "secure" so that the browser will only send it over HTTPS. The module then tracks access to the site and logs out any user who attemps to visit an "important" page without sending along that second cookie.

Pro: Still reduced load on server with reduced damage from hijacking.
Con: Session hijack still possible, but limited in what damage can be done and data is still sent in the clear sometimes (may be an acceptable risk).

Use HTTPS for a session after login

This is a solution that one of my clients created to provide HTTPS pages for all logged in users, and keep all anonymous users on HTTP, but could be extended for other rules as well.

The major piece of the idea is in settings.php:


if ($_SERVER['HTTPS']) {
ini_set('session.cookie_secure', 1);
$base_url = 'https://example.com';
}
else
{
$base_url = 'http://example.com';
}


This little bit of code says "if the user is requesting a secure page, make sure that their cookie is marked as secure and that the base_url variable (used in many parts of Drupal) includes https - otherwise, use the regular http values." The use of the secure cookie flag prevents hijacking but does have one drawback: If the user has a bookmark for the homepage that is not https then their cookie won't be sent along to the site and they will appear to be logged out.

Combine that with a redirect from the regular "user/" pages to the https version and you should be all set.

Pro: Still simple, more complete than a "per path" SSL system, limited possibility to hijack a session.
Con: Potentially confusing to users under certain conditions.

Just Make All Drupal Pages SSL

This is the most secure solution, but also the most resource intensive on the server. If you just make all traffic to the site over HTTPS then it will all be encrypted - problem solved!

You can use Apache's mod_rewrite to achieve this:


RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R,L]

php_value session.cookie_secure 1

Pro: Complete solution. Simple - no extra modules required.
Con: May require more expensive servers, or additional servers.

Which Secure Page Solution Is the Best?

The best solution depends on your specific site, end-users, and privacy needs. Many sites don't need to worry about HTTPS at all. Some want to keep performance up as much as possible and only care about the security of the data en-route, but aren't concerned about session-hijacking (e-commerce where the credit card is not stored). As is often the case, you must balance multiple facets when considering the right solution for your site.

Got any other solutions? See any other pros or cons with the ideas presented here? Please let me know.