TLS (I still have to get used to saying TLS instead of SSL) everywhere is a goal many sites attempt to achieve. There are however issues if you try to convert an existing site to "all SSL". Many legacy pages may refer to resources by the full URL using the http protocol. For example, we keep finding image tags in old diaries on our site from time that are still pointing to http. 

Having a mix of secure and insecure content can be a problem. An attacker could manipulate the insecure content, and with that, affect the content the browser loaded securely. Rightfully so, browsers have become more picky when it comes to mixed content, and stopped displaying or executing some mixed content.

After you convert your site to https only, the first thing to do to reduce the impact of legacy http links is adding the "String Transport Security" header (HSTS). This header will let browsers know that your site is only valid via https, and browsers will refuse to connect to your site via http going forward [RFC6797]. 

HSTS does however not help if the browser comes across a page including insecure content. The warning regarding insecure content will still be displayed. A new technique, "Upgrade Insecure Requests" can be used instead.

All this is made possible by Content Security Policies (CSP). A new standard [1] defines a "upgrade-insecure-requests" option that will instruct the browser to rewrite all references for insecure content to https. This way, the mixed content warning will no longer be displayed.

The advantage of this method is that you do not have to update the content of the pages. If you run a site with thousands of legacy pages (like us), it can be difficult to find and fix every last image and script reference. Instead, we let the browser handle it and all we have to do is to add the header to our server configuration.

To enable this feature, add the "Content-Security-Policy: upgrade-insecure-requests" header,or a <meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests"> meta tag. As an added bonus, if a reporting URL has been defined for the CSP violation, it will be reported to the site and remaining insecure content can be eliminated. The header of course should not prevent you from cleaning up your site.

According to caniuseit.com, this option is currently supported in Chrome and Opera with support in Firefox coming [2]. It is marked as "under consideration" for Internet Explorer.

Thanks to Caleb for alerting me about this new option. Caleb also collect HTTP headers as a hobby at https://securityheaders.com .

[1] http://www.w3.org/TR/upgrade-insecure-requests/
[2] http://caniuse.com/#feat=upgradeinsecurerequests

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn