HTTPS Persistence Question

Quick answer: HTTP cookie persistence is best.

 

 

You can technically use either, and both are good. But know that a) either party in an SSL conversation can (and eventually will) renegotiate the SSL session, and b) it will change the SSL session ID.

 

Sorry, but I didn't think SSL persistence was an option when you're terminating SSL on the device.

Thanks all .

 

Hi Steve , do you mean that because session is decrypted before sending to server , so i cannot persists based on SSL info ? only HTTP persistence

That's correct SSHSSH.

Per the guide:

 

 

 

SSL persistence is a type of persistence that tracks SSL sessions using the SSL session ID, and it is a property of each individual pool. Using SSL persistence can be particularly important if your clients typically have translated IP addresses or dynamic IP addresses, such as those that Internet service providers typically assign. Even when the clients IP address changes, Local Traffic Manager still recognizes the session as being persistent based on the session ID.

 

 

 

The SSL session ID is accessible both when and when not terminating the SSL on the BIG-IP, and is a valid persistence method in some instances. The guide goes on to say,

 

 

 

You might want to use SSL persistence and source address affinity persistence together. In situations where an SSL session ID times out, or where a returning client does not provide a session ID, you might want Local Traffic Manager to direct the client to the original node based on the clients IP address. As long as the clients simple persistence record has not timed out, Local Traffic Manager can successfully return the client to the appropriate node.

 

 

 

Translation: browser clients or servers can (and likely will) re-negotiate the SSL session during the application session, at which time the SSL session ID will change. Every browser does it differently, but most modern browsers will usually go a few hours before re-negotiating. In any case, re-negotiation is inevitable the longer the session is open, so it's a good idea to have a secondary persistence mechanism in place (ie. Source Address).

 

 

To see the persistence records for SSL (terminated or non-terminated SSL), you can look at the statistics in the browser or type the following from the shell:

 

 

tmsh show ltm persistence persist-records

 

 

Ultimately though, HTTP cookies are the most reliable browser-based persistence type, and have the added benefit of putting the burden of persistence tracking back on the client.

 

Kevin, this article for v11.2.1 still states SSL persistence is not possible where the SSL terminates on the device: http://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm-concepts-11-2-1/ltm_persist_profiles.html?sr=254024371192492

 

 

"Note: The SSL persistence type is only valid for systems that are not performing SSL certificate-based authentication of client requests or server responses. If you are using Client SSL or Server SSL profiles to configure certificate-based authentication, do not configure an SSL persistence profile. Instead, create an iRule to perform SSL session persistence."

The basic reason for this statement is that, on some platforms, the SSL session ID does not traverse multiple TMMs. So a multi-core system may create multiple (different) persistence records for a single connection. I don't recall what platform has resolved this. Disabling CMP for this virtual server solves that problem.

 

 

So while it DOES work when terminating the SSL, cookie persistence is still the most reliable method.

 

Good to know. Thanks.