New Cipher for TLS1.x Padding Vulnerability

I'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    RSA 

If 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 RSA  

So 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 RSA   

Or am I missing something here ?

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.