6

I have a web farm where the web servers are responsible for negotiating the secure connections. Does anyone else with a web farm go out of their way to reduce TLS handshake overhead by ensuring that TLS resume handshakes are supported? And if so, why?

We are switching from a sticky session to a more balanced load balancing algorithm. We are concerned that we will lose the benefit of the TLS resume feature. Assuming every connection from a client goes to a different webserver, we are assuming a full TLS handshake will be required. I don't know the overhead, but if we are looking at 20ms round trip it would appear that the full handshake will take 3x or so as long to complete.

Dennis Williamson
  • 64,083
Brian Adams
  • 61

3 Answers3

4

I don't know how large the OPs web server farm is, but for most smaller / midsized installations I find it cleanest and simplest to handle all TLS/SSL on the load balancer. So you have:

Internet (HTTPS req) -> L7 HTTPS proxy LB -> plain HTTP on LAN -> webserver

o3 Magazine had a good writeup on how relatively easy this is with nginx, and what performance numbers you can expect. f5 posted a commentary on the benefits of using a commercial appliance for SSL acceleration instead of a DIY solution (IMHO somewhat biased).

Note that you'll need your web servers to inspect X-Forwarded-For and X-FORWARDED_PROTO headers and handle the connection correctly.

Most installations should get by fine with a single HTTP & HTTPS load balancer, or a pair of load balancers in active/passive configuration for HA. In this setup handshake resume is a non-issue, as there is only one SSL/TLS endpoint (which typically will automatically support handshake resume).

0

I was under the impression that one the connection had been established, even with a load-balancer in place, all future connecitons in that session would happen to the same server?

Perhaps that's merely how sites I've used and services I've configured operate.

warren
  • 19,297
0

Assuming you're using Apache, have a look at distcache. From the man page, "the distcache architecture provides a protocol and set of accompanying tools to allow applications, and indeed machines, to share session state between them by way of a network service."

"The primary use of distcache right now is SSL/TLS session caching. This allows SSL/TLS servers (eg. a secure Apache web server providing HTTPS support) to use a centralised session cache, i.e any server may resume SSL/TLS sessions negotiated by any other server on the network. The advantages to this approach include increased freedom of mechanisms for load-balancing."

Gavin Brown
  • 113