Forum Discussion
Robert_Roman_14
Nimbostratus
NimbostratusNew Cipher for TLS1.x Padding Vulnerability
Currently, we have our client ssl profile set with the following cipher string: !SSLv3:!SSLv2:ALL:!DH:!ADH:!EDH:!MD5:!EXPORT:!DES:@SPEED
We have been tasked by our infoSec department to correct the following vulnerability. TLS1.x padding vulnerability CVE-2014-8730. https://support.f5.com/kb/en-us/solutions/public/15000/800/sol15882.html. It wants us to set a new ssl profile called tls padding with a new cipher string of !SSLv3:RC4-SHA.
My question is this: Will this have any negative effects. Should i modify the original string above to add RC4-SHA to the string, or should I indeed create a new SSL profile. I would create the new profile and use clientssl as a parent profile.
Any help would be appreciated.
David_StoutI'm struggling to follow F5s logic in the referenced article. TLSv1.x is still available in the cipher string they recommend
tmm --clientciphers '!SSLv3:RC4-SHA' ID SUITE BITS PROT METHOD CIPHER MAC KEYX 0: 5 RC4-SHA 128 TLS1 Native RC4 SHA RSA 1: 5 RC4-SHA 128 TLS1.2 Native RC4 SHA RSAIf you take your original string you have this list of supported ciphers
tmm --clientciphers '!SSLv3:!SSLv2:ALL:!DH:!ADH:!EDH:!MD5:!EXPORT:!DES:@SPEED' ID SUITE BITS PROT METHOD CIPHER MAC KEYX 0: 5 RC4-SHA 128 TLS1 Native RC4 SHA RSA 1: 5 RC4-SHA 128 TLS1.2 Native RC4 SHA RSA 2: 47 AES128-SHA 128 TLS1 Native AES SHA RSA 3: 47 AES128-SHA 128 TLS1.2 Native AES SHA RSA 4: 47 AES128-SHA 128 DTLS1 Native AES SHA RSA 5: 53 AES256-SHA 256 TLS1 Native AES SHA RSA 6: 53 AES256-SHA 256 TLS1.2 Native AES SHA RSA 7: 53 AES256-SHA 256 DTLS1 Native AES SHA RSA 8: 10 DES-CBC3-SHA 192 TLS1 Native DES SHA RSA 9: 10 DES-CBC3-SHA 192 TLS1.2 Native DES SHA RSA 10: 10 DES-CBC3-SHA 192 DTLS1 Native DES SHA RSA 11: 60 AES128-SHA256 128 TLS1.2 Native AES SHA256 RSA 12: 61 AES256-SHA256 256 TLS1.2 Native AES SHA256 RSASo if you just simply add :!TLSv1 to your existing cipher string you get the following set of supported ciphers minus the TLSv1.x that is subject to the CVE article.
tmm --clientciphers '!SSLv3:!SSLv2:ALL:!DH:!ADH:!EDH:!MD5:!EXPORT:!DES:@SPEED:!TLSv1' ID SUITE BITS PROT METHOD CIPHER MAC KEYX 0: 5 RC4-SHA 128 TLS1.2 Native RC4 SHA RSA 1: 47 AES128-SHA 128 TLS1.2 Native AES SHA RSA 2: 47 AES128-SHA 128 DTLS1 Native AES SHA RSA 3: 53 AES256-SHA 256 TLS1.2 Native AES SHA RSA 4: 53 AES256-SHA 256 DTLS1 Native AES SHA RSA 5: 10 DES-CBC3-SHA 192 TLS1.2 Native DES SHA RSA 6: 10 DES-CBC3-SHA 192 DTLS1 Native DES SHA RSA 7: 60 AES128-SHA256 128 TLS1.2 Native AES SHA256 RSA 8: 61 AES256-SHA256 256 TLS1.2 Native AES SHA256 RSAOr am I missing something here ?
Brad_ParkerCirrus
The POODLE vulnerability is only for CBC ciphers. '!SSLv3:RC4-SHA' would result in only RC4 ciphers and exclude SSLv3 which will cover the POODLE vulnerability. The only other issue with this is RC4 is also consider to be weak and soon to be considered insecure. I would recommend upgrading whenever you can to 11.5+ to get access to newer and string cipher such as GCM.
The issue for CVE-2014-8730 is not that there is a problem with TLS1.x. Rather, there is a problem in the implementation of Padding when using block ciphers in CBC mode. That is why it is recommended to use RC4 which is stream cipher or only use block ciphers in GCM (Galois Counter Mode) which does not use CBC mode.
The best solution at the moment is to upgrade to a version where the padding issue is fixed. Currently 11.5.1 HF7, 11.4.1 HF7 (yes HF7) or 11.6.0 HF3, are the versions I would recommend. CVE-2014-8730 is fixed in these versions, then you will just need to disable SSLv3 for the configuration utility as suggested in SOL15702, in order to mitigate poodle.
