Yes that sounds correct. SSL Session ID is pretty
useless these days for maintaining persistence. If
you are terminating SSL on your load balancers, doing
cookie based persistence is probably your best bet.
If you are not terminating on the load balancer and
are encrypted all the way through, you are pretty
much stuck with source ip based persistence, which
basically sucks if you have lots of clients coming
On Tue, 5 Feb 2002, Allan Liska wrote:
> Hi all,
> I am trying to develop a definitive policy for SSL Session-ID based load
> balancing, and I am wondering if you all can help, because there seems to
> be a lot of confusion.
> This is my understanding of how the process works, and the problem with
> the Microsoft bug, if I am missing anything, please let me know:
> 1. A client initiates a session with a server.
> 2. The client and the server share the following information:
> Protocol Version
> Session ID -- Generated by the Client
> Cipher Suite
> Compression Method
> 3. After the hello session has completed, the server sends its certificate
> to the client.
> 4. In subsequent transactions, the server will use the SSL Session ID to
> track session information with the client.
> In the case of the browsers listed here:
> The SSL session ID is regenerated every 2 minutes, which creates a new
> session. Making it possible for a client to lose persistency if the site
> is being load balanced.
> Does all of this sound correct?
The Load Balancing Mailing List
MRTG with SLB: http://vegan.net/MRTG
Hosted by: http://www.tokkisystems.com
This archive was generated by hypermail 2b30 : Tue Feb 05 2002 - 11:50:30 EST