Blogs

Blogs

Securing Liferay Chapter 5: An easily missed HTTPS caveat

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 defaults - which might not be what you want in production.

This is part 5 of a series. All the chapters are linked at the bottom of this article - I recommend to start with chapter 1. This chapter is an extension to chapter 3 - an aspect that you'll not run into when you just follow my recommendation. But if you ignore those recommendations, there's something you might want to know. Just as before, please note that I'm using Apache httpd as the webserver of my choice. If you are more familiar with any of the others: Feel free to search/replace the name. It's the principle that I'd like to discuss, not the name or origin of the webserver.

Tomcat (or: my appserver) speaks https too...

Yes it does. Still, in chapter 3 I'm recommending to configure https through Apache httpd. Why?

  • because I'm used to it and I have it anyway just to get access to mod_rewrite
  • because it supports a lot of different configurations and has a lot of documentation (and implementations) readily available (Let'sEncrypt anyone?)
  • because... security...

What's more secure when Apache httpd handles encryption?

Httpd, being a separate process, typically runs as a different user than tomcat. Further more, it's started as root and drops those privileges once configured. And here's the main reason: You can store your private server key (the crown jewels of a web server) to be readable only to root. And when you're running on a separate server, you even have that level of protection between your Appserver and application (Liferay).

If your appserver handled encryption, it would need access to your private key as well. Granted, the private key in a Java keystore is typically password protected. The only problem is that the password also needs to be read by the user that tomcat is running as. So basically you can't really store the private key (that never must escape your control) in a way that the appserver can't read it.

Any security hole in either appserver or application might expose your filesystem to the outside - and it'd be a very bad idea to leak your private key. You might not even know when it escapes - I find it's a lot harder to properly protect the private key when you only have the appserver doing everything from serving application data to handling connection encryption.

And did I mention that just mod_rewrite alone has saved me hours for quickly fixing issues in production? If you've not yet considered an extra Apache httpd: let this chapter be the trigger for changing your setup. And if you did: Congratulations. Great choice.