CVE-2014-8730 Padding issue
Incorrect TLS padding could be accepted when terminating TLS 1.x CBC cipher connections. F5 has fetched CVE-2014-8730 for this issue.
This issue does not affect the management interface, only the traffic interfaces and does affect all released versions of BIG-IP except the latest version, 11.6.0.
Customers should upgrade to hotfixed releases. See the F5 solution article for this issue for more information.
If you cannot upgrade, then we advise using TLSv1.2 with AES-GCM ciphers (requires BIG-IP v11.5.0 or later and recent clients).
If you cannot upgrade and cannot use AES-GCM ciphers, then we recommend using RC4 ciphers until you can upgrade.
See this solution for more information on setting TLS cipher strings.
Published Dec 08, 2014
Version 1.0
LyonsG_85618Cirrostratus
Jeff - we currently use the following cipher settings: RC4-SHA:HIGH:MEDIUM:!SSLv2:!SSLv3:!ADH However according to https://www.ssllabs.com/ssltest/ we are still showing as vulerable. Any ideas why this woudl be?
Mike_MaherNimbostratus
So is it ok to use AES-265-SHA and AES-128-SHA?- brad_11480So I added this string to our existing cipher string. It still grades us as "F". Rather than the two POODLE attack marks-- SSL 3 and TLS, now it only shows the TLS. I expected that one to go away and end up with the SSL 3, whose grade is capped at "C". The string I set is: 'ALL:!ADH:!LOW:!EXP:!NULL:RC4+RSA:+HIGH:+MEDIUM:!SSLV3:RC4-SHA'
- brad_11480my bad MY [long] cipher string was allowing other ciphers.. Using the recommended 'patch' of the !SSLV3:RC4-SHA on version 11.4.1 leaves me with no SSLv3 and 3 ciphers for TLS1, 1.1, 1.2 RC4-SHA. What client issues will I end up running into?
- AES-128-SHA and AES-256-SHA are both CBC ciphers and are susceptible to this issue. RC4-SHA is recommended over AES-CBC ciphers until you patch. SSLLabs is looking for CBC ciphers. On my BIG-IP 11.6.0, the cipher string "RC4-SHA:HIGH:MEDIUM:!SSLv2:!SSLv3:!ADH:-AES:-MD5" removes the vulnerable AES-CBC ciphers and correctly leaves the AES-GCM ciphers. You can use tmm --clientciphers to see the accepted ciphers. See solution 15194 https://support.f5.com/kb/en-us/solutions/public/15000/100/sol15194.html
arai_a_5902> This issue does not affect the management interface, I don't understand why you say this, Do you say management access (GUI) isn't affected by this?- I did some testing tonight and the cipher string provided in sol15882 results in an F at SSL Labs' testing site, due to ciphers using ADH key exchange. I'm not an expert, so I am not certain how risky having this enabled is. Disabling anonymous Diffie-Hellman (ADH) key exchange bumps the score from a F to a B, using "!ADH:!SSLv3:AES-GCM:RC4-SHA". Using RC4 caps the score at B. Disabling RC4 results in an A rating, but it's likely that a majority of users won't be able to access your site.
- arai_a_5902> This issue does not affect the management interface, I don't understand why you say this, Do you say management access (GUI) isn't affected by this?
gouthamHello jeff, I am running 11.4.0 HF5..can I just address the padding issue by removing !SSLv3 from the cpher string "!SSLv3:RC4-SHA"?? what I meant to say is I dont want to disable SSLv3 and at the same time I want to address the new padding (TLS1.x) issue..
ArieAltostratus
At least one of the cloud-based services that connect to our systems seems choke on the custom cipher. Do your regression testing...
