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.
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_protocols
directive to the http{}
block if it doesn’t exist, or edit the existing directive to remove SSLv3
from the parameter list.
# in the http{} configuration blockssl_protocols TLSv1 TLSv1.1 TLSv1.2; # omit SSLv3 because of POODLE (CVE‑2014‑3566)
Create or edit the same directive in the mail{}
configuration block if your NGINX or NGINX Plus instances handle Mail traffic.
# in the mail{} configuration blockssl_protocols TLSv1 TLSv1.1 TLSv1.2; # omit SSLv3 because of POODLE (CVE‑2014‑3566)
Create or edit the same directive in the stream{}
configuration block if your NGINX or NGINX Plus instances handle TCP traffic.
# in the stream{} configuration blockssl_protocols TLSv1 TLSv1.1 TLSv1.2; # omit SSLv3 because of POODLE (CVE‑2014‑3566)
Locate all other instances of the ssl_protocols
directive in your configuration (it can be included in a server{}
configuration block within the http{}
, mail{}
, and stream{}
blocks). We recommend removing these ssl_protocols
directives, but at minimum remove SSLv3
from the list of parameters:
# in every server{} block ssl_protocols TLSv1 TLSv1.1 TLSv1.2;# omit SSLv3 because of POODLE (CVE‑2014‑3566)
Run the following command to reload the configuration:
# nginx –s reload
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.
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.
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.
"This blog post may reference products that are no longer available and/or no longer supported. For the most current information about available F5 NGINX products and solutions, explore our NGINX product family. NGINX is now part of F5. All previous NGINX.com links will redirect to similar NGINX content on F5.com."