Recipe 8.4. Forcing a Secure Connection

Problem

You need to make sure that pages and forms that handle your visitors' confidential information are transmitted over a SSL connection between their browsers and your web server.

Solution

Use an Apache mod_rewrite rule in an .htaccess file to check the connection type, and switch to a secure connection before the page is returned to the visitor's browser:

 RewriteEngine On RewriteCond %{SERVER_PORT} !443$ RewriteRule ^(.*)$ https://yourwebsite.com/path/to/ssldir/$1 [R=301,L] 

This rule will apply to every file in the same directory as the .htaccess file, and to all the files in its subdirectories as well.

Discussion

Many web surfers are familiar with the protocol acronym that signifies a secure web connection: the https:// that precedes the location of the page they're requesting. That doesn't mean, though, that they'll always use it, even when it's in their best interest to do so. You can help matters by carefully coding your links with the https:// prefix, especially when they target parts of your site where a secure connection is critical, such as your online store checkout or login form. But visitors who manually type in the address (or otherwise use http:// rather than https://) might be unnecessarily exposing their confidential information without knowing what they're doing.

The rewrite rule I've presented in the Solution tests the connection type and switches to a secure connection if the browser has not requested one.

As you've seen in other Recipes that use Apache's rewrite engine, the module must be enabled on your web server for this solution to work.

When Apache gets a request that begins with https://, it responds to the request over a different port than the one it uses for a standard request. Port 443 is Apache's default port number for secure connections, while port 80 is the standard port number for non-secure connections. When a visitor requests https://yourwebsite.com, Apache processes the request over port 443.

Ports are a rather esoteric concept, since they rarely appear in the actual URL of the browser request, and do not correspond to a physical component on the web server. Picture Apache as a old-fashioned telephone operator sitting behind a switchboard.

For most of the requests it receives, Apache plugs the line that completes the connection into a jack on the switchboard marked "80;" for secure connections, Apache connects the browser to a jack marked "443." The Apache module that encrypts data using SSL only works on port 443 connections (see Figure 8-3).

Figure 8-3. Much like an operator, a web server directs requests to where they need to go

The first line in the .htaccess file activates the rewrite engine. Then the conditional statement checks the port number of the connection.

The port number need not be part of the URL the visitor requests for the rewrite rule to work.

Even though port 443 and the https:// prefix go hand in hand, the conditional statement does not test the URL for the presence of https://; rather, it checks the port number, which is available to the rewrite engine through the Apache environment variable {SERVER_PORT}.

A connection over anything other than port 443stated in the second line as !443$activates the rule in the third line. The rule takes any URL not requested over port 443^(.*)$and redirects it to the same page over a secure connection, starting with https://.

See Also

Recipes 1.6 and 9.1 discuss other uses for Apache's rewrite engine.