The DROWN Attack: Another SSL Vulnerability

We all know that SSLv2 is supremely broken and not recommended for use on any network, but (surprisingly or not) it's still being used on many web servers today.  One of the reasons it's used is that many servers offer a wide array of encryption protocols in order to cater to the wide array of browsers being used by all the Internet users out there.  After all, if a user wants to visit a website using a browser from 10 years ago, some websites want to cater to that and still let him in.  So whether an oversight on the part of the web server administrator or a business decision to still allow old security protocols, the fact remains that the old and broken SSLv2 is still widely deployed today.  

OpenSSL just released an update that allows for a "Man-in-the-Middle" attack on any webserver using the old SSLv2. The vulnerability allows an attacker to decrypt an intercepted connection by repeatedly using SSLv2 to make connections to a server. In the process, the attacker learns a few bits of information about the encryption key each time.  Ultimately, the attacker can learn the encryption key and use it to decrypt anything the user sends to the webserver.

Fear not, however, if you are currently offloading your SSL on the BIG-IP. By utilizing the default configuration in your BIG-IP SSL profile, your applications are not vulnerable. The only two situations your applications might be vulnerable in the data path are:

  • You are passing SSL through the BIG-IP to your application servers and NOT offloading. If this is your situation, there is an iRule mitigation you can implement that was developed for the POODLE attack that will also defend in this case.
  • You have enabled the COMPAT ciphers in your SSL profile. See David's notes below in the comments for more details.

For BIG-IP version 12.0, the COMPAT cipher string for SSL profile on the data plane won't expose the issue unless you explicitly use the COMPAT cipher string with SSLv2 enabled (“COMPAT+SSLV2”) because this configuration enables SSLv2 only.  I'm not sure why anyone would ever use this configuration, but in an effort to provide full disclosure, I wanted to share that it's an available option...and I highly discourage anyone from using it!  

For BIG-IP versions 10.1.0 thru 10.2.2, the cipher string “ALL” in addition to “COMPAT” will expose the issue because SSLv2 was included in both groupings in those older versions.  Also, the SSL profile includes an option called “NO SSLv2” which can be used to disable the protocol at the profile level.

OpenSSL has already released a new version to address this vulnerability, so get out there and implement the new version if you are one of the vulnerable webservers.  Better, though, is to completely remove SSLv2 from the options your webserver offers when serving up security protocols.

Check back here for more updates as other information on this attack becomes available.

Related Resources:

Published Mar 01, 2016
Version 1.0

Was this article helpful?

5 Comments

  • if you don't offload you can still block the ssl v3 and less connection attempts w/ an iRule: https://devcentral.f5.com/s/articles/irule-to-stop-sslv3-connections
  • It is important to note that it *is* possible to configure a BIG-IP to negotiate SSLv2. On all currently supported versions (and indeed even for all versions > 9.0) SSLv2 has not been in the DEFAULT or NATIVE cipher suites. However, up through v11 the product is distributed with a COMPAT suite of ciphers which include SSLv2. Customers who are concerned about this can examine their clientssl profiles to ensure that they do not include the COMPAT or COMPAT+EXP ciphers. If they need assistance determining if their cipher string includes these weak protocols they can use the secret decoder ring starting on page 8 of the SSL Everywhere Recommended Practices Guide: (https://f5.com/Portals/1/Premium/Architectures/RA-SSL-Everywhere-deployment-guide.pdf) To determine which ciphers are available by version, reference these SOLs v10: SOL 11444 (https://support.f5.com/kb/en-us/solutions/public/11000/400/sol11444.html) v11-12: SOL 13163 (https://support.f5.com/kb/en-us/solutions/public/13000/100/sol13163.html) -dave
  • Officially, it is being revised this failure. No official patch is available, I received the information directly from a case I opened F5. As a workaround you can disable SSLv2, here I am in version 11.6 and is feasible this setting
  • If you want to manually test a web server you can do so with NMap (nmap --script sslv2 -p ) or s_client (openssl s_client -ssl2 -connect :)
  • previous comment did not like my syntax.. NMAP: nmap --script sslv2 -p port-or-portlist ip-address-or-CIDR-block Sclient: openssl s_client -ssl2 -connect ip-or-hostname:443