Forum Discussion
bchick2_8645
Nimbostratus
NimbostratusSSL Cache Timeout
This is my first time posting so I apologize if this isn't the best place for this. I'm trying to learn more details about the Cache Timeout settng in the SSL profile. We have an issue where it appears a users SSL session has expired on the Big IP even though they have continued to be active. Basically we log when an SSL session is created, what that SSL session ID is, the source IP, and a couple other things. An hour later (after the default cache timeout expires) and the user makes their next action a new SSL session is created at the Big IP. If we change the cache timeout setting to two hours the behavior occurs after two hours. Does this timeout not get extended with activity? Is there a way to make it be extended like most timeouts? I expected when I saw this value and it's default of one hour that the SSL session would expire after one hour of inactivity. This only causes a problem for us because we're associating a client cert with the SSL session ID (in the session table) and when the new SSL session is negotiated for some reason IE is not resending the client certificate and does not prompt the user to select one. Since it is associated with the old SSL session ID the user just gets redirected to our "client cert required" screen in the middle of an active session. As far as our back end app server is concerned it just didn't receive a client cert from Big IP so that is the default behavior (to redirect to that screen).
I can provide more details if necessary but I'm really just trying to understand the SSL cache timeout as that seems to be the key to resolving our issue. (In case you're wondering the timeout on the "session add" command that adds the cert to the session table is currently set to be longer than the cache timeout and it doesn't make a difference. Testing has indicated that timeout does get extended with activity (apparently) unlike the cache timeout).
natheCirrocumulus
bchick2
As far as I understood the SSL Cache Timeout is only interested in when the SSL negotiation takes places and is not interested in activity. It's use is to increase the performance on the box, in reducing the amount of SSL renegotiations that take place but this is counter balanced by the decreased security of having the same session open for longer periods. So, to conclude, you are seeing the expected behaviour.
Hope this helps,
N- bchick2_8645So essentially you're saying it forces renegotiation after the timeout expires? That would make sense with what I'm seeing. What about the renegotiation being disabled in the SSL profile? Does that setting only apply to client initiated renegotation? Also, do you know if you can set timeout to zero to never renegotiate? What would be the downside to doing that? Is it considered a security risk? Thanks for the quick reply.
- bchick2_8645Nevermind, what you said plus what is in SOL6767 answers my questions. I think what we see is complicated by the middleware that we run that accesses client certs on smart cards. It has a pin timeout of its own. It appears that if it has timed out before the Big IP forces renegotiation IE is unable to access the client cert and so sends no cert in the handshake. Then our users get redirected to the client cert required page in the middle of an active session. I'll do some testing to verify that theory tomorrow. If that's the case we'll probably have to either set the cache timeout to indefinite or at least make it longer than our typical users average session.
nitassEmployee
An hour later (after the default cache timeout expires) and the user makes their next action a new SSL session is created at the Big IP.it isn't client renegotiation, is it?
when the new SSL session is negotiated for some reason IE is not resending the client certificate and does not prompt the user to select one.have you seen "client certificate request" from bigip during ssl handshake?