Thursday, 31 July 2014

Why you should never mix HTTP and HTTPS

Hopefully if you are reading this, you are reasonably familiar with HTTPS otherwise known as HTTP-secure and based on encryption, which is usually TLS, although known by its older name of SSL (apparently the name was changed when it moved from the private to the public domain in order to avoid accusations of bias to Netscape who developed it)

Without HTTPS, if your page contains any kind of data, let's say it displays a user name and password to you, then even if you have to login to see that information, at some point that data is sent over the internet in plain text including all the HTML and any scripts etc. that make up the page.

You have pretty much no control or knowledge of where that data goes between the server and the browser. It could go through a country where things are spied on (like the UK!) or it could pass through a corporate network that has spyware installed, hacked network routers or any one of various things that could send that private data to someone else.

It should be obvious that if that data is encrypted in some way, like SSL/TLS, between the server and the client, then even if someone can read the network data, they will not know what the data contains and your data will remain private. The clever thing about SSL/TLS is the encryption key is generated and sent in a way that cannot be intercepted by a spy using the SSL certificate of the server, which can be matched to the URL you typed in and to the authority that issued it.

On some sites, however, you might see this:


or this




And if you hover over it you get a warning that says, "this page contains both secure and insecure data..." and is often caused by a page that uses SSL but includes adverts or plugins/analytics that are only available on plain HTTP. I occasionally see it on Facebook, of all places (naughty Facebook)



but why does this matter? Surely as long as the important stuff is sent over SSL, the rest of the page content can come however it wants can't it?

The problem that this presents is that not only is HTTP readable, it is also modifiable to someone who has a certain amount of network access and who can intercept your request/response. How does that work? Well, if I can act as a proxy and see you (or more specifically, a part of your page) request, let's say http://advertiser.com/someadvert.php, then I can retrieve the result myself and add a few extra pieces of data to it, let's say that I just add an additional script to the result. This script will be invisible and there is no way that the browser will know that the response is not from the server but has been modified in transit. Now imagine that my script runs after the page loads and takes the contents of the username and password form fields and then sends them to my site to collect and user later!

Is that really possible? Absolutely and it is very easy to anyone who can act as a proxy between your browser and the server you think you are talking to. In some countries that is everyone who uses the internet. All of the protection that your page got from SSL has gone in the trash by a simple single use of an HTTP connection.

Sometimes a company might provide an SSL option for extra money and most of us want the free version which is HTTP only but really you should not compromise your site security for the sake of a few dollars. You might not even know your site is hacked because it is not exactly hacked, you simply start getting reports of unexpected logins or unauthorised transactions and have to assume that your site is compromised somehow.

If any part of your site needs to use SSL, then your WHOLE site needs to use it and we should never see the mixed-content warning every again. You can also use a content security policy and/or strict HTTP security http header to force the browser to prevent loading of non-SSL content.

Another cool article here: https://community.qualys.com/blogs/securitylabs/2014/03/19/https-mixed-content-still-the-easiest-way-to-break-ssl
Post a Comment