In other posts I discussed how to redirect the initial request to a website from the HTTP version to the HTTPS  (for Apache and IIS).

By following those steps your website no longer will serve HTTP content but users will still be able to get to your site without having to know to type the HTTPS:\\ before they browse to your site.

This is an important part of making your site reachable by users over SSL because:

1. Most users do not type a URL moniker at all when entering an URL.
2. Since 99% of the traffic on the Internet is not available over HTTPS so browsers default to HTTP.
3. Existing HTTP URLs that have been indexed by search engines, embedded in documents, passed off in emails can continue to work.

This approach isn’t perfect, for example:

1. An attacker can perform a Man-In-The-Middle on the initial request and bypass the SSL protection (see sslstrip).
2. It has the potential to “train users” to not navigate to the HTTPs version of your site initially.

The problem is of course that the alternative of returning an error when a user requests the HTTP version of the website (say a 403.4 – SSL required) or simply not having a server listening on the HTTP port is almost the same as saying your site isn’t accessible to the mainstream users.

So how can you manage these problems? There are a few things you can do:

For sensitive services like those for login and those that collect personal information or credit cards actually use 403.4 errors. This tells the user in no uncertain terms that SSL is required for that task but since the browsing experience does not typically “start here” you do break the user experience for your users.

You may also want to consider hosting the most sensitive content like login and account details on a separate virtual host that does not have a HTTP listener (for example login.example.com or accounts.example.com).

Next you should communicate your policy on SSL to the web browsers so they can do the right thing for the users, there are several ways for you to do this:

1. Set the HTTP Strict-Transport-Security (HSTS) header for your pages this will tell the browsers to require SSL on your site.
2. Request that your site be added to the HTTPS Everywhere Rule list.
3. Request that your site be added to the Preloaded HSTS list in Google Chrome.
4. If you are a larger site you can also request that Google “pin” your web server’s public keys to your domain.

These things will not eliminate these risks but it does help, especially for those using browsers that support HSTS (Chrome and Firefox as of today) or those that are using plugins like HTTPS Everywhere and NoScript.

As for the last two, they are clearly Chrome specific but it represents about 32% of the browser market today and as such is worth paying attention to.

Ryan

Additional Resources

How to Deploy HTTPS Correctly