Nowadays, it is common (and convenient) to use the Load-Balancer SSL capabilities to cypher/uncypher traffic from clients to the web application platform.
Performing SSL at the Load-Balancer Layer is called “SSL offloading“ because you offload this process from your application servers.
Note that SSL offloading is also “marketingly” called SSL acceleration. The only acceleration performed is moving SSL processing from the application server, which has another heavy task to perform, to other devices in the network…
So no acceleration at all, despite some people claiming they do accelerate SSL in a dedicated ASIC, they just offload…
The diagram below shows what happens on an architecture with SSL offloading. We can clearly see that the traffic is encrypted up to the Load-Balancer, then it’s clear between the Load-Balancer and the application server:
Benefits of SSL Offloading
Offloading SSL from the application servers to the Load-Balancers has many benefits:
Offload a heavy task from your application servers, letting them focus on the application itself.
Save resources on your application servers.
The Load-Balancers have access to clear HTTP traffic and can perform advanced features such as reverse-proxying, Cookie persistence, traffic regulation, etc…
When using an ALOHA Load-Balancer (or HAProxy), there are much more features available on the SSL stack than on any web application server.
It seems there should only be positive impact when offloading SSL.
Counterparts of SSL Offloading
As we saw in the diagram above, the load-balancer will hide three important pieces of information from the client connection:
protocol scheme: the client was using HTTPS while the connection on the application server is made over HTTP
connection type: was it cyphered or not? Actually, this is linked to the protocol scheme
destination port: on the load-balancer, the port is usually 443 and on the application server should be 80 (this may change)
Most web applications will use 301/302 responses with a Location header to redirect the client to a page (most of the time after a login or a POST) as well as requiring an application cookie.
So basically, the worst impact is that your application server may have difficulties knowing the client connection information and may not be able to perform the right responses: it can totally break the application, preventing it from working.
Fortunately, the ALOHA Load-Balancer or HAProxy can help in such a situation!
Basically, the application could return such responses to the client:
Location: http://www.domain.com/login.jspAnd the client will leave the secured connection…
Tracking Issues With the Load Balancer
In order to know if your application supports SSL offloading well, you can configure your ALOHA Load-Balancer to log some server responses.
Add the configuration below in your application frontend section:
capture response header Location len 32
capture response header Set-Cookie len 32Now, in the traffic log, you’ll see clearly if the application is setting up a response for HTTP or HTTPS.
Some other headers may be needed, depending on your application.
Web Applications & SSL offloading
There are three possible answers for such a situation, detailed below.
Client connection information provided in the HTTP header by the Load-Balancer
First of all, the Load-Balancer can provide client side connection information to the application server through HTTP header.
The configuration below shows how to insert a header called X-Forwarded-Proto containing the scheme used by the client.
To be added in your backend section.
http-request set-header X-Forwarded-Proto https if { ssl_fc }
http-request set-header X-Forwarded-Proto http if !{ ssl_fc }Now, the ALOHA Load-Balancer will insert the following header when the connection is made over SSL:
X-Forwarded-Proto: httpsAnd when performed over clear HTTP:
X-Forwarded-Proto: httpIt’s up to your application to use this information to answer the right responses: this may require some code updates.
HTTP header rewriting on the fly
Another way is to rewrite the response set up by the server on the fly.
The following configuration line would match the Location header and translate it from HTTP to HTTPS if needed.
Rewriting rspirep http://www.domain.com:80/url:
rspirep ^Location:\ http://(.*):80(.*) Location:\ https://\1:443\2 if { ssl_fc }The above example applies to HTTP redirection (Location header) but can also be applied on Set-cookie (or any other header your application may use).
You can only rewrite the response HTTP headers, not in the body. So this is incompatible with applications setting up hard links in the HTML content.
SSL bridging
In some cases, the application is not compatible at all with SSL offloading (even with the tricks above) and we must use a ciphered connection to the server, but we still may require to perform cookie based persistence, content switching, etc…
This is called SSL bridging, or it can also be called a man in the middle.
In the ALOHA, there is nothing to do, just do SSL offloading as usual and add the keyword SSL on your server directive.
Using this method, you can choose a light cipher and a light key between the Load-Balancer and the server and still use the Load-Balancer advanced SSL feature with a stronger key and a stronger cipher.
The application server won’t notice anything, and the Load-Balancer can still perform Layer 7 processing.
