Secure connections: encrypt, inspect and decrypt traffic when using a WAF

Protect both web servers and users, with this combination of layers and tools.

We’re often asked how to configure our load balancer to protect both web servers and users. To answer this fully, there are a number of parts to consider and like any good security implementation, it’s best done as a combination of layers and tools. In this blog, we’re going to focus on the implementation of the Web Application Firewall, or WAF.

To secure the connection from the connecting client machine (your user) you should use an encryption layer, this is possible using an HTTP over SSL (HTTPS) connection. This ensures an application-to-application secure, encrypted, tunnel is used point-to-point so that a ‘man-in-the-middle’ attack (someone watching the traffic between client and server) can be mitigated. Communication between the load balancer and the real server can also be SSL encrypted. We refer to this as the ‘re-encrypt to backend’ feature.

Using both of these methods together means that any time there’s data ‘on the wire’, it’s encrypted. Seems simple enough so far? Great, let’s get a little more complicated.

It’s often desirable to use a WAF to ensure that potentially harmful requests (SQL injection, remote command execution, etc) aren’t passed on to the real servers - think of it as a sieve for HTTP traffic - which is fully tunable to the individual requirements of a deployment.

WAFs and encryption

To make this possible we have a WAF built right into our appliance as standard, configurable via the WebUI. We already have an excellent blog on how to configure the WAF - so I’m not intending to tell you how to do that. The important part to appreciate here is that the WAF can’t directly read encrypted traffic – here's where it starts to get interesting.

For the WAF to process the traffic, we must first decrypt the HTTPS traffic so it can be handled in ‘clear text’ - importantly, this can be restricted to clear text within the load balancer only, if desired - then pass it through the WAF before passing this onwards toward the real server.

Decrypting the traffic is done by configuring an ‘SSL termination’, using an appropriate certificate that would be recognised and trusted by the connecting browser - otherwise you’ll see nasty redness in the address bar and your users will get warning messages. This is placed before the WAF.

So, now we can catch the encrypted traffic at the SSL termination, decrypt it and pass it through the WAF, before it makes its way to the real server. The WAF itself doesn’t perform the load balancing directly, it hands this over to HAProxy, the Layer 7 load balancing service, for it to make the final connection to the real server which - could be encrypted, if desired.

One of the issues we need to address is that users will generally only type in your website address, for example, www.mydomain.com. For historical reasons, browsers will try to connect to this without the encrypted HTTPS by default, but with HTTP. Never fear - we can help there too. There’s a way to make a browser initially connect on HTTP (port 80) then reconnect on HTTPS (port 443) where we catch the encrypted traffic with the SSL termination.

The redirection capability lies within the Layer 7 service, which issues a redirect code to the client. This is known as ‘Force to HTTPS’ within our WebUI and is configured within a Layer 7 virtual service.

So, we have:

• an HTTP mode Layer 7 virtual service accepting traffic on port 80 in clear text, telling any clients to reconnect on HTTPS
• HTTPS connections are picked up by the SSL termination and passed into that same Layer 7 virtual service which detects the traffic coming via the SSL termination and passes it onward to the WAF
• The WAF processes the traffic and hands it over to a Layer 7 virtual service where load balancing algorithms are applied and finally onward to the real servers, encrypted if so chosen
• The response traffic takes the reverse traffic through the ‘chain’ on its route back to the client machine.

This diagram makes things clearer:

Of course you can achieve the same effect by using the same, or a similar, toolset to us and writing the configuration yourself. We make no secret of the fact that we leverage other, carefully chosen, software to provide a solution to the administrator. Here’s an abridged version of the software we use:

• SSL termination - stunnel.org
• WAF - Apache HTTPD and mod_security
• Layer 7 load balancing - HAProxy

Of course using our load balancer makes all this much easier! Our appliance enables you to load balance, encrypt and protect your traffic, all through our WebUI. To find out more, feel free to schedule a demo – you'll explore our product with us, discuss your requirements in depth, and find out how we're able to design a bespoke solution that fits with your system needs.