First, let's just agree that supporting SSLv3 is no longer a good idea, and that all old versions of SSL should be disabled by default. In fact, if I could add one item to the Top 10 Hardcore Security Features in 11.5, it would be SSLv3 being disabled by default in the Client SSL profile: SOL15022 - SSLv3 protocol is disabled in the DEFAULT SSL ciphers. This change in behavior is very safe from a browser support perspective, especially with IE6 seeing the last nails in its coffin. Wikipedia has a nice entry on the broad browser support for TLS 1.0, and the rapidly growing support of TLS 1.1 and 1.2.
The death of IE6 and the rapid growth of browser-share for both Google Chrome and Mozilla FireFox, which are auto-updating, bodes well for TLS 1.1 and 1.2. Many reports estimate Chrome and FireFox combined for between 60-80% browser share in 2013, with Chrome leading the way at 40-60%. IE8-10 still have some significant presence, but TLS 1.1 and 1.2 support is easily turned on in these browsers, though this might increase customer support call volume a bit. (Citations: 1, 2, 3)
So, BIG-IP is an excellent platform for enforcing good transport encryption of your application. Via the Client SSL profile, it's fairly easy to set the certificate and key, the supported ciphers, and even SSL/TLS versions supported. A well-covered topic on DevCentral, the TLS handshake itself subject to many attacks, such as BEAST, CRIME/BREACH. and Lucky 13 to name only a few. Our good friend David Holmes wrote up a nice post awhile back on "Getting Good Grades on your SSL", and referenced the great tool available on SSLLabs.com, called Pulse. SSL Labs also has a detailed paper on TLS Best Practices that's a primary reference for the BIG-IP configurations that will help you shine in your next Pulse report. You may also want to check out the good work our friends at OWASP are doing with their TLS Protection Cheat Sheet.
So, let's get to work on improving that report card from Pulse. First, you'll want to make sure you've got a handle on SOL10167 and SOL8802, which cover the Client SSL Profile and configuring cipher strength, respectively. Attack-by-attack, we'll cover some settings that will help you mitigate via BIG-IP:
Renegotiation attacks: When this attack vector against SSL 3.0 and all versions of TLS was first published in August 2009, there seemed to be no immediate remediation, but a 2-line iRule disabling Renegotiation provided an immediate fix for any F5 administrator. Subsequent versions of TMOS since v10.1.0 have added a checkbox to disable renegotiation altogether, however, disabling renegotiation introduces some other security problems and incompatibility with client certificates. RFC5746 for secure renegotiation has since been proposed, and is implemented in TMOS since v10.2.3. All modern browsers support secure renegotiation, but in order to support any older browsers, choose the "Require" option to accept initial handshakes only from those unpatched clients.
CRIME, BEAST, TIME, and Lucky 13: Fortunately for me, all the heavy-lifting has been done by our own Jeff Costlow, and I encourage you to review his excellent post on TLS from last year.
Summary of recommendations:
Disable SSLv2 and SSLv3 (No SSLv2, No SSLv3 in Client SSL profile).
Disable TLSv1.0 (No TLS 1.0) if you are concerned about BEAST, but beware possible browser support issues.
Require Secure Renegotiation
Use a cipher string a little stronger than the DEFAULT, for example:
Updated the cipher string in the article to something a bit better:
"!SSLv2:!EXPORT:DHE+AES-GCM:DHE+AES:DHE+3DES:RSA+AES-GCM:RSA+AES:RSA+3DES:ECDHE+AES-GCM:ECDHE+AES:ECDHE+3DES:-MD5:-SSLv3:-RC4"
@Jonathan, it appears that the DHE ciphers are being negotiated instead of ECDHE, and capping your grade due to DH 1024 parameter-length. What version of TMOS are you running?
Jonathan, take another look at the updated cipher string in the article above, which moves ECDHE to the front of the order, ahead of DHE. That should solve your primary problem.
