Forum Discussion
squip_86995
Nimbostratus
NimbostratusOpenSSL and Heart Bleed Vuln
Get the latest updates on how F5 mitigates Heartbleed
Hi Team,
I know this question is eventually going to be asked - I may as well do it.
With the news today about the Heartbleed OpenSSL Vulnerability (http://heartbleed.com) I wanted to confirm if we are at any risk. All of my LTM V11 and V10 instances are running OpenSSL 0.9.8x which does not appear to be a vulnerable version of OpenSSL... Does the F5 hook into this when we Sign/Request SSL Certs? If so we're sitting pretty, right?
Thanks.
Updates based on feedback:
ul
Update 2: F5 have published a security advisory on this issue - http://support.f5.com/kb/en-us/solutions/public/15000/100/sol15159.html
Simon_Waters_13Cirrostratus
Okay still struggling to get my head around this.
We use 11.4.2 HF2.
We get connections using TLS 1.2 (and some old) using a bespoke set of ciphers including "NATIVE"
I assume the TLS 1.2 connection must be using the NATIVE code, but that we may fall back to older ciphers, and that since the SSL library mod_ssl.so depends on is libssl.so.0.9.8 (readelf -d mod_ssl.so) then this F5 pair are not affected, but that people with 11.5 may be. And I nearly upgraded BECAUSE of the better SSL cipher support in 11.5......
What_Lies_Bene1Seems you are not.
I'd like some clarity around the compat, native mixed cipher strings myself. I assume worse case and that if a compat cipher is specified in the cipher string then regardless of whether a native cipher is actually negotiated and used everything drops down to OpenSSL. Perhaps that's not the case.
tmm --clientciphers NATIVEwill give you the list of the NATIVE ssl ciphers on your bigip Version. For all ciphers that appear on that list, you're not using openssl.
Also, the only BigIP version that is using a vulerable openssl in the wild is v11.5.0.
- What_Lies_Bene1I'm not convinced that's the case when using a mixed cipher string. OpenSSL supports the native ciphers too. I'll try and do some testing and see what I find. You're correct that only v11.5 is vulnerable. As noted earlier, the management GUI is also vulnerable but again only on v11.5.
It's quite possible to work this out logically: Ref: http://support.f5.com/kb/en-us/solutions/public/13000/100/sol13163.html
-
There are ciphers which exist in Native but not in Compat.
-
YOu can specify "NATIVE:COMPAT" as a cipher string
-
Therefore, the stack used depends on which cipher is in use, with the natural preference being for NATIVE.
- Tested this just now on 11.2.1 using "NATIVE:COMPAT" as my cipher string on ssl profile. I can connect just fine using ciphers that are only present in NATIVE, and I can do the same using ciphers only present in COMPAT list. So that should confirm that the stack used is decided on a per-connection basis.
- One thing I find curious though, is that if I run "openssl ciphers" on my machine, I get a longer list of ciphers than is listed in Sol13163 in the compat list for my version (11.2.1).
- What_Lies_Bene1Yes, OpenSSL supports ALL the NATIVE ciphers as well as the compat ones but obviously those ciphers are handled by TMM and the offload hardware. Your test isn't definitive unless you check the stats and confirm that your connection shows as native, not compat.
-
ltm profile client-ssl ciphertest { app-service none ciphers NATIVE:COMPAT defaults-from clientssl } ----------------------------------------------------------------- Ltm::ClientSSL Profile: ciphertest ----------------------------------------------------------------- Virtual Server Name N/A Bytes Inbound Outbound Encrypted 1.7K 4.7K Decrypted 0 0 Connections Open Maximum Total Native 0 2 3 Compatibility 0 1 1 Total 0 2 4- What_Lies_Bene1Excellent, thank you. That proves it! :-)
- HR_38560
so is 11.5.0 safe or do we need to update?
- What_Lies_Bene1There is no update. v11.5 is vulnerable to this issue in two respects: 1) Where the Management Web GUI is concerned and 2) If any of your SSL Profiles contain cipher strings which contain compat ciphers but only if the client negotiates a compat cipher (which a hacker clearly would ensure happens).
- HR_38560oke waiting for a update then, had an upgrade scheduled for 11.5, but actually our 10.2.4 version is actually safer then :D
- I'm not a security expert, so you may want to verify this independently: 1. The Native Stack on the Bigip v11.5.0 is not vulnerable. 2. You can force use of the native stack by specifying "NATIVE" as your cipher suites list on your SSL profiles. On 11.5, there is a long list of ciphers supported by NATIVE, so this should not cause any significant loss of options for connecting clients.
Dale_19172I'm particularly interested in whether Virtual Edition is vulnerable, as it does not have recourse to the Cavium offload.
THiThis discussion seems to be around BIG-IP hw appliances with offloading ssl acceleration to Cavium card. What about Virtual Editions, they do all offload on sw - are they vulnerable?
- I think, but haven't confirmed, that the platform is irrelevant. The NATIVE stack provides an API that offloads to hardware when it is available, but will always do what you ask of it, falling back to software if no hardware is present. The same thing happens with TCP Segment Offload. The TSO subsystem will always transmit your packets, whether or not there is physical hardware available to offload the packet processing.
A solution article has just been released regarding this issue.
http://support.f5.com/kb/en-us/solutions/public/15000/100/sol15159.html
