Are there any set back factors regarding HTTPS load-balancing?

Question

Are there any set back factors regarding HTTPS load-balancing versus HTTP load-balancing?

Could this be a reason, why doesn't HTTPS spreads on various websites? (there are cheap CA's on the market)

Answer 1

I'm not sure James is correct. My understanding is that the SSL handshake starts and ends with the request/response pair. Even if HTTPS supports TLS resume via session keys, those resume keys would be on the front-end load balancer with the client, who would always be hitting the same load balancer.

That being said it's entirely possible to load balance to HTTPS servers, the reasons most people do not, I believe, are:

• There is significant overhead in decrypting SSL. Many load balancer products do this in hardware and save compute time on the webservers (or application servers in a 2-tier configuration)
• There is more (double, probably) overhead in decrypting and rencrypting on the same device.
• It requires you to set up valid certificates internally, ideally. This doesn't have to cost any money, but it would require either money or a reliable, secure, internal CA. Simply put, it's more management overhead.

Answer 2

Your question seems a bit confused.

If you mean what are the disadvantages of HTTPS compared with HTTP, then:

1) it's a lot slower - athough the badwidth overhead isn't that great, the problem as ever is latency - SSL requires at least 2 additional round trips per request.

2) Proxies can't cache data - making it even slower

3) There is significant impact on anything which might want to handle processing - such as content firewalls and load balancers

The processing overhead isn't that big - the performance problems are all about network latency - and terminating the SSL off the webserver doesn't help.

Answer 3

It isn't the cost of the certificate so much (although that is debatable and tends to be based on which CA one is utilizing and that CA's licensing requirements) but the cost of servers. Load-balancing HTTPS traffic vs. HTTP traffic isn't all that much different from an implementation standpoint either. It's all cost driven. SSL can be an expensive operation from a cpu standpoint, for both the key exchange and the encryption/decryption of data. The total number of concurrent users you can get from a server is going to be lower with HTTPS than the total number of concurrent users over HTTP, meaning you'll need more servers to do the same thing.

Although they do work very well, devices that offload those ssl operations can also be fairly expensive.

"Traditional" web sites (as opposed to web applications) tend to have a highly trafficked component of the site that is strictly marketing content, which is mostly stateless and anonymous traffic. While important to the Business, press releases, marketing communications, product spec sheets, downloadable or online demonstrations, etc., are all designed to convert those anonymous users into buyers but why encrypt that anonymous traffic? I think that site admins tend to view this as a non-optimal and unnecessary use of computing resources.

Web 2.0, social networking, and web applications are different though and should be ssl encrypted primarily because, by their very nature, there is no anonymity between user and site. After all, the very first thing one tends to do on a Twitter or Facebook is sign in.

Answer 4

Well, HTTPS isn't stateless/connectionless; the client must return to the same server for subsequent connections because the session keys are held in cache on that server. With HTTP, as long as the content is replicated across your servers, it doesn't matter which server the client hits, and they can be sent to a different server on subsequent requests.

Also, one of the main reasons people do terminate the SSL on a load balancer, is to save costs on certificates; place one certificate on the LB, decrypt the traffic, pass to your servers as plain HTTP, and then re-encrypt the return traffic through the load balancer.

I'd suggest further reading on the SSL/TLS handshake process: http://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake_in_detail