SSL Session Ciphers

is this relevant?

 

 

sol12543: OpenSSL vulnerability CVE-2010-4180

 

http://support.f5.com/kb/en-us/solutions/public/12000/500/sol12543

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 ?

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

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.

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

Wow. Thanks for this.

 

 

If we decide to implement I'll let you know how we go on.