Suppose I have a TCP-level load balancer which passes TCP packets between one of two backend HTTPS servers, and the client. In order to ensure no problems with encryption, then the load balancer would have to maintain a table to ensure that X client IP always lands on HTTPS server A and Y client IP lands on HTTPS server B, etc.
Supposing that the client is mobile, what would happen when switching from, for example, 3G to 1X internet connection protocol? In this case that (almost certainly) causes a change of IP address. What would the user experience?
- A re-establish of the SSL/TLS connection? (assuming the user's next click was after the IP address finished changing, there would be no interruption)
- A full break of the secure connection? (the user would see an error and then have to retry)
- A fallback to a lower version of SSL/TLS? (again, no interruption, but what if the IP changes again, would it go back to normal, or fail?)
If you have a load balancer with a good understanding of HTTP (most of them), you can usually configure 'stickiness' to a given real server based on cookie. The load balancer will inject a cookie into the response of the server, with a unique value for each possible real server. On subsequent requests to the same domain, a well-behaved browser will send back the same cookie, which the load balancer will read and use to redirect it back to the same server as before.
It will depend on the implementation of the specific load balancer as to whether it honours that cookie value for differing source IP addresses, or will just put it back in the round-robin (or weighted) pool, but most I have worked with will just use the cookie if a 'sticky' configuration exists.
Your bigger problems will come depending on how you apply your SSL certificate. You will have to have the load balancer do the SSL encryption/decryption for this to work. If the SSL certificate is applied to the server, the load balancer will not be able to inspect the underlying HTTP data in the encrypted tunnel, so will only be able to do TCP load balancing (i.e. wweighted or round-robin). If this setup is required (e.g. as part of some end-to-end encryption contract clause), you will have to set up rules so that one server is favoured over the other, except when it is unavailable (e.g. set it up as a failover backup, not a load balanced service) -- you will simply have to take the brief hit in reconnecting clients in this instance. You might be able to mitigate this in the application by storing the application/session state in a resilient/redundant (database) store and posting the session identifier in every request (by cookie, hidden form field or querystring parameter) -- be very careful re: session security if you do this.
Other stipulations will apply to your application of multiple SSL-enabled web sites on the same IP. Most (if not all) load-balancer/server devices will (can-) not bind multiple SSL certificates to the same IP/port combination. At best, a wildcard certificate for
*.yourdomain.example.orgcan be applied to one IP/port (e.g. to cover www.yourdomain.example.org, other.yourdomain.example.org), or a certificate with multiple SANs (subject alternate names) can be used, instead (although most certificate vendors will not issue a SAN-based certificate with SANs for multiple root domains).