Forum Discussion

Bernard_9290's avatar
Bernard_9290
Icon for Nimbostratus rankNimbostratus
Jul 12, 2011

SSL::session invalidate issue

BIG-IP version:10.2.0 HF1

 

 

We have a virtual server with a client SSL profile configured for mutual authentication and we would like to invalidate the SSL session when the user logs out from the associated application by using an iRule.

 

 

To do that, we execute "SSL::session invalidate" in the http_request event when matching the logout URI (/f5logout).

 

 

The session is successfully invalidated only if the "SSL::session invalidate" command is not followed by a redirection or "http::respond".

 

 

Otherwise, the session remains active. It means that the user doesn't have to renegotiate a SSL session (provides the password protecting the private key) if he wants to logs in again in the application.

 

 

Any idea if there is restriction in the "SSL::session invalidate" command usage?

 

 

The iRule...

 

 

when HTTP_REQUEST {

 

switch [HTTP::uri] {

 

"/f5logout" {

 

drops the session from the session cache to prevent reuse of the session

 

SSL::session invalidate

 

HTTP::redirect "http://domain2"

 

return

 

}

 

}

 

insert specific X509 information in header

 

HTTP::header insert "DN" [X509::subject [SSL::cert 0]]

 

insert the entire client certificate in header

 

HTTP::header replace SSLClientCert [b64encode [SSL::cert 0]]

 

}

 

 

Bernard

 

  • 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.