Since it’s been about 3 months since POODLE, we’re clearly overdue for another major vulnerability in SSL and/or TLS. Fortunately for us, the research team at SmackTLS has released details of the FREAK attack (aka OpenSSL CVE-2015-0204). We can test whether our browsers are vulnerable here, and we can read cryptographer Matthew D. Green’s excellent summary of the attack mechanism on his blog. Once we’ve digested that and had a good laugh at the irony of the NSA getting hoisted by its own petard, we need to move on to how to mitigate the vulnerability in our infrastructures.
To be clear, this vulnerability is on the client side. So, for the most part BIG-IP (appliance, chassis, or virtual) isn’t vulnerable, since the main mode of operation for BIG-IP is for SSL/TLS termination, i.e. as the server. SOL16139 provides a summary of how and where BIG-IP is vulnerable, which is primarily on the Server SSL profile only when COMPAT cipher string is used. These findings are good news for two reasons:
The COMPAT cipher string is not configured by default (DEFAULT is).
The server side of the connection typically isn’t open to the Internet or other untrusted networks.
F5 intends to patch this vulnerability in our next major release later this year, since the severity is not deemed critical for BIG-IP.
As BIG-IP administrators, we may be breathing a sigh of relief. However, one of the key components of this vulnerability is that the server must present export ciphers in order for a vulnerable client to be exploited. As Mr. Green notes in his blog post linked above, these weak ciphers should have been deprecated long ago. Unfortunately, with the help of Ivan Ristic at SSL Labs, they’ve found an alarming percentage of web sites are still negotiating these weak export-level ciphers. As responsible citizens of the Internet, it’s important that we review our SSL profiles and ensure that the aforementioned COMPAT cipher string that enables weak export ciphers isn’t in use on any of the Client SSL profiles. This configuration change is easy to implement, and won’t impact compatibility of even the most antiquated browser (looking at you, IE6). Uploading your Qkview snapshot to iHealth.f5.com will also enable us to see, at a glance, if COMPAT is enabled anywhere.
The other vulnerability, as per the SOL, is with HTTPS monitors, but:
1. Monitors are almost always exclusively used on the private network, isolated from the public.
2. If someone is in position to MITM your monitor traffic, and they go through all of the effort to do so, they'll manage to obtain decrypted - monitor traffic. It is exceedingly rare that someone would have sensitive data in their HTTPS monitors. So they have the export RSA key - but the management plane isn't normally opening connections that could be MITM'd, except for monitors.
And if the servers being monitored are patched to not support export RSA ciphers, then the MITM won't work to start with. So patch those servers.
There is a mitigation in the SOL (-kRSA), but the user has to decide if it is really necessary.
About sol16139,
I thing removing the RSA key exchange cipher for HTTPS monitor is difficult solution for many production site.
Because many servers may only accept RSA key exchange only.
And I know some users started to use HTTPS monitor over internet, as BIG-IP is located on internet (Virtual Edition on AWS), I think this vulnerability should be treated as higher priority shouldn't it?
I think getting big IPs is a bit difficult process as per the professional of Custom Writing Services because they have also tried their best to get such IPs but i think they were not able to get it.
