SSL::session invalidate issue

Hi Bernard,

 

 

I've used SSL::session invalidate in CLIENTSSL_CLIENTCERT successfully, but not tried it in HTTP_REQUEST. The wiki page shows an example in HTTP_REQUEST though.

 

 

What do you see if you log [SSL::sessionid] after calling SSL::session invalidate and HTTP::redirect?

 

 

If this isn't working for you, you could open a case with F5 Support. Make it clear in the case request that you're not looking for them to write an iRule for you--just test why an existing iRule isn't working as expected.

 

 

Aaron

Hi Aaron,

 

 

Please find below what we see when logging the SSL::sessionid and certificate subject

 

 

Logging has been added as follows:

 

 

------------------------------------------------------

 

when CLIENTSSL_CLIENTCERT {

 

log "Session ID : [SSL::sessionid]"

 

}

 

 

when HTTP_REQUEST {

 

switch [HTTP::uri] {

 

"/f5logout" {

 

log "Session ID Before : [SSL::sessionid]"

 

SSL::session invalidate

 

log "Session ID After : [SSL::sessionid]"

 

log "SSL Cert After : [X509::subject [SSL::cert 0]]"

 

HTTP::redirect "http://domain2"

 

return

 

}

 

}

 

-----------------------------------------------------

 

 

Note that the result is the same when logging after both SSL:session invalidate and HTTP::redirect commands.

 

 

We get....

 

 

first login and browsing

 

Jul 13 11:24:32 local/tmm1 info tmm1[17322]: 01220002:6: Rule IR_ATE_PassCert_V04 : Session ID : 1c5b8031b6a318735016fc00e2309171886c2208429e385c7f573559fc761bc9

 

Jul 13 11:24:32 local/tmm info tmm[17321]: 01220002:6: Rule IR_ATE_PassCert_V04 : Session ID : 1c5b8031b6a318735016fc00e2309171886c2208429e385c7f573559fc761bc9

 

 

logout

 

Jul 13 11:24:41 local/tmm info tmm[17321]: 01220002:6: Rule IR_ATE_PassCert_V04 : Session ID Before : 1c5b8031b6a318735016fc00e2309171886c2208429e385c7f573559fc761bc9

 

Jul 13 11:24:41 local/tmm info tmm[17321]: 01220002:6: Rule IR_ATE_PassCert_V04 : Session ID After :

 

--> the session ID is now unknown OK

 

Jul 13 11:24:41 local/tmm info tmm[17321]: 01220002:6: Rule IR_ATE__PassCert_V04 : SSL Cert After : CN=xyz,...,C=BE

 

--> the certificate is still in the F5 cache NOK

 

 

Login again without closing the browser: access is transparent (no password to provide) and user gets back the same session (The ID is identical)

 

Jul 13 11:25:21 local/tmm2 info tmm2[17323]: 01220002:6: Rule IR_ATE_PassCert_V04 : Session ID : 1c5b8031b6a318735016fc00e2309171886c2208429e385c7f573559fc761bc9

 

 

Bernard

 

 

Hi Bernard,

Can you try calling 'session delete ssl [SSL::sessionid]' to remove the SSL cert from the session table? I'm thinking something like this:

      HTTP::respond 302 Location $location Connection Close Cache-Control No-Cache Pragma No-Cache
      session delete ssl [SSL::sessionid]
      SSL::session invalidate

If that doesn't work, I think you might need to call SSL::renegotiate after SSL::session invalidate to request that the client negotiate a new SSL session.

However, doing using SSL::renegotiate will open you up to the vulnerability described in SOL10737. There is a fix in 11.0beta2 and possibly one for 10.2.x. You could open a case with F5 Support to get status on this. See this thread for details:

http://devcentral.f5.com/Community/GroupDetails/tabid/1082223/aff/5/afv/topic/aft/1178540/afc/1251057/Default.aspx

Aaron

Hi Aaron,

 

 

I think we have found the root cause of the issue with "SSL::session invalidate command". It seems that the command has not been designed for multi-processers F5 units.

 

 

The iRule is successfully executed in our production environment on a BIG-IP 4100 which is single processor.

 

 

We are now migrating to F5 BIG-IP 8900 which are multi-processor units (2x4 processors) and where we have encountered the issue.

 

 

This is confirmed when displaying the number of the CPUs executing the iRule (via TMM::cmp_unit) in the logs

 

 

When the CPU used for the "SSL::session invalidate" command and the CPU used for the first request after re-login are the same, the SSL session is not in the F5 cache and we need to provide a password. In this case the invalidation is successfull.

 

 

However, when the CPUs are not identical, the SSL session is still in the cache and the login is transparent which is really a security issue.

 

 

Bernard

 

 

Hi Bernard,

 

 

I thought the SSL cache was shared across all units. Which version are you testing this on? If you're seeing the session ID different on different cores I suggest opening a case with F5 Support.

 

 

Aaron

Hi Aaron,

 

 

We have migrated yesterday from 10.2.0 HF1 to 10.2.2 to make sure we have all the latest fixes.

 

It looks like the cached SSL session is indeed made available accross all units. When navigating in the application, as we can see in the logs, distinct processors are sometimes used and the SSL session remains the same.

 

However the session invalidation seems only to invalidate the cached session at the "scope" of the processor that has executed the command.

 

 

We have now opened a case with F5 support.

 

 

Bernard

That's interesting. If that's the case it seems like a bug. Please reply back with what you find out from Support.

 

 

Thanks, Aaron

It looks like this was tracked in the following bug:

 

 

BZ365698 - ssl::invalidate does not work correctly on CMP environment

 

 

If anyone else is affected, I'd open a case with F5 Support and ask for an engineering hotfix be provided for you.

 

 

Aaron

just to point to the offical info on this issue: http://support.f5.com/kb/en-us/solutions/public/13000/900/sol13955.html

 

so from 10.2.4 HF4 it shouldn't be an issue anymore.