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_protocols
directive to thehttp{}
block if it doesn’t exist, or edit the existing directive to removeSSLv3
from the parameter list.# in the http{} configuration block ssl_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 block ssl_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 block ssl_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 aserver{}
configuration block within thehttp{}
,mail{}
, andstream{}
blocks). We recommend removing thesessl_protocols
directives, but at minimum removeSSLv3
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
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