Mixing Secured and Unsecured Assets Without Browser Errors

• Forward Proxy
• PHP-Only Proxy
• Security Considerations

One of the benefits realised with the migration of the Perpetual βeta website to SDF’s MetaArray is being able to serve the website over the HTTPS protocol.

When using HTTPS, all of the assets requested by the secured resource should also be available via HTTPS. If they are not, then the client web-browser will most likely complain about the page containing a mix of secure and unsecured content. It’s probably no surprise that the most tiresome handling of this is that provided by Microsoft’s Internet Explorer (MSIE), which interrupts your browsing with a dialogue that you have to respond to in order to continue (and this can happen on every page on a HTTPS site)! Don’t get me wrong, MSIE is absolutely right to advise the user of this condition, but it would be nice if it could do so a little less intrusively.

It can be difficult for a webmaster to ensure that all assets are available from a secure source, particularly in cases where a website relies on resources from an external provider, over which the site’s operator has no control, and for which HTTPS versions might not be available.

Such a condition manifested itself on the Image Viewer pages of this website. In those instances where geographical information is available, the Image Viewer will plot the location where I took the photograph on an inline map, provided by OpenStreetMap (OSM). Unfortunately OSM serves the map tiles from a non-HTTPS server. The Leaflet.js files — that we use to manage the map — are also served over regular, unencrypted HTTP. These assets would therefore trigger a warning in MSIE, on the Image Viewer pages, if we couldn’t address the issue.

Forward Proxy

Fortunately it is really easy to work around this and it’s our old friend mod_rewrite that provides the solution: which is to proxy the HTTP requests and deliver them over HTTPS.

So how does this work? Let’s take a look at what’s happening without a proxy:

We can see that the client web-browser requests HTTPS content from the Perpetual βeta server and also requests HTTP content from example.com. It is this mix of secured and unsecured content that the web-browser complains about.

When we introduce a proxy the situation changes and looks something like this:

What’s happening now is that the client web-browser only makes requests of the Perpetual βeta server. When we need unsecured resources, it is the Perpetual βeta server itself that requests them. It then delivers them over HTTPS. The Perpetual βeta server is thus acting as a proxy between the client web-browser and the unsecured server.

How do we get the server to do this? In this case Perpetual βeta’s httpd.conf file contains the following URL rewriting rules (alternatively, we could implement this within .htaccess):

RewriteCond %{QUERY_STRING} source=(.+)
RewriteRule ^proxy$ %1? [P]
RewriteRule ^tiles\/([0-9]+)\/([0-9]+)\/([0-9]+)\.png$ http://a.tile.openstreetmap.org/$1/$2/$3.png [P]

The first two lines handle the JavaScript and CSS files that constitute Leaflet.js (but we can request any other unsecured resource with these). They will match a request in the form: /proxy?source=http://example.com/

For example:

<script src="/proxy?source=http://example.com/" type="text/javascript"></script>

The final rewrite rule is specific to OpenStreetMap and provides for the retrieval of the map tiles. The rule matches a request that looks like this: /tiles/14/8089/5301.png, which proxies for http://a.tile.openstreetmap.org/14/8089/5301.png

With these rules in place the client web-browser always receives secure assets even when the source of those assets is not secure.

PHP-Only Proxy

In cases where your web host does not support mod_rewrite or where some other server configuration means that you can’t implement a proxy as described above, there are pure PHP proxies that serve the same purpose. I can recommend PHP Transparent Proxy as I’ve used it myself on other projects.

However, you should be aware that these will not perform as well as a pure Apache/mod_rewrite solution as the PHP overhead will add some latency to the proxy process.

Security Considerations

CAUTION: If you decide to implement a proxy solution there are important security considerations to take into account. Strictly limiting access is essential if you are using a forward proxy (such as that described here). Otherwise, any client could use your server to access arbitrary hosts while hiding his or her true identity. This is dangerous both for your network and for the Internet at large. Securing your proxy is beyond the scope of this article, but you’ll be able to find all you need to know with some judicious Googling.