Remove SSLv3 from Default ssl_protocols behavior

[Thomas Ward]

As far as I can tell, this affects both Stable and Mainline branches. Effectively, 1.6.x and 1.7.x both should have this applied, in my opinion.

Currently, according to the documentation at ​http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_protocols the SSL module has a default setting of ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2; if ssl_protocols is not defined.

Unfortunately, this leaves new site configurations which don't define ssl_protocols explicitly vulnerable to POODLE. Ultimately, it is best to remove SSLv3 from the default protocols list.

To that end, I went digging in the code. If one were to make the following changes this would effectively remove SSLv3 from the default, if SSLv3 is not specified explicitly via ssl_protocols:

REPLACE Line 564 of the ngx_http_ssl_module.c file in src/http/modules (​http://trac.nginx.org/nginx/browser/nginx/src/http/modules/ngx_http_ssl_module.c#L564) with:
(NGX_CONF_BITMASK_SET|NGX_SSL_TLSv1

Ultimately, you can still enable SSLv3, but it is off by default. I have run tests on this and it appears that it will work correctly to disable the SSLv3-by-default functionality. While it is easier to ship configuration files which disable SSLv3, that does not prevent a user from using modified configurations which don't disable SSLv3 by default, but also don't specify an ssl_protocols line.

NOTES: uname -a is from the Ubuntu Virtual Machine I am using. The nginx -V line is from the NGINX Stable PPA which is based off of Debian's packaging of the nginx stable version.

[https://stackoverflow.com/users/573152/bernard-rosset]

nginx blog itself says impact on real users is minimal
​http://nginx.com/blog/nginx-poodle-ssl/

Considering the fact that it might affect bots, if they cannot/prefer to use SSLv3 over other protocols, they are:

1. very outdated
2. definitely acting strange

Overall, no real reason as to why support SSLv3 by default as it exposes users de facto

[Maxim Dounin]

This was already discussed, and consensus is that we are not changing the default for now. Rationale is as follows:

• SSLv3 is still important from compatibility point of view, there are various clients which doesn't support (or enable by default) anything better;

• Mitigation for POODLE is already good and improving, including fallback protection via TLS_FALLBACK_SCSV and anti-POODLE record splitting; so, basically, modern browsers are not affected.

See these threads for more details:

​http://mailman.nginx.org/pipermail/nginx-ru/2014-October/054783.html
​http://mailman.nginx.org/pipermail/nginx-devel/2014-October/006161.html

We'll likely reconsider the change later.

[Thomas Ward]

Maxim: I question the logic here. Less than 3% of the Internet's clients, based on CloudFlare, are using legacy devices which are impacted by the lack of SSLv3. While modern browsers are not affected, unfortunately Firefox does NOT support TLS_FALLBACK_SCSV at this time. As well, continuing to support SSLv3 out of the box is still insecure - even if browsers drop it, you can still be vulnerable to POODLE via a specially crafted attack via, say, curl, or the openssl_client program, or any number of alternate methods to trigger the attack. IE also does not support TLS_FALLBACK_SCSV at my last checks, which further can open a risk of POODLE.

If your compatibility point of view relies at all on XP, TLSv1 is supported on IE8 on XP. With less than 3% of users on XP or legacy devices, based on Cloudflare and other data, you're looking at a failure in your logic to provide legacy support while keeping a vulnerability to POODLE in the system. Even then, if WinXP/IE8 is the consideration point, Windows has already got TLSv1 support in there. Disabling SSLv3 therefore has no impact on there.

If your compatibility argument is based on the 11% of chinese users still using IE6, that's a little outside the scope here, I believe. IE6 is so old that anyone using it, China or not, is vulnerable to a whole host of other problems, not just SSL incompatibility. As well, the proposed change here allows webmasters to enable SSLv3. It ultimately only changes the default bitmask. You will be able to reenable SSLv3 by specifying it on the ssl_protocols line. I don't agree with dropping SSLv3 support altogether, I just suggest changing the default ssl_protocols behavior for when it's not defined.

If you are choosing to keep SSLv3 SOLELY for the ancient legacy support, you're ultimately detracting from the "modern web server" standards. This is why changing the defaults is one thing, while dropping SSLv3 support overall is different. We can still safely drop the default ssl_protocols support while keeping SSLv3 support in the web server. This allows SSLv3 to be enabled if it's needed, but keeps nginx 'modern' in the sense of security. (To that end, I've heard rumors that Apache is making this change, which, being the other big web server software, means that nginx might be lagging behind in that regard.)

I strongly suggest we revisit this issue sooner rather than later because this DOES need to be addressed.

(Also, sending me to a Russian thread on this issue added a substantial headache - I'm not russian speaking so I had to hand off the entire email chain manually...)

[https://stackoverflow.com/users/573152/bernard-rosset]

I also do not get the point.

I saw 2 people on the nginx-devel mailing list actively defending the fact that default configuration should be protection-oriented rather than compatibility-oriented.

Count 4 with Thomas and me here.
That is 4 vs 1 on visible discussions based on this ticket alone.
At least allow the discussion to go on, rather that closing a thread deciding you guys won't fix it. There is life outside nginx' offices...

Real-life aspects are being underlined, the most prominent one being that for a very large amout of standard nginx use cases, the clients will have at least support of TLS v1.0. Edgy cases with clients not supporting TLS are the exception.

SSLv3 is facing yet another classical Mexican stand-off in computer engineering:

1. Servers won't upgrade since some clients still need it
2. Clients won't upgrade since 'it works' so they do not need to change a thing

I thought nginx was part of those companies always pushing good practices ahead. This 'good practices' phrase is something you might hear/read a lot around nginx.
Well. Good practices imply knowing when compatibility should be kept and when to dissatisfy a bunch of lazy/outdated clients.

Having big players such as LinkedIn and CloudFlare deactivating SSLv3 is a sign of confidence. It is maybe finally time to get (and a perfect opportunity of getting) rid of SSLv3.

[Owen Garrett]

Thanks for the comments - we do hear what you're saying.

If it makes sense for you to explicitly disable SSLv3, then of course it makes sense for us to change the default behavior for you. However, there are hundreds of millions of NGINX services running - public, internal, legacy - and we're not comfortable making that decision on behalf of every one of them.

One the one hand, the POODLE vulnerability received a huge amount of publicity. Anyone dealing with public web apps should be aware of it and should already have made a judgement about whether or not to make the well documented configuration changes to disable SSLv3.

On the other hand, if we were to change the default behavior to disable SSLv3, this would go largely unnoticed. Not everyone reads the cumulative change list of every package when they apt-get update...?

We might then unexpectedly lock out your IE6/XP customers. They are your users and customers, not ours. It's your decision whether to exclude them from your service, not ours.

Furthermore, there are plenty of internal services that use NGINX with custom, legacy clients. Disabling SSLv3 would potentially lock out an unknown number of non-browser-based clients with unknown and hard-to-debug consequences.

When we made our decision, we were mindful to balance a 'secure-by-default' posture against our responsibility to not break anything in unexpected ways.

For the time being, we have come down on the 'don't break anything' side, and as Maxim hinted, we may reconsider this later when the risks to our users are lower.

[https://stackoverflow.com/users/573152/bernard-rosset]

We are talking about default configuration, right?

That means to me it won't break any existing nginx instance because default files do not override existing configuration without asking for it first (and offering the capability of showing a diff).

What we are talking about with default configuration are new instances, which you would want as secured and as performant for the most common use cases.

Unless I am mistaken, I guess these most common use cases imply not using SSLv3. There are some other tweaks you could also add (such as worker_processes set to auto).

The baseline is: changing default configuration should not break any existing nginx isntance. If it does, it is because systems owners are automatically overriding their configuration with the default one from the the source without checking it.
In that case, they are to blame, not you.

At the same time, default configuration is usefull for new setups. People with specific needs should be the ones having the most work to do, modifying the configuration, and it will be those people who will search for edge cases of configuration.
People using standard setup for common use cases should not stumble upon (or worse and most probably: oversee) a security flaw in the shipped default configuration.
Summing up: Make the 20% deal with the extra work, not the 80%...

Thus, I still do not get your stance, guys.

[Valentin V. Bartenev]

Replying to Bernard Rosset <be.rosset@gmail.com>:

We are talking about default configuration, right?

That means to me it won't break any existing nginx instance because default files do not override existing configuration without asking for it first (and offering the capability of showing a diff).

Default files don't contain the ssl_protocols directive, which means that the default value is used. And you propose to change it.

If it does, it is because systems owners are automatically overriding their configuration with the default one from the the source without checking it.

No, you're wrong here. Changing default value of any directive can affect existing configurations.

[Maxim Dounin]

Reopened, this is currently being reconsidered.

[Maxim Dounin <mdounin@…>]

In b2899e7d0ef83d6bbaed6ad96bf31ba72ae4b185/nginx:

Disabled SSLv3 by default (ticket #653).

[Maxim Dounin]

Committed. Thanks for prodding this.