<< Ersatz wofür? | Home | Thank you culture >>

HTTP and HTTPS - mixed mode configuration

why it doesn't work and how to fake it

Quite often I'm answering the same question: Customers want to make sure that secret data always gets transmitted through https, while they fear the encryption burden of forcing https everywhere. I need a point to refer to for the future - congratulations, you found this point.

This story has several different aspects. First, let me start with the underlying assumption: 

Mixing http and https does! not! work!

Why? Well, if you don't force everything to be https, you're risking to leak some information through http sooner or later - this can be external content, images, javascript, ajax calls, and they might leak your session information. See Firesheep for what this means. Firesheep, combined with the ever so present unencrypted public Wifi networks, is the reason why all the big sites are finally offering proper https-only access.

Now that this is out of the way, let me get to other arguments:

If you're having somewhat current hardware on your webserver, encryption doesn't impose a huge burden any more when configured sensibly. Yes, there's some more overhead than going unencrypted, but when you need encryption for some data, you probably don't want to do it partially, but correctly. If you don't have experience setting up https, get help from somebody who does (e.g.). Your biggest problem is not how to set up a well performing https endpoint: Your biggest problem is to set it up correctly.

Your (by order of magnitude) second biggest problem is to set up the performance. And if you had experienced help in setting it up correctly, the odds are that performance has been taken care of already. If not, your helping hand was most likely not very experienced. And if you can't affort to pay a helping hand I ask you to first measure your performance unter https before you complain about it being too low. Next, compare it to the odds that someone would get hold of your credentials, abuse your server and how long it would take to bring it back. Add this recovery time to the time that you save by hosting in http/https mixed mode

So, in order for http/https mixed mode to work, you must do everything right, all the time, for eternity, with every update. Otherwise you'll leak a session id. Or include javascript through http instead of https. If everything goes well, you are safe (because your browser won't execute the javascript) but you're up for a time consuming debugging session. Congratulations if you figure out quickly that there's an "s" missing in the middle of an innocent URL that worked yesterday when you accessed the site through http.

Your toolbox

There's a great standard, and depending on the time you read this, it's implemented by most browsers (for IE it's expected in version 12...). The name is HSTS or RFC 6797. By sending a little header, it instructs a browser to only ever contact the given site through https, never through http. It also gives a timespan for its validity - typically at least a year and only test installations have it shorter.

You can (ab)use this standard for a poor-man's mixed-mode implementation. Note that I don't state that this is the solution, it's just a way to implement a mixed mode a bit more safely than without this setup.

In general, enabling HSTS is easy. On Apache, just unconditionally redirect all http traffic to https. On the https virtual server, add the following line to your configuration:

   Header set Strict-Transport-Security "max-age=31536000; includeSubDomains"

The workaround: Enabling mixed mode

For Mixed-mode you omit the unconditional forwarding to https (naturally) and for the HSTS header you just go one level deeper in your stack:  Move the header generation to your application server or application: The application server is supposed to forward login requests and login forms to https and - if necessary - generate new session cookies that never have been used through http. Then, whenever you actually log in: add the HSTS header. This forces the browser for anybody logging in to the site to choose HSTS, while allowing others to freely use http or https - to their choice. 

Yes, this targets the browser, not the user. But in large they're sufficiently synonymous as everybody carries their own browser in their own pocket. And if anybody demands to configure mixed mode rather than https only, this is a good workaround for you to sleep reasonably well without too much of an argument on why mixed-mode does not work.

Now if only every browser would support HSTS...

Crossreferencing: This feature is available as a plugin for Liferay, some more discussion on https setup on Liferay is here. The discussed technique naturally works independent of Liferay.



Securing Liferay Chapter 3: Port issues and HTTP/HTTPS

You probably know the basic installation instructions for Liferay Bundles: ?unzip and run startup.sh? - with this you get to a working Liferay installation in a minute. It will run with all...

Kommentar hinzufügen Trackback senden