This week, I'm traveling to Vancouver, BC to attend the Apache Software
Foundation Conference. For several years, Sander Temme from Thales e-Security has given a talk called the "TLS State of the Union", and this year is no exception[3]. (I also happen to be speaking on Monitoring[1] and Security[2]. If you are attending, come say "hi"!). I suspect one of his topics this year will be "SSL Drown", and I'm curious as to how he will present it, because on the one hand it's kind of a big deal, and on the other, it shouldn't really have been a problem for anyone *at all*.

[Quick Network Security Catch-up Guide: SSL stands for Secure Sockets
Layer and is the cryptographic software that protects your communications with secure web and email services. TLS - Transport Layer Security - is the more modern name.]

SSL Drown[4] is an attack that can be used against a server using an outdated protocol known as SSLv2. It is one of the latest attacks to be given a scary name that news outlets love to publicize. Nobody wants to talk about CVE-2016-0800, but "Drown Attack" gets people's attention, even outside of the network security world.

The big issue with the SSL Drown attack is that, while it is "only" an attack against an outdated protocol, it can be used to attack communications using *new* more-secure protocols like the latest-and-greatest TLSv1.2. That's what makes this vulnerability a Really Big Deal: it can make secure protocols insecure merely by its
presence.

The SSLv2 protocol was declared insecure and dead way back in 1996 and immediately replaced with SSLv3. Since 1996, 3 new protocols have been
introduced (TLSv1, TLSv1.1, and TLSv1.2), SSLv3 itself has been declared
unsafe, and it's starting to look like TLSv1's days are numbered for the truly security-conscious. The attack described in the SSL Drown announcement is mostly just a re-publication of work done in 1998 by Daniel Bleichenbacher at Bell Labs[5], with the added detail that newer-protocol connections (that didn't really exist way back in the 1990s) can be broken by attacking SSLv2 on the same server, then using the results of that attack to listen-in on the TLS conversations.

So an attack against SSLv2 announced in 2016 shouldn't have been a big deal, right? Nobody should have been using SSLv2 since 1996 and security-conscious IT workers in high-security fields -- such as health care -- should have already been phasing-out SSLv3 by March 2016 when SSL Drown was announced. So why is SSL Drown actually relevant to anyone but services who died out back in the late 1990s?

Well, it turns out that a shocking number of web and email servers in both protected (internal) networks and on the open Internet were still running SSLv2 for some reason. Any reasonable security audit should have have identified this old, insecure protocol and recommended that it be disabled immediately. There is simply no reason anyone would need to have this protocol enabled. Recent versions of various SSL/TLS implementations such as OpenSSL actually require you to recompile the entire stack in order to support SSLv2. Other implementations are expected to be used in a large number of use-cases, and therefore need
SSLv2 to remain supported.

We recently discovered a service that had this protocol enabled, and the owners were at a loss to explain how the oversight had occurred. The situation was quickly corrected (it's an easy configuration change, and will cause zero disruption to legitimate clients) but who knows how long their service was vulnerable to this particular attack? The solution is constant monitoring for insecure configurations of this nature. That monitoring needs to be kept up-to-date with industry best practices to make sure that you are testing for the right things.

The good news is that it's quite easy to test your TLS configuration against those industry best practices. There's even a publicly-available tool that you can point at your web service and it will tell you everything it can about your service, and give you a letter-grade. The service is Qualys's SSL Labs SSL Server Test.[6] Just enter your URL and it will scan your service the configuration problems. It only takes a minute or two, and won't interrupt any clients or services you have
running. You can even request that your results not be publicly-posted on their leader-board.

If it identifies any problems in your configuration, talk to your IT administrators about those issues and try to get them fixed. Or if you are an IT administrator and aren't sure how to fix those configuration errors, contact someone you trust to give you some help.

So, go scan your web server. Yes, *you*.

The answer to most security problems is "constant vigilance", and SSL Drown is no exception. If more IT administrators used tools like the SSL Server Test, SSL Drown would have been a non-story. I would love it if most network-security attack issues were non-stories like this, where only some super-small segment of the Internet were at risk.
"
CHADIS is a unique screening, decision support and patient engagement system designed to streamline and optimize healthcare by providing Clinicians with evidence-based data that improves diagnosis and management of health, emotional, developmental and behavioral concerns. CHADIS is the only IT company that has been designated as a “portfolio sponsor” by the American Board of Pediatrics for their Maintenance of Certification program.
[1] http://apachecon2016.sched.org/event/6OIt
[2] http://apachecon2016.sched.org/event/6OIs
[3] http://apachecon2016.sched.org/event/6OJV
[4] https://drownattack.com/
[5] https://en.wikipedia.org/wiki/Adaptive_chosen-ciphertext_attack
[6] https://www.ssllabs.com/ssltest/