JSession and SSL Session Persistence

SSL Session persistence is not a solution, the issue with new SSL requests which generate a new SSL SessionID is valid.

 

 

The real solution is to base persistence on the JSessionID (for java apps) or php sessionID or whatever cookie is being set.

 

 

I was actually able to persist users across 2 different VIP's (one HTTP and one SSL) using the JSessionID in a cookie hash profile and matching that across virtuals. So long as the pool members in each VIP are the same this will work. If they are not it won't work. If they are not than the user will hit 2 different servers one for HTTP and one for HTTPS.

 

 

In a clustered environment where true session replication is working, persistence is a really stupid thing to use. No offense to anyone. But in reality so long as the F5 can understand who the primary and secondary cluster replicates are it should be able to load balance to them, if the first goes down it knows who has the session.

 

 

mod_jk and proxy plug-in's like weblogic and websphere have this ability built in, which is why many folks choose to use them, however, based on personal experience with the mod_jk it cannot handle extreme load, it ends up bogging down the server. The weblogic proxy-plugin is exteremly efficient...go figure.

 

 

At any rate, I digress. If there is a reason to persist to SSL sessions, I would highly suggest offloading SSL to the F5, using server side SSL (if the app requires SSL to run on the servers) and then use a simple Cookie persistence profile that looks for the applications cookie, not the SSL SessionID.

 

 

-Wes