Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deprecate SSLv2 support on v0.12 and v0.10 #80

Closed
shigeki opened this issue Mar 1, 2016 · 18 comments
Closed

Deprecate SSLv2 support on v0.12 and v0.10 #80

shigeki opened this issue Mar 1, 2016 · 18 comments

Comments

@shigeki
Copy link

shigeki commented Mar 1, 2016

OpenSSL-1.0.1s disables SSLv2 by default for against DROWN attack(CVE-2016-0800). https://www.openssl.org/news/secadv/20160301.txt

There are no reasons to continue to support SSLv2 on Node LTS.

@rvagg
Copy link
Member

rvagg commented Mar 1, 2016

I'd like more input on this, so /cc @nodejs/crypto @nodejs/ctc (@nodejs/lts).

Reference to read up on if you're not following the details: https://drownattack.com/

Of particular relevance is this:

Modern servers and clients use the TLS encryption protocol. However, due to misconfigurations, many servers also still support SSLv2, a 1990s-era predecessor to TLS. This support did not matter in practice, since no up-to-date clients actually use SSLv2. Therefore, even though SSLv2 is known to be badly insecure, until now, merely supporting SSLv2 was not considered a security problem, because clients never used it.

DROWN shows that merely supporting SSLv2 is a threat to modern servers and clients. It allows an attacker to decrypt modern TLS connections between up-to-date clients and servers by sending probes to a server that supports SSLv2 and uses the same private key.

We are already not enabling it by default for 0.10 and 0.12 (right?) and you have to use --enable-ssl2 to get it. My preference is always to non baby our users, I'm absolutely fine with a "secure by default" approach my experience tells me that there are way too many crazy ways that people are using Node in the wild that it's difficult to know whether what we think is an appropriate course of action isn't actually going to cause significant problems for a portion of users. So caveat emptor and a conservative process is my preferred way of making changes to LTS in particular.

However, the difficulty here is that having sslv2 enabled and not even necessarily using it can open you up to attack.

At this stage my vote would be to print a verbose warning at start-up if you --enable-ssl2 that points to https://drownattack.com/ or other resource, rather than removing it entirely. But that's a soft preference and I'm not going to fight too hard if others have strong conviction here, so speak up!

@mhdawson
Copy link
Member

mhdawson commented Mar 1, 2016

I think I'd prefer if we removed the option by default, but allowed that to be reverted with --security-revert={cvenum}. So if you added --security-revert={CVE-2016-0800} you'd get the warning and be able to use --enable-ssl2. (I think --security-revert was going to warn for each one reverted)

It leverages the approach we put in place the last time and makes the bar a little higher in that you have to actively choose to add --security-revert while at the same time providing the customer a work around if they absolutely still need to keep using it.

@bnoordhuis
Copy link
Member

I'll be the contrarian today. :-)

SSLv2 was superseded - because it was known to be flawed - by SSLv3 twenty years ago, in 1996. It was officially deprecated (in RFC 6176) half a decade ago, in 2011. From the abstract:

This document requires that when Transport Layer Security (TLS)
clients and servers establish connections, they never negotiate the
use of Secure Sockets Layer (SSL) version 2.0.

I agree with Rod that babying your users is bad but I don't think that's what we're doing if we remove SSLv2 support for good.

Honestly, I can't think of a remotely valid use case that would require SSLv2. Even if your application needs to talk to a 2001-era set-top box, it's going to communicate over SSLv3, not SSLv2.

@evanlucas
Copy link

Do we have any data on whether people are even using the --enable-ssl2 flag still?

@shigeki
Copy link
Author

shigeki commented Mar 2, 2016

Note that the current HEAD of v0.12/v0.10-staging cannot work SSLv2 even if we use --enable-ssl2.

According to openssl/openssl@56f1acf, we need to add the following patch.

diff --git a/src/node_crypto.cc b/src/node_crypto.cc
index 454c9be..754d159 100644
--- a/src/node_crypto.cc
+++ b/src/node_crypto.cc
@@ -391,6 +391,9 @@ void SecureContext::Init(const FunctionCallbackInfo<Value>& args) {
   SSL_CTX_sess_set_get_cb(sc->ctx_, SSLWrap<Connection>::GetSessionCallback);
   SSL_CTX_sess_set_new_cb(sc->ctx_, SSLWrap<Connection>::NewSessionCallback);

+  if (SSL2_ENABLE)
+    SSL_CTX_clear_options(sc->ctx_, SSL_OP_NO_SSLv2);
+
   sc->ca_store_ = NULL;
 }

Furthermore, three SSLv2 ciphers of EXP-RC2-CBC-MD5, DES-CBC-MD5 and DES-CBC3-MD5 are completely disabled by #if 0 so that we cannot provide exact the same features of SSLv2 as before unless we change them.

I don't think it is worth while continuing to support SSLv2 even in LTS with paying such costs.

@mhdawson
Copy link
Member

mhdawson commented Mar 2, 2016

While I prefer that we avoid breaking changes, we have had to accept them from openssl and pass them along in the past. In this case since we'd have to actively change the Node.js code to enable insecure algs and it would only be a partial fix without floating patches on openssl, I'd have a hard time making a strong case for doing it.

@jasnell
Copy link
Member

jasnell commented Mar 2, 2016

I'm leaning the same direction as @shigeki and @bnoordhuis. At this point there is exceedingly little reason to continue supporting SSLv2 in any way.

@evanlucas
Copy link

+1 to removing it unless someone makes a very compelling argument against it

@Fishrock123
Copy link
Contributor

🔪

Does that mean the flag will be removed, or that it simply won't do anything?

Alternatively we could make the existing flag just warn and move the functionality under --security-revert, but I doubt we feel strongly enough to do that at this point.

Edit: I just read that the security patch to OpenSSL itself disables it outright. 🔪 🔪

@brodycj
Copy link

brodycj commented Mar 2, 2016 via email

@ChALkeR
Copy link
Member

ChALkeR commented Mar 2, 2016

+1 to removing, but not sure what should the existing flag do — warn or throw?

@MylesBorins
Copy link
Contributor

+1 to having the flag give a warning. While that is technically a semver major I think it is way better than having individuals keep using the flag with no idea

@mhdawson
Copy link
Member

mhdawson commented Mar 2, 2016

I agree that we should not leave the option but have it do nothing. If we just remove it completely the end user would get "bad option:". A warning would allow them to run, but if they are actually using it that could result in a harder to diagnose problem later on. I think I'd lean towards removing completely

@Fishrock123
Copy link
Contributor

@mhdawson has a point. Maybe detect that flag and fail early with a special error?

@bnoordhuis
Copy link
Member

I'll write a patch.

@rvagg
Copy link
Member

rvagg commented Mar 2, 2016

(cross-posting nodejs/node#5433 (comment))

I'm calling it and adding this:


SSLv2 support is being removed

Given the additional barriers introduced in OpenSSL 1.0.1s to retaining SSLv2 support and the long list of known SSLv2 vulnerabilities, Node.js v0.10.43 and v0.12.11 will be completely remove SSLv2 support and the --enable-ssl2 command-line argument.


I also suggest this means that if you supply the argument then it should bork, not fail silently, it's a breaking change but it needs to be explicit.

@bnoordhuis
Copy link
Member

nodejs/node#5529 (v0.10)

bnoordhuis added a commit to bnoordhuis/io.js that referenced this issue Mar 2, 2016
Remove support for SSLv2 because of DROWN (CVE-2016-0800).

Use of the `--enable-ssl2` flag is now an error; node will print an
error message and exit.

Fixes: nodejs/Release#80
PR-URL: nodejs#5529
Reviewed-By: Rod Vagg <rod@vagg.org>
@shigeki
Copy link
Author

shigeki commented Mar 4, 2016

nodejs/node#5536 (v0.12)

Quoting from abstract in the paper of DROWN attack,

We conclude that SSLv2 is not only weak, but actively harmful to the TLS ecosystem

I close this for hoping that Node makes TLS ecosystem be healthy.
Thanks for all your agreements.

@shigeki shigeki closed this as completed Mar 4, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

10 participants