CVE-2014-8730 Padding issue

[Jeff_Costlow_10]

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.

[LyonsG_85618]

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_Maher]

So is it ok to use AES-265-SHA and AES-128-SHA?

[brad_11480]

So 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_11480]

my 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?

[Jeff_Costlow_10]

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?

[JoshBecigneul]

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?

[goutham]

Hello 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..

[Arie]

At least one of the cloud-based services that connect to our systems seems choke on the custom cipher. Do your regression testing...

[Jeff_Costlow_10]

arai.a: Correct, This issue does not affect the management GUI. goutham: Your proposed cipher string of "RC4-SHA" would avoid this issue as well as SSLv3 POODLE. However, RC4 has known weaknesses and should not be a long term solution. I would suggest patching when possible. Josh: Disabling ADH ciphers is probably not a problem for anyone; ADH is rarely used. I agree with your conclusion that AES-GCM may be restrictive until more browsers have been updated.

[jba3126]

LyonsG - It's because you are still allowing the CBC Ciphers with that string. Depending on your version of OS (mine 10.2.4) you are still allowing the CBC ciphers: tmm --clientciphers 'RC4-SHA:HIGH:MEDIUM:!SSLv2:!SSLv3:!ADH' 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: 53 AES256-SHA 256 TLS1 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 Native DES SHA RSA 6: 10 DES-CBC3-SHA 192 TLS1.2 Native DES SHA RSA 7: 10 DES-CBC3-SHA 192 DTLS1 Native DES SHA RSA 8: 61 AES256-SHA256 256 TLS1.2 Native AES SHA256 RSA 9: 4 RC4-MD5 128 TLS1 Native RC4 MD5 RSA 10: 4 RC4-MD5 128 TLS1.2 Native RC4 MD5 RSA 11: 47 AES128-SHA 128 TLS1 Native AES SHA RSA 12: 47 AES128-SHA 128 TLS1.2 Native AES SHA RSA 13: 47 AES128-SHA 128 DTLS1 Native AES SHA RSA 14: 60 AES128-SHA256 128 TLS1.2 Native AES SHA256 RSA

[kridsana]

Is RC4-SHA support all of browser ? We can't upgrade now but not sure if change cipher to RC4-SHA will work without fail. (Not concern about RC4 weakness)

[kridsana]

From ssllab result, It's seem RC4-SHA not support with IE6/xp. And Did some browser like firefox or chrome with older version support RC4-SHA?

[Cyril_M]

Hi, why is there still no patch for the v11.3 whereas they are available for v11.2.1 and v11.4.0 ? What's wrong with this version ? :) https://support.f5.com/kb/en-us/solutions/public/15000/800/sol15882.html Thanks

[brad_11480]

upgraded the systems to the HF6 as recommended. Now TMM keeps restarting on the standby system. Others experiencing similar? Support isn't providing too much information but I'm understanding that others may have a similar problem with HF6.

[Chris_G_01_1415]

Brad, We are running HF6 and not having any issues at all

[RobertS1]

Dont use 11.4.1 HF6 or 11.5.1 HF6 if you use APM. There is a critical bug in HF6 involving APM. If you use HF6 and APM contact support they should be able to give you an engineering hotfix. Or wait for an update should be soon within a week.

[Michael_Voight_]

11.3.0 is End Of Software Development This means there will be no standard hotfix (Reference Solution 5903 at ask5.com) for more info. There are engineering hotfixes that are built that have the fix.

[MWat0815_185830]

If we can't apply a patch which f5 provided, is invalidating CBC mode effective against this vulnerability?