A recently reported vulnerability in version 3 of the SSL protocol (SSLv3) can be exploited in a man-in-the-middle attack to extract parts of a plain‑text transmission that was encrypted with HTTPS. Google researchers have published a detailed explanation describing how such an attack might be mounted.
This is not a vulnerability in any implementation of SSL/TLS, but rather a vulnerability in the design of the SSLv3 protocol when using block ciphers. As all alternative stream ciphers also show weaknesses, the only measure is to disable SSLv3 in your NGINX and NGINX Plus configurations.
Disabling SSLv3 in NGINX
SSLv3 is enabled by default in NGINX and NGINX Plus, and is potentially used by HTTP and Mail services.
[Editor – Proxy and load balancing of TCP traffic was not fully supported when this article was originally published. For the sake of completeness, the following steps have been updated to include protection for TCP traffic.]
Perform these steps on all NGINX and NGINX Plus instances:
- Eliminate SSLv3 from the set of protocols used for HTTP traffic. Add the following
ssl_protocolsdirective to thehttp{}block if it doesn’t exist, or edit the existing directive to removeSSLv3from the parameter list. - Create or edit the same directive in the
mail{}configuration block if your NGINX or NGINX Plus instances handle Mail traffic. - Create or edit the same directive in the
stream{}configuration block if your NGINX or NGINX Plus instances handle TCP traffic. - Locate all other instances of the
ssl_protocolsdirective in your configuration (it can be included in aserver{}configuration block within thehttp{},mail{}, andstream{}blocks). We recommend removing thesessl_protocolsdirectives, but at minimum removeSSLv3from the list of parameters: - Run the following command to reload the configuration:
What’s the Effect of This Change?
All modern browsers and API clients support TLSv1 and later. Disabling SSLv3 will inconvenience WindowsXP users who browse using Internet Explorer 6; CloudFlare estimates that 1.12% of WindowsXP users (who make up 3.12% of their traffic) will be affected – this equates to approximately 1 in 3000 users.
The change might also affect web crawlers and other automated bot traffic.
The Future
In an SSL Downgrade attack, the attacker can disrupt SSL/TLS handshakes and cause the client and server to select an earlier version of SSL/TLS. When used to force selection of SSLv3, it can make the SSL/TLS connection vulnerable to the POODLE attack. Disabling SSLv3 at the server makes this attack impossible.
Google has proposed an extension to SSL/TLS named TLS_FALLBACK_SCSV that seeks to prevent forced SSL/TLS downgrades. [Editor – The extension was adopted as RFC 7507 in April 2015.] This extension might eventually be accepted into OpenSSL, and the corresponding client‑side support added to major browsers. This will allow web services to support SSLv3, but legacy clients will still be vulnerable.
Nevertheless, this vulnerability might signal the final nail in the coffin for SSLv3 – a simpler and more reliable solution overall.
What Else Can I Do?
We recommend updating your client software so that it does not support SSLv3. This will protect you from this attack when you access services that have not been updated to disable SSLv3.
Further Reading
- The original vulnerability report
- A more concise explanation from ImperialViolet
- Several vendors have published recommendations; Ubuntu’s is particularly comprehensive
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
