Forum Discussion

Dave_Burnett_20's avatar
Dave_Burnett_20
Icon for Nimbostratus rankNimbostratus
Jul 03, 2012

SSL Session Ciphers

Recent testing has identified that our web host allows clients to resume an SSL session with a different cipher to that originally negotiated.

 

 

e.g The server allowed the following session over SSLv3 to be resumed as follows : Session ID : 61ed39e667977078d6740c3b489280d9f62c56eac1bbf8a63eb76fe6d5de5ace

 

Initial Cipher : SSL3_CK_RSA_RC4_128_SHA (0x0005)

 

Resumed Cipher : SSL3_CK_RSA_DES_192_CBC3_SHA (0x000a)

 

 

We are being told that an attacker managing to locate the start of an SSL connection might be able to manipulate the session cache to cause subsequent resumptions of the session in order to use a cipher chosen by the attacker.

 

 

Is there a way the F5 can be configured to enforce resumed SSL sessions into using the originally negotiated cipher or is this purely a web server configuration ?

 

 

Many thanks

 

app sec
BIG-IP Access Policy Manager (APM)
security

6 Replies

Sort By
  • nitass's avatar
    nitass
    Icon for Employee rankEmployee
    Jul 03, 2012
    is this relevant?

     

     

    sol12543: OpenSSL vulnerability CVE-2010-4180

     

    http://support.f5.com/kb/en-us/solutions/public/12000/500/sol12543
  • Dave_Burnett_20's avatar
    Dave_Burnett_20
    Icon for Nimbostratus rankNimbostratus
    Jul 03, 2012
    A really prompt response ! Thanks for this.

     

     

    It may be relevant, but I'm not totally sure?

     

     

    This article infers that the F5s are not vulnerable to CVE-2012-4180, which relates to an open-SSL vulnerability allowing the downgrade to a weaker ciphersuite of an SSL session

     

     

    So you think, fine, we're OK as we're running one of those versions.

     

     

    But then it goes on to say that clients can only change to a cipher that has been enabled on the F5, which seems to suggest that attackers could still change the cipher and use it to attack the webserver session.

     

     

    So, do we have a vulnerability or not ?

     

     

    And, I suppose my original question is still valid - can the F5 enforce a resumed session to reuse the original cipher ?
  • nitass's avatar
    nitass
    Icon for Employee rankEmployee
    Jul 03, 2012
    But then it goes on to say that clients can only change to a cipher that has been enabled on the F5, which seems to suggest that attackers could still change the cipher and use it to attack the webserver session.

     

     

    So, do we have a vulnerability or not ?i understand the new cipher has to be allowed by f5 i.e. cipher setting in f5. so, if cipher is configured good enough, i think it could be fine.

     

     

    And, I suppose my original question is still valid - can the F5 enforce a resumed session to reuse the original cipher ?i never did but i think it could be possible. for the first connection, we can add ssl session id and cipher to table. and later when connection is resumed, we can drop connection if cipher does not match the one in the table.

     

     

    SSL::sessionid wiki

     

    https://devcentral.f5.com/wiki/iRules.SSL__sessionid.ashx

     

     

    SSL::cipher wiki

     

    https://devcentral.f5.com/wiki/iRules.SSL__cipher.ashx

     

     

    v10.1 - The table Command by Spark

     

    https://devcentral.f5.com/Tutorials/TechTips/tabid/63/articleType/ArticleView/articleId/2375/v101--The-table-Command--The-Basics.aspx

     

     

    anyway, if you do not allow ssl resume, you can disable cache size.

     

     

    sol6767: Overview of the BIG-IP SSL session cache profile settings

     

    http://support.f5.com/kb/en-us/solutions/public/6000/700/sol6767.html
  • Dave_Burnett_20's avatar
    Dave_Burnett_20
    Icon for Nimbostratus rankNimbostratus
    Jul 03, 2012
    If I'm reading you correctly you're saying that the enforcement of using the origional cipher is possible by a combination of i-rules?

     

     

    This is an area I'm not too familiar with as we've not used them very extensively at all in our current LTM/ASM setup.

     

     

    Looking at the links you've kindly provided it appears that on the initial https connection we should add the cipher version ( SSL::cipher version ) to the session table so that it links to the session ID. Is that correct ? However, I'm brave enough to admit I wouldn't know the full i-rule to write to achieve this.

     

     

    Then I think you're saying that, should the connection be resumed (but how would you know it had been resumed, does it use the same session ID ?) you would write an i-rule to examine the cipher version of the resumed connection and compare it to the original. If the ciphers were different the connection woul be dropped. Again, I wouldn't know how to begin writing that i-rule !

     

     

    Thanks for your help so far. I wouldn't blame you if you walked away now ! but if you're an i-rule expert and know the syntax required I'd be most grateful for further assistance.
  • nitass's avatar
    nitass
    Icon for Employee rankEmployee
    Jul 03, 2012
    i am not an expert. anyway, it is fun to write irule, so i never mind to do it if i can. however, in some case, it is difficult or i am not able to test it out. i prefer testing it before giving irule.

    e.g. 

    [root@ve10:Active] config  b virtual bar list
virtual bar {
   snat automap
   pool foo
   destination 172.28.19.79:443
   ip protocol 6
   rules myrule
   profiles {
      clientssl {
         clientside
      }
      http {}
      tcp {}
   }
}
[root@ve10:Active] config  b rule myrule list
rule myrule {
   when RULE_INIT {
   set static::tabletimeout 3600
}
when CLIENT_ACCEPTED {
   log local0. "[IP::client_addr]:[TCP::client_port] is connecting"
}
when CLIENTSSL_HANDSHAKE {
   set sid "[SSL::sessionid]"
   set cp "[SSL::cipher name]"
   log local0. "sessionid is $sid"
   log local0. "cipher is $cp"

   if {[table lookup $sid] ne ""} {
      if {[table lookup $sid] ne $cp} {
         log local0. "resume ssl session but cipher is different"
         reject
      }
      log local0. "resume ssl session and cipher is identical"
   } else {
      log local0. "new ssl session"
      table set $sid $cp $static::tabletimeout indefinite
   }
}
}

/var/log/ltm
Jul  3 23:31:03 local/tmm info tmm[5111]: Rule myrule : 192.168.206.55:51112 is connecting
Jul  3 23:31:03 local/tmm info tmm[5111]: Rule myrule : sessionid is 80f1024444a55cd8189cffe6ca7e7c18decbac0776a4c09e1b762accc8e86974
Jul  3 23:31:03 local/tmm info tmm[5111]: Rule myrule : cipher is RC4-SHA
Jul  3 23:31:03 local/tmm info tmm[5111]: Rule myrule : resume ssl session and cipher is identical