ssl-l4-fallback

[casablancag]

Hi I have a question regarding advance-balance ssl. I have a content configured with advance-balance ssl and apllication ssl. Now our customer claims that the ssl stickiness doesn't work well. The SSL Stickiness is based on SSL Session ID but after 3 Frames should the stickiness fallback to a lyser 4 stickiness. That means that if the Session ID change and the IP Address is still the same the stickiness should not be compromised. Is it right ?

[Gilles Dufour]

actually - no.

We only insert the L4 hash in the sticky table if we can't find the session id in the first 3 packets.

In your case, with a changing session id, the CSS is able to retrieve the session id but it does not match the previous ones in our table.

So, we simply loadbalance the connection - no stickyness.

There is no solution for broweser like IE that keeps on chaning the session id.

You need to switch to another sticky method like sticky source ip.

Regards,

Gilles.

[andrew.thomson]

Hi,

We have had similar problems in the past.

I do not think it is IE browser that changes the SSLID, rather it is the "Security Providor" used by the browser (SCHANNEL).

SCHANNEL has had a number of changes applied over the last few Windows releases. There is a registry setting ClientCacheTime, which determines when the SSL session expires and has to be refreshed. The default setting for this is different for different versions of Windows.

There is information on the actual values for this setting in the Microsoft Knowledge base.

Basically older versions probably have a timeout of around 1-2 minutes.

Later version it is 10 hours.

But all of this is of no value if you are not in control of the desktop (i.e. public internet access).

However if you do have control of a managed desktop, within an organisation for example, try setting the following registry entry to a high value:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

DoubleWord keyword Value pair

ClientCacheTime = Decimal 36000000

This is 10 hours in milliseconds.

Even when using this setting we have seen instances of clients sometimes renegotiating an SSL session with a backend server right at the beginning of the browser session (not sure why at the moment), but it seems to stick for all subsequent tcp connections.