[Converge] --cipher-list and --enable-legacy-cipher-list Command Line Switch

[jasnell]

We've been in the progress of porting the updated io.js default cipher lists over to node.js. In addition to this change, we're working on adding new --cipher-list and --enable-default-cipher-list command line switches that allow the compiled in default cipher list to be overridden. This is a work in progress that hasn't fully landed yet.

• 4d9c81b7e2522c5d5d9d35058cbb0bce1228d360 test: fixing a few nits in the test
• 370573665a4daba22655e00c8d0ae8577899d8e5 tls: pass in isolate with define string constant + style nits
• 3f58ce6942fd0cf90877a4df2fb32539f1614c9d tls: make --enable-legacy-cipher-list less verbose
• 1bf15467e2b7e074f16744806aff92544953fbd9 tls: command-line switch and envar cipher-list override
• tls: throw an error on getLegacyCipher node-v0.x-archive#14574 (master)
• tls: throw an error on getLegacyCipher node-v0.x-archive#14573 (v0.12)
• tls: throw an error on getLegacyCipher node-v0.x-archive#14572 (v0.10)

[jasnell]

The tl/dr version:

This work adds new command line switches and envars:

• --cipher-list and NODE_CIPHER_LIST override the default cipher list with a complete user-provided alternative. e.g. node --cipher-list=ABC would set the default cipher list to ABC
• --enable-legacy-cipher-list and NODE_LEGACY_CIPHER_LIST override the default cipher list by reverting it back to known previous version cipher lists. e.g. node --enable-legacy-cipher-list=v0.10.38 reverts it back to the default cipher list from Node v0.10.38.
• There's a new tls.getLegacyCiphers method in tls.js to grab the default cipher list from a specific version. e.g. tls.getLegacyCiphers('v0.10.38') returns the v0.10.38 cipher list.

[bnoordhuis]

/cc @nodejs/crypto

[rvagg]

I'm wondering if there is a case for the legacy ciphers list, are we aware of any use cases that would break if they change to the new list. I know the new list is very restrictive but it's also modern and similar to what you'll find configured in many web servers today. We might be denying use of Java6 or Android Browser 4 but .. if you're supporting old clients like that then I'm sure you're expecting to have a hard time all over the place.

I'm +1 on --cipher-list and NODE_CIPHER_LIST but -0 on all of the legacy cipers work because that sounds like a path toward building up a lot of technical debt and easily enabling unsafe run modes.

[indutny]

What is the reason behind introducing command line arg and env variable for overriding this? I wonder if it might be accomplished in the user land without doing this? Are there any people who requested it?

[jasnell]

Will provide more detail on the history of this when I've got more time
over the next couple of days. For now, back to date night!
On Jun 26, 2015 8:31 PM, "Fedor Indutny" notifications@github.com wrote:

What is the reason behind introducing command line arg and env variable
for overriding this? I wonder if it might be accomplished in the user land
without doing this? Are there any people who requested it?

—
Reply to this email directly or view it on GitHub
nodejs/node#39 (comment).

[jasnell]

Ok, so I'll split this up a bit:

The main justification for introducing --cipher-list and NODE_CIPHER_LIST is to allow Node.js deployments to be updated to a new, more secure or alternate built in default cipher list without requiring a full Node.js update. The intent is to allow sysops to more quickly respond to cipher vulnerabilities without having to wait for the next release -- this is particularly important in the case that changes to the default cipher list break backwards compatibility.

The justification for the legacy cipher list is to make it possible to revert to a specific known previous default without requiring that developers keep track of the lists themselves. The intent is to keep this list of supported legacy lists as short as possible, but yes, it's possible to build up cruft.

When we (IBM) first made these changes to our own Node.js build, we initially deployed to our bluemix environment using the updated cipher list that switches off RC4. Once it was deployed, we discovered that quite a few of the applications deployed on top ended up breaking because of their reliance on RC4. Instead of having to revert the deployment, the sysops were simply able to use the legacy cipher environment variable to temporarily revert the default cipher list without (a) having to know what that default cipher list was (they simply enabled the default for the previous version of node they deployed), (b) having to revert the Node update on their servers or (c) having to force application developers to work. After setting that environment variable, they went back and worked with the application developers whose applications broke to get them off of RC4 then were simply able to remove that environment variable to switch back to the new default cipher list. It ended up being a very simple and smooth approach.

It would be possible to use a userland module to maintain the old cipher lists but then each application deployed to a PaaS environment like bluemix would need to be modified to use the module when a temporary system-wide revert like the one described above becomes necessary.

@mhdawson may have some additional thoughts on this as well...

[indutny]

Thank you for the explanation! +1

[rvagg]

Pretty sure this is handled by nodejs/node#2412