Apology from the Writer: Excuse the kitschy title image, but it really seems like everyone already thinks of SSL as little locks on the intertubes, so I really just had to go along with it!
Public disclosure of the DROWN attack is a little over a week old now, but for the end user it can be a *little* unclear just what versions of OpenSSL are truly vulnerable and which are not. Reading the official openssl security release for March 1st, it can be easy to miss which versions of openssl are critically crippled, and which are not. This is partly because there are actually TWO related and serious security advisories in effect as of March 1st. One is for CVE-2016-0703, and the other is for CVE-2016-0800; only the latter is actually DROWN, but the former substantially compounds the effectiveness of DROWN for crypto n’eer-do-wells.
If your version if openssl is earlier than 1.0.1m or 1.0.2a, abandon ship! Unless your distro applied patchsets (like Ubuntu, RedHat and a few others) this version really does need to be updated –CVE-2016-0703 affects these versions. If your version of openssl is earlier that 1.0.1s or 1.0.2g, (but at least as new as 1.0.1m or 1.0.2a) then saying it is vulnerable to DROWN isn’t *quite* the whole story. Unpatched versions in this range are only vulnerable when applications do not have SSLv2 and SSLv3 disabled, which allow cryptographically insecure “export ciphers” (you can thank the US gov’t for these!) to be used.
NetBSD 6/7 ship with a base OpenSSL install that falls into this latter category. I only became aware of the issue after consulting a test site to test my Apache install. While upgrading to 1.0.1s/1.0.2g would be the best solution, all that was needed for me was adding a line to disable SSLv2 and v3 in my apache config (and this preventing export ciphers):
SSLProtocol all -SSLv2 -SSLv3
…and that should be enough to keep your server from DROWNing! Just make sure to disable SSLv2/3 on all services on your boxes.