A new OpenSSL vulnerability (CVE-2016-0800), called DROWN, was recently announced. It affects older versions of several widely used server technologies:
- SSLv2, an old version of the Secure Sockets Layer protocol. Most up‑to‑date websites don’t use Secure Sockets Layer (SSL) at all, having moved to Transport Layer Security (TLS).
- IIS v7, an older version of Microsoft Internet Information Services
- NSS 3.13 (Network Security Services), a widely used cryptographic library
The DROWN vulnerability is described on a dedicated website, The DROWN Attack. DROWN stands for Decrypting RSA with Obsolete and Weakened eNcryption, and makes vulnerable websites susceptible to man‑in‑the‑middle attacks.
DROWN is unusual in that it does not require a site to actively use SSLv2 or other vulnerable protocols. A site is vulnerable if it supports one of the vulnerable protocols or shares a private key with any other server that allows SSLv2 connections.
Both NGINX Open Source and NGINX Plus support SSLv2, but it is turned off by default in all versions since NGINX 0.8.19 (released in October 2009). Only users who have explicitly turned on SSLv2, or use an NGINX version earlier than 0.8.19, or share a private key with another server that allows SSLv2 connections, are vulnerable to this attack.
Site owners should check whether their website configuration supports SSLv2 and disable it if it does. With NGINX and NGINX Plus, the use of SSL and TLS protocols is controlled by the ssl_protocols configuration directive. In order to enable recent TLS only, and disable SSL v2 and SSL v3, use the following syntax:
Please see the reference documentation on SSL/TLS support with NGINX.
For more information about the DROWN attack and NGINX Open Source, send email to nginx@nginx.org. You can also subscribe to the mailing lists.
NGINX Plus users can contact NGINX Support.
Visit the following sites for more information:
- The security advisory for DROWN from OpenSSL.org
- A detailed description of DROWN on ZDNet
- The DROWN Attack dedicated website
If you’re updating your NGINX configuration, or if you’re looking to improve application performance for your secure website, consider upgrading to HTTP/2. You can learn about the benefits in our recent HTTP/2 blog post and HTTP/2 white paper.
Image courtesy The Drown Attack.
About the Author
Related Blog Posts
Secure Your API Gateway with NGINX App Protect WAF
As monoliths move to microservices, applications are developed faster than ever. Speed is necessary to stay competitive and APIs sit at the front of these rapid modernization efforts. But the popularity of APIs for application modernization has significant implications for app security.
How Do I Choose? API Gateway vs. Ingress Controller vs. Service Mesh
When you need an API gateway in Kubernetes, how do you choose among API gateway vs. Ingress controller vs. service mesh? We guide you through the decision, with sample scenarios for north-south and east-west API traffic, plus use cases where an API gateway is the right tool.
Deploying NGINX as an API Gateway, Part 2: Protecting Backend Services
In the second post in our API gateway series, Liam shows you how to batten down the hatches on your API services. You can use rate limiting, access restrictions, request size limits, and request body validation to frustrate illegitimate or overly burdensome requests.
New Joomla Exploit CVE-2015-8562
Read about the new zero day exploit in Joomla and see the NGINX configuration for how to apply a fix in NGINX or NGINX Plus.
Why Do I See “Welcome to nginx!” on My Favorite Website?
The ‘Welcome to NGINX!’ page is presented when NGINX web server software is installed on a computer but has not finished configuring