LiquidFiles Documentation
LiquidFiles Documentation
On This Page

Reverse Proxy Configuration

When working with reverse proxies and load balancers, the typical setup looks like this:

  • The client is connecting to liquidfiles.company.com using the external IP address 20.30.40.50.
  • liquidfiles.company.com on IP 20.30.40.50 is terminated at the reverse proxy.
  • The reverse proxy is making a second connection to the internal IP 10.1.2.3.

HTTP or HTTPS for the internal connection

Traditionally internal connections in reverse proxy setups have been using HTTP but we absolutely recommend that you use HTTPs everywhere. There's a few reasons for this:

  • Without HTTPS everywhere, HSTS cannot be enabled.
  • Without HTTPS everywhere, Secure Cookies cannot be enabled.
  • The traditional reason that using HTTPS will improve performance just isn't true on modern systems, at least not with the usage profile of LiquidFiles.
Without HTTPS everywhere, security will be degraded and if you perform security audits and similar, please be prepared that this will be highlighted as a potential risk.

Configuration using HTTPS everywhere

In LiquidFiles, there's three configurations you need update so that it works properly with reverse proxies — setting the Public Hostname correctly, adding the reverse proxy as a trusted proxy and ensure that the required protocol is permitted or enforced.

The configuration you need to make sure is correct is available in Admin → System → Hostname & URL:

1: Public URL — set this to the URL you want the end users to use when accessing LiquidFiles and please make sure you select to use HTTPS. You can set the System Hostname to the same or something different if you want.

2: Protocol — with HTTPS everywhere, set this to Force HTTPS. This is the default setting.

3: Trusted Proxies — you will need to enter the IP address of your reverse proxy/proxies in order for LiquidFiles to be able to determine the correct IP address of the client that's using LiquidFiles

Please see the Public URL documentation for a complete description of these options.

Configuration using HTTP

The only real reason to use HTTP between the reverse proxy and LiquidFiles is if you have an IPS or similar you want to inspect the traffic and you cannot configure the IPS to inspect HTTPS traffic.

To configure LiquidFiles to use HTTP between the reverse proxy and LiquidFiles and still use HTTPs for the overall connection (between the client and the reverse proxy), you need to configure LiquidFiles as follows:

1: Public URL — set this to the URL you want the end users to use when accessing LiquidFiles. You can set the System Hostname to the same or something different if you want.

2: Protocol — Set the protocol to permit either HTTPS or HTTP.

3: Use Public Hostname in URLs without this the client may be redirected using HTTP and submit forms using HTTP depending on your reverse proxy configuration. Some reverse proxies can be configured to inspect and rewrite all links so that they are forced to use HTTPS within the reverse proxy. Setting Use Public Hostname in URLs will also ensure that the Public Hostname and HTTPS is set for all URLs.

3: Trusted Proxies — you will need to enter the IP address of your reverse proxy/proxies in order for LiquidFiles to be able to determine the correct IP address of the client that's using LiquidFiles

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. If you're using HTTP between the reverse proxy and LiquidFiles, you're almost certainly decreasing security, since we can no longer use secure cookies and HSTS.

Background

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 this scenario, it is not possible to use secure cookies (even if you would be able to overwrite this in the reverse proxy, you would not be able to login).

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 2 years. 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".

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.

Conclusion

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.