Protecting NGINX and NGINX Plus from the POODLE Attack

Original: https://www.nginx.com/blog/nginx-poodle-ssl/

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:

  1. 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 block
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # omit SSLv3 because of POODLE (CVE‑2014‑3566)
  2. 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)
  3. 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)
  4. 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)
  5. 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

Retrieved by Nick Shadrin from nginx.com website.