tls: prevent server from using dhe keys < 768 #3890
Conversation
|
LGTM Ran test suite locally. 1 failing (but unrelated) test in |
|
This is a patch that prevents a security misconfiguration, IMO that makes it not a |
|
Technically it is semver-major but it is one that should have minimal impact. The introduction of the new command line switch to revert to the prior behavior is also significant. That said, this would land in v0.12.x which is in a weird place in semver-land anyway. LGTM |
| @@ -203,7 +203,8 @@ automatically set as a listener for the [secureConnection][] event. The | |||
|
|
|||
| - `dhparam`: DH parameter file to use for DHE key agreement. Use | |||
| `openssl dhparam` command to create it. If the file is invalid to | |||
| load, it is silently discarded. | |||
| load, it is silently discarded. Its key length should be greater | |||
| than or equal to 768 bits, otherwise it throws an error. | |||
There was a problem hiding this comment.
"its key length" -> "it throws an error", with "it" referring to two different things here. Maybe just "otherwise an error will be thrown" as the easy way out.
|
I'm not really happy about the |
|
Also, I'd vote for semver-major, we can argue this is a bug or misconfiguration but in the spirit of the conservative approach to semver we've been taking we should hold off till the next major. And, /cc @nodejs/crypto |
|
@rvagg The only setups this is going to break is those that have been dangerously misconfigured. And they still have a way to get back the old behaviour. It looks like a sane thing to do. An alternative non-breaking approach would be to reduce this to a big warning instead of an Error. But given that this part of code is generally one of the first things that the server does — anyone should notice the error immediately after the version update on the test setup. |
|
@rvagg .. note that this does not print the I'm good with |
|
oh, I see this is for 0.12, we are doing the right thing in v4+ I take it then? |
|
@mhdawson , correct me if I'm wrong, but this fix would end up needing to go out in v4.x also (unfortunately). In v4.x it would be a semver-minor bump |
|
I leave the decision of a new option name to native English speakers. I have no preference. @mhdawson I have two comments here.
@jasnell It's already in v4.x with 1024 bits limit at https://github.com/nodejs/node/blob/v4.x/src/node_crypto.cc#L800-L806 . Do not be worry :-) |
Fishrock123
added
the
semver-minor
|
Note: this is at least |
|
@shigeki ... ah, that's right.. so hard to keep track sometimes :-/ |
|
@shigeki I added the requested change to the Makefile for the test fixtures. In terms of documenting this the discussion I had with James was that we'd prefer not to add to the regular documentation. We don't want anybody to use it and it will not be in any later release. Instead we planned to just document it in the migration notes so that people are aware of it if they need to use it when upgrading but otherwise are less likely to use it. I think Jame's comment above echo's the same approach. Does that make sense to you or do you still think we need to add it to printHelp() and tls.markdown ? |
|
@rvagg updated to address wording comments and change name of the option |
|
@mhdawson I'm okay for no doc. Someone in the future would have the same question as mine so please write its description in the commit log. Otherwise, LGTM after CI is fine. |
As part of the fix for logjam, node was upgraded to a level of openssl which rejects connections to servers that are using keys smaller than 768 bits. It is still possible, however, to create a server that uses a smaller key size and and older client may be able to connect to it. This PR moves us to a secure by default stance on the server side as well, preventing the creation of a server using a dhe key size less than 768. This can be overridden with the command line option which is also added. It is derived from nodejs@9b35be5 which was landed in later io.js/node versions but makes the limit 1024. This PR uses the smaller limit in order to meet the recomendations for logjam while matching was was done on the client side in openssl to minimize the potential impacton users. The command line option will only be documented in the release notes and will not be added to the tls documentation. The goal is that people who are upgrading are aware and can use the option if they run into issues, but otherwise the option is not visible/used. Address review comments 1 Address second set of review comments
|
Updated based on shigeki's comment to add to the commit comment and squashed. |
| // USE OR OTHER DEALINGS IN THE SOFTWARE. | ||
| // | ||
| // Flags: --allow-insecure-server-dhparam | ||
|
|
There was a problem hiding this comment.
The copyright/license header should be removed. nm... oy, forgot these are v0.12
|
Changes LGTM. Disregard my previous two comments, keep forgetting this is v0.12. |
|
CI run is green on all but windows. Looking at earlier failures most of them are pre-existing. The only one that worries me a bit is "not ok 721 - test-tls-ticket-cluster.js" which failed 2/3 times and which I don't see in the previous run, going to start another CI run to see how many times it recreates. Don't think its related as I'd expect any failure to be 100% but more data can't hurt https://ci.nodejs.org/job/node-test-pull-request/782/ |
|
If that continues to fail, may want to pass it through the new stress test job in CI to see if it's flaky |
|
From test https://github.com/nodejs/node/blob/v0.12/test/simple/test-tls-ticket-cluster.js -----BEGIN RSA PRIVATE KEY----- So looks to be an RSA key, don't see how that could be related to limiting DHE key size |
|
No recreates in second run, only failures commonly seen on windows so seems unrelated. I think we are good to go CI run wise |
|
@rvagg ... can we get one more review from you on this before landing? |
|
I'm not entirely comfortable with squeezing this in to v0.12 cause of the breaking nature of it but I'll throw in an lgtm for the sake of secure-by-default and the low likelihood of anyone being impacted. |
|
@mhdawson test-tls-ticket-cluster.js has nothing to do with DHE key exchange. Probably it was a timing issue in process fork and die. FYI. Google is planning to deprecate DHE in Chrome because they consider that 1024bits DHE has not enough security and moving to ECDHE is better. |
|
I'm not happy with adding another seldom used command line switch, but if you go ahead, please at add it to |
|
not documenting it is intentional. This switch would only exist in v0.12
|
|
@jasnell alright, carry on! |
|
I was out Friday afternoon so just see the comment from James to land, will do that now |
As part of the fix for logjam, node was upgraded to a level of openssl which rejects connections to servers that are using keys smaller than 768 bits. It is still possible, however, to create a server that uses a smaller key size and and older client may be able to connect to it. This PR moves us to a secure by default stance on the server side as well, preventing the creation of a server using a dhe key size less than 768. This can be overridden with the command line option which is also added. It is derived from 9b35be5 which was landed in later io.js/node versions but makes the limit 1024. This PR uses the smaller limit in order to meet the recomendations for logjam while matching was was done on the client side in openssl to minimize the potential impacton users. The command line option will only be documented in the release notes and will not be added to the tls documentation. The goal is that people who are upgrading are aware and can use the option if they run into issues, but otherwise the option is not visible/used. PR-URL: #3890 Fixes: nodejs/Release#49 Reviewed-By: Myles Borins <[email protected]> Reviewed-By: James Snell <[email protected]> Reviewed-By: Rod Vagg <[email protected]> Reviewed-By: Shigeki Ohtsu <[email protected]>
|
landed caa16b4 |
PR #3890 [1] introduced the variable ALLOW_INSECURE_SERVER_DHPARAM defined in src/node_crypto.cc. However, if nodejs is built without OpenSSL support, the build fails: error: ‘ALLOW_INSECURE_SERVER_DHPARAM’ was not declared in this scope ALLOW_INSECURE_SERVER_DHPARAM = true; Fix this by using the preprocessor macro HAVE_OPENSSL to opt-out the use of ALLOW_INSECURE_SERVER_DHPARAM in non-OpenSSL builds. [1] #3890 PR-URL: #4201 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Rod Vagg <[email protected]>
PR #3890 [1] introduced the variable ALLOW_INSECURE_SERVER_DHPARAM defined in src/node_crypto.cc. However, if nodejs is built without OpenSSL support, the build fails: error: ‘ALLOW_INSECURE_SERVER_DHPARAM’ was not declared in this scope ALLOW_INSECURE_SERVER_DHPARAM = true; Fix this by using the preprocessor macro HAVE_OPENSSL to opt-out the use of ALLOW_INSECURE_SERVER_DHPARAM in non-OpenSSL builds. [1] #3890 PR-URL: #4201 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Rod Vagg <[email protected]>
As part of the fix for logjam, node was upgraded to a level of openssl which rejects connections to servers that are using keys smaller than 768 bits. It is still possible, however, to create a server that uses a smaller key size and and older client may be able to connect to it. This PR moves us to a secure by default stance on the server side as well, preventing the creation of a server using a dhe key size less than 768. This can be overridden with the command line option which is also added. It is derived from nodejs/node@9b35be5 which was landed in later io.js/node versions but makes the limit 1024. This PR uses the smaller limit in order to meet the recomendations for logjam while matching was was done on the client side in openssl to minimize the potential impacton users. The command line option will only be documented in the release notes and will not be added to the tls documentation. The goal is that people who are upgrading are aware and can use the option if they run into issues, but otherwise the option is not visible/used. PR-URL: nodejs/node#3890 Fixes: nodejs/Release#49 Reviewed-By: Myles Borins <[email protected]> Reviewed-By: James Snell <[email protected]> Reviewed-By: Rod Vagg <[email protected]> Reviewed-By: Shigeki Ohtsu <[email protected]>
PR nodejs#3890 [1] introduced the variable ALLOW_INSECURE_SERVER_DHPARAM defined in src/node_crypto.cc. However, if nodejs is built without OpenSSL support, the build fails: error: ‘ALLOW_INSECURE_SERVER_DHPARAM’ was not declared in this scope ALLOW_INSECURE_SERVER_DHPARAM = true; Fix this by using the preprocessor macro HAVE_OPENSSL to opt-out the use of ALLOW_INSECURE_SERVER_DHPARAM in non-OpenSSL builds. [1] nodejs/node#3890 PR-URL: nodejs/node#4201 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Rod Vagg <[email protected]>
As part of the fix for logjam, node was upgraded to a
level of openssl which rejects connections to servers that
are using keys smaller than 768 bits. It is still possible,
however, to create a server that uses a smaller key size
and and older client may be able to connect to it.
This PR moves us to a secure by default stance on the
server side as well, preventing the creation of a server
using a dhe key size less than 768. This can be overridden
with the command line option which is also added.
It is derived from
9b35be5
which was landed in later io.js/node versions but makes
the limit 1024. This PR uses the smaller limit in order
to meet the recomendations for logjam while matching was
was done on the client side in openssl to minimize the
potential impacton users.