Reverse Proxy Configuration
When working with reverse proxies and load balancers, the typical setup looks like this:
- The Connection between the client and the reverse proxy is using https.
- The Connection between the reverse proxy and the LiquidFiles system is using http (this should probably be switched to https if you're using LiquidFiles v3.3 or later — see further down).
In LiquidFiles, there's two configurations you need update so that it works properly with reverse proxies — adding the reverse proxy as a trusted proxy and ensure that the required protocol is permitted.
Adding the proxy as a trusted proxy
The first setting you need to do is to add the IP address of the reverse proxy as a trusted proxy in LiquidFiles:
A reverse proxy is supposed to send the clients real IP address using an X-Forwarded-For HTTP header. Every reputable reverse proxy automatically does this, and if things are not working as expected it might be good to double-check. Adding the IP address of the reverse proxy as the trusted proxy will make LiquidFiles trust this X-Forwarded-For header on behalf of the reverse proxy.
Without the trusted proxy, all connections will appear to come from the reverse proxy. The means that things like GeoIP lookups won't work, blacklist of clients after failed attempts will blacklist the reverse proxy, i.e. everyone.
Should you use http or https between the reverse proxy and LiquidFiles?
How can this be? History tells us that http should give better performance, and up until v3.2, that might have been the case. Since v3.3, LiquidFiles has switched from HTTP v1.1 to HTTP/2. HTTP/2 is only available over https and switches to binary transfers and more importantly has connection re-use, meaning that there's a lot less setting up and tearing down connections with HTTP/2 / LiquidFiles v3.3. All tests so far shows that HTTP/2 is faster even if it does require https, than http.
For optimum performance, it's most likely better to use HTTPs.
On default, LiquidFiles requires all connections to use HTTPs.
If you wish to enable http between the reverse proxy and LiquidFiles, please go to Admin → System & Hostname & Public URL, and change the configuration as the following:
By setting the Protocol to "Permit either HTTP or HTTPs", both HTTP and HTTPs will be permitted, and with the Public URL set to HTTPs all links sent in emails and similar will use HTTPs.
Will using a Reverse Proxy improve my security?
Mostly — No, our experience is that you're likely going to make things worse with a reverse proxy.
Going back a few years, common knowledge was that using a reverse proxy, any reverse proxy, would improve security for all web server and web services. This is not true any more. LiquidFiles, that uses a modern web server configured according to modern security standards is more than capable of residing on the hostile Internet without any form of reverse proxy.
There are basically two types of reverse proxies. Simple
reverse proxies and
Web Application Firewalls (WAF).
A Web Application Firewall will look at all the traffic and has the capability to intercept common web application threats
and block in real time.
Configuring any Web Application Firewall will take weeks for each application that you on-board. Some have a builtin learning capability so that you can whitelist things that it has caught that's considered false positivies. If you use a Web Application Firewall, it should prevent attacks from reaching the LiquidFiles system and give a lot more detailed logging over the attacks and will therefore improve the overall security as if nothing else you'll get increased visibility.
If you use a simple reverse proxy that cannot look at specific web threat patterns and highlight for instance if any forms are not using Cross Site Request Forgery protection, likilehood is that both security and performance will suffer.
Session Cookie Secure Flag and HSTS
Two things that often come in security reviews when using reverse proxies is that the session cookie secure flag is not set and that HSTS is not configured. The session cookie secure flag tells the browser that this cookie can only be used for https sessions and not http sessions. In LiquidFiles, this is enabled if you configure the http protocol as "Force https". That's the only setting that will guarantee that the client will always use https (this is the default setting and on default the session cookie secure flag is set). If you follow a traditional reverse proxy configuration, you'd use https between the client and the reverse proxy and http between the reverse proxy and the LiquidFiles system. In LiquidFiles you configure a protocol setting other than "Force https", and since LiquidFiles then can no longer guarantee that the client will always use https, and indeed what happen in this configuration, and we can no longer set the session cookie secure flag in LiquidFiles.
It's similar with HSTS. HSTS is a function that tells client that until a specified timeout you are only permitted to connect to this server using https. The recommended timeout and the timeout that LiquidFiles uses is 1 year. Please see the LiquidFiles HSTS documentation for more information about HSTS. Similarly to the session cookie secure flag, LiquidFiles cannot tell clients to force connections over https unless you configure LiquidFiles with the protocol setting to "Force https".
In both of these cases, you have two options, either use https all the way to the LiquidFiles system, or you will have to configure your reverse proxy to set the secure flag for the session cookie, and configure HSTS in the reverse proxy.
Web Security Testing
A simple way to test the web security configuration is to use SSLabs SSL test on the LiquidFiles system. A default configured LiquidFiles system will receive an "A+" score. If you don't receive an "A+" score when using LiquidFiles through a reverse proxy, you have made LiquidFiles less secure than if you didn't use a reverse proxy.
Our experience is that most reverse proxies are not configured for optimum security and have less secure default configuration that what LiquidFiles has. With the default configuration on both, security (and performance) will therefore be better by not using a reverse proxy. If you implement a Web Application Firewall, take the time to both configure it properly and have a system for ongoing monitoring, you'll block attacks before the reach the web application, get an incrased visibility of the threats and overall increased security. But with a simple reverse proxy that don't inspect the traffic, the best you can really hope for is that you don't make things worse. Use the SSLabs SSL test and test upload and download speed with and without the reverse proxy and decide what's best in your instance.