Disclaimer: while I dabble with Apache from time to time, I’m not a professional SysAdmin or Apache guru. The things described below is my own experience, and it should not be considered expert advice, just a staring point. An other way to say it: if you know better, please leave a comment :).
AskApache (a great blog BTW for technical network related stuff – the only negative thing being that sometimes it is too technical :)) has an article about mixing secure (fetched through HTTPS) and non-secure (fetched through HTTP) elements on a page. Usually the result of doing something like this is that the browser displays a warning and/or a broken lock instead of a normal lock. This can scare away security conscious users. Two things you can do to remedy this:
If you host the resources the link goes to, use the HTTPS protocol to link to them. Most of the times people use plain HTTP to link to static elements (like images, style-sheets and so on) because the encryption in the HTTPS protocol creates an overhead and we want to keep CPU utilization low for our servers
. Here are my counter-arguments: modern servers have plenty of CPU power. Also, most (read 99.9%) of modern web browser do multiple requests over the same connection, so that the encryption key is negotiated only once every N minutes (where N is around 15 if I remember right). An other argument would be (if you are using a hosting company): I never seen hosting companies charing by the amount of HTTPS connections made. Finally the big argument: are you ready to loose visitors / sales / whatever your site is about because users mistrusting your site (because of the warnings) to get some little speed and scalability gain?
If the given resources are not hosted by you and are not accessible through a secure connection, you could use mod_proxy to create a virtual proxy to make it seem as the response comes from your server. (You could also simply copy the page / image in question to your local server and serve it up from there, but that includes all kind of copyright problems). Some advantages and disadvantage:
- Advantage: you eliminate the mixed content warning
- Disadvantage: You are using double the bandwidth (because your server first fetches the given resource – thus using downstream bandwidth – then sends it to the client – using upstream bandwidth)
- Advantage: it is seamless for the client
- Disadvantage: you have to have mod_proxy installed. It is not included in the default Apache installation and SysAdmins are not very happy to install it, because it can very well be a security risk it not configured properly
- Advantage: it works with dynamic resources (for which the make-a-copy and serve-it-from-the-local-server wouldn’t work even if you would to resolve somehow the copyright issues)
One final note: the AskApache article talks about hosting videos (Google and YouTube) on a secure page. The interesting thing is that the browser only cares about the fact that the player is loaded through a secure connection, not that the video (loaded by the player) loads through a secure connection. This is done because the browser has no control over the plugins (in this case the Flash player) behavior. The good news is however that because of this if you chose the proxy solution, you don’t have to proxy the entire video, just the player (which is obviously much smaller).
4 responses to “Including mixed (SSL and non-SSL) content on your secure site”
Yeah I’m glad you liked the article, I am still using it without mod_proxy to this day, works great on IE7
The reason I’m considering mixing SSL and non-SSL on the same page is because of caching. As far as I understand, SSL content is not cached. So if you load all your assets via SSL (images, stylesheets, etc), the browser has to download it on every page view. This is a huge performance issue. I think there is a small period of time when the negotiated SSL key is still valid, and a page view during that small window will allow the asset to be pulled from cache. But I think the data is stored encrypted in the browser cache, so once the key expires and is re-negotiated, that data is invalid. And it is a noticable performance hit.
Yes, the W3C spec states that SSL’ed assets must not be cached, so SSL’ing an entire site causes huge server load and client side performance issues.
If you are running a public facing website then this will usually mean the difference between 1 page request for returning customers and 20 hits.
I would really consider putting some heavy disclaimers at the start of this article that it is only for people who aren’t interested in their website scaling.
@damon: there is a disclaimer at the beginning of the post 🙂
I’ve done some research and here is what I’ve come up with:
IE has a well known bug whereby it doesn’t download resources over SSL if they have 0 cache expiry time. So the resources to be downloaded at all, you should set an expiry time in the future (this is true of IE6, I don’t know if it got fixed in IE7/8).
Firefox 2 doesn’t cache SSL content to disk by default, however version 3 seems to do so under some conditions.
My conclusion is: yes, it does introduce some scalability problems. In general, you can rely on it being cached during the browsing session, but not in between browsing sessions. As always, it is a tradeoff between security (which becomes more important as the use of wireless – an easy to sniff medium – becomes very widespread) and costs.