If a server advertises anonymous elliptic curve Diffie-Hellman ciphers, a malicious client could crash the server. F5 BIG-IP does not support anonymous ECDH ciphers on the management interface nor for dataplane traffic so we are not vulnerable. We have created ID465805 to track this vulnerability.
SSL_MODE_RELEASE_BUFFERS is a special flag that will treat OpenSSL memory slightly differently. F5 does not use this flag and are not vulnerable to this issue. We have created ID465804 for tracking purposes.
This is where it gets fun. DTLS is rather new, but is essentially TLS over UDP instead of TCP.
This flaw happens when a server sends a malicious handshake message to a client. BIG-IP does not by default contain any DTLS clients and is not vulnerable. If you are using BIG-IP as a DTLS client, F5 will be patching all older releases over time. ID465803 has been created.
This is a great vulnerability. It’s got a lot of complicated elements and it’s not intuitive.
We have to first start with a man in the middle of our infant TLS connection. The attack happens before the server certificate has been checked and the attacker never tries to impersonate the server so the users’ browser will not even pop up a warning for a bad certificate.
The MITM watches as the client sends his CLIENT_HELLO message. He passes that unmodified to the server.
At this point, the MITM sends a Change Cipher Spec message to both the client and the server. This is a simple message that tells the server and the client that all new messages should use a new cipher. This message usually happens after a renegotiation
Sending a CCS message during the handshake is forbidden by the protocol, but OpenSSL has ignored it since OpenSSL 0.9.8.
New code was introduced into OpenSSL 1.0.1 to lock the TLS pre-master secret when a CCS message is received. This pre-master secret is used to generate the session key. It should be decided randomly later in the handshake.
Since the pre-master secret is now set at a predictable value, the MITM can guess the session key. He can continue passing all further messages between the client and the server, but since he has the session key, all traffic can be decrypted or even modified.
OpenSSL fixed the problem in OpenSSL 1.0.1h by dropping the connection when an early CCS message is received.
The only way to be vulnerable to CVE-2014-0224 is to have an OpenSSL 1.0.1 server and an OpenSSL 0.9.8 or higher client.
BIG-IP 11.5.0 and 11.5.1 use OpenSSL 1.0.1 for the management interface, so we are vulnerable. We are tracking this with ID 465799 and will be releasing a patch shortly. For now, you should ensure your management interface is isolated to a private network. We will be releasing fixes for all supported BIG-IP versions over time to patch the vulnerable clients that may be on the BIG-IP.
However, there is good news. Dataplane virtual severs configured to use TLS termination are not vulnerable to this attack (unless you are using COMPAT ciphers; not the default). BIG-IP queues the CCS message and does not set the pre-master secret like OpenSSL.
If you are using straight TCP virtual servers, then the attack will be passed through directly to your SSL servers. You could use a variant of the heartbleed mitigation iRule to stop early CCS messages. My team hasn’t written this iRule yet; it only needs to watch for a CCS message before the initial handshake is completed. If it occurs, the connection should be dropped. This is how patched OpenSSL operates.
I must point out there are some tools in existence that incorrectly claim that BIG-IP TLS virtual servers are vulnerable. The tools merely send a client HELLO message and then immediately send a CCS message. If the server does not shut down the connection, then the tool claims the server is vulnerable.
Even though we are not vulnerable, F5 plans to change our behavior to match OpenSSL. This is currently being tracked as ID465908 and will be released in hotfixes over time.
The OpenSSL saga keeps going. Heartbleed has put a lot of scrutiny on the code.
F5 will continue to watch for vulnerable code and patch as needed.
I hope you enjoyed this deep dive into the latest OpenSSL vulnerabilities.