镜像站点 · 本页由第三方 GitHub 只读镜像提供，非 GitHub 官方站点，不接受任何登录或凭据输入。前往 github.com
Skip to content

Allow enabling FIPS mode from an environment variable #10938

Closed
#11006
Closed
Allow enabling FIPS mode from an environment variable#10938
#11006
Labels
cryptoIssues and PRs related to the crypto subsystem.

Description

@gibfahn
gibfahn
opened on Jan 21, 2017

Problem

As of cae9eb35f0, it is no longer possible to enable FIPS mode with an environment variable. This change was to prevent security issues caused by the misuse of the $OPENSSL_CONF variable. However this means it is no longer possible to test that the FIPS binary actually fails as expected in CitGM.

We can expect (for example) citgm ws to fail with:

error: | 4) WebSocketServer hixie mode connection establishing handles messages passed along with the upg
error: | Uncaught Error: error:060A80A3:digital envelope routines:FIPS_DIGESTINIT:disabled for fips      
error: | at Error (native)                                                                               
error: | at new Hash (crypto.js:56:18)                                                                   
error: | at Object.Hash (crypto.js:55:12)                                                                
error: | at WebSocketServer.completeHandshake (lib/WebSocketServer.js:411:24)                            
error: | at onClientVerified (lib/WebSocketServer.js:471:25)                                             
error: | at WebSocketServer.handleHixieUpgrade (lib/WebSocketServer.js:526:3)                            
error: | at WebSocketServer.handleUpgrade (lib/WebSocketServer.js:172:61)                                
error: | at Server.WebSocketServer._onServerUpgrade (lib/WebSocketServer.js:89:12)                       
error: | at onParserExecuteCommon (_http_server.js:409:14)                                               
error: | at HTTPParser.onParserExecute (_http_server.js:377:5)
Node Version How to enable FIPS Command to test
v4 On by default citgm ws
v6.0.0..v6.8.1 Requires env var OPENSSL_CONF=/path/to/openssl_fips_enabled.cnf citgm ws
v6.9.0.. Command line flag only mkdir bin; printf '#!/bin/sh'"\n/path/to/node --force-fips "'$*'>bin/node; export PATH=$PWD/bin:$PATH; citgm ws (doesn't work as child processes are spawned).

Possible solution

Allow OPENSSL_FIPS=enable to enable FIPS mode, but don't provide an equivalent to disable it, I don't think this causes any security issues.

Refs:

Turn off FIPS by default: #5181
Discussion of OPENSSL_FIPS: #3820
PR to ignore OPENSSL_CONF: https://github.com/nodejs/node-private/pull/82

cc/ @rvagg @bnoordhuis @shigeki @mhdawson @gdams @sxa555

Activity

  1. gibfahn
    added
    cryptoIssues and PRs related to the crypto subsystem.
    on Jan 21, 2017

  2. gdams commented on Jan 22, 2017

    @gdams
    gdams
    on Jan 22, 2017
    Member

    I am personally slightly confused as to what security difference there would be between using an environment variable to set the config file rather than passing it as a flag. Looking at the PR it seems to be implying that the issue was with attackers being able to swap out the default config file from a known location. So my question is what is the difference between the two commands below?

    node --force-fips /path/to/openssl_fips_enabled.cnf
    export OPENSSL_CONF=/path/to/openssl_fips_enabled.cnf

    We are still using the same path so surely an attacker could still modify/change the config file?
    @rvagg perhaps you can explain this to me?

  3. bnoordhuis commented on Jan 23, 2017

    @bnoordhuis
    bnoordhuis
    on Jan 23, 2017
    Member

    The security issue was that node unconditionally loaded a config file. The OPENSSL_CONF variable only influenced where it looked, not if. On Windows, it was in a location that is usually writable by other users.

    Support for OPENSSL_CONF could be brought back. I'm not a huge fan of the side channel nature of environment variables, though.

  4. gdams commented on Jan 23, 2017

    @gdams
    gdams
    on Jan 23, 2017
    Member

    Ahh okay, thanks for clearing that up, The only issue with using a flag is that we are seriously reducing the usability of fips. Not only are we unable to spawn child processes of node (such as in citgm) but I would also imagine that this prevents us from using clusters too?

  5. sam-github commented on Jan 23, 2017

    @sam-github
    sam-github
    on Jan 23, 2017
    Contributor

    Setting OPENSSL_CONF=/dev/null would cause node to not use a conf file.

    Command line flags are difficult to control compared to env vars, the node invocation is often hidden (such as inside a batch or shell script).

    Since it it was windows in particular that doesn't store OpenSSL's conf file in a secure location by default, how about we bring back the default loading of the conf file on non-Windows, and the env var that controls the location?

  6. bnoordhuis commented on Jan 24, 2017

    @bnoordhuis
    bnoordhuis
    on Jan 24, 2017
    Member

    The environment variable might be acceptable but I don't like the idea of a default config file, it's very implicit and un-node-y.

    Meta: I don't understand why FIPS is configurable at runtime in the first place. In order to tick those government contract checkboxes, crypto needs to be locked down with no way to disable or override it. I would have expected separate FIPS-only binaries.

  7. gibfahn commented on Jan 24, 2017

    @gibfahn
    gibfahn
    on Jan 24, 2017
    MemberAuthor

    @bnoordhuis Separate FIPS-only binaries is how it worked in v4, it was changed for v6 as a result of #3819. It might be a discussion we should reconsider, but I guess people want to use their FIPS node binaries to npm install things.

    So are you saying that you're fine with loading an OpenSSL config file if OPENSSL_CONF=/path/to/file is set, but not ok with having a default location that always gets loaded if it exists (like /usr/local/ssl/openssl.cnf).

  8. bnoordhuis commented on Jan 24, 2017

    @bnoordhuis
    bnoordhuis
    on Jan 24, 2017
    Member

    @gibfahn Correct.

    @mhdawson @stefanmb See #10938 (comment) - I have no love for FIPS and it's not my department but doesn't a runtime knob weaken its security guarantees? Perhaps something to reconsider if you agree.

  9. mhdawson commented on Jan 24, 2017

    @mhdawson
    mhdawson
    on Jan 24, 2017
    Member

    @bnoordhuis I started at the same point thinking that you'd just want to know it was on. However, there was strong push from community members who wanted/needed the runtime switch for their use cases and so it was added in 6.x.

  10. mhdawson commented on Jan 24, 2017

    @mhdawson
    mhdawson
    on Jan 24, 2017
    Member

    From the discussion sounds like we have consensus that adding back the option to set the config file with OPENSSL_CONF without any fallback default (ie unless you specify it through env or command line no default file will be opened) . Seems like the next step is to submit a PR for that.

  11. sam-github commented on Jan 24, 2017

    @sam-github
    sam-github
    on Jan 24, 2017
    Contributor

    I'll do that tomorrow.

  12. sam-github commented on Jan 25, 2017

    @sam-github
    sam-github
    on Jan 25, 2017
    Contributor

    #11006

  13. 4 remaining items

  14. sam-github
    closed this as completedin #11006on Feb 9, 2017
  15. sam-github
    added 2 commits that reference this issue on Feb 13, 2017

    crypto: support OPENSSL_CONF again

    4f98413

    crypto: support OPENSSL_CONF again

    a3bf4a2
  16. italoacasas
    added 2 commits that reference this issue on Feb 16, 2017

    crypto: support OPENSSL_CONF again

    a839748

    crypto: support OPENSSL_CONF again

    570c5e1
  17. krydos
    added 2 commits that reference this issue on Feb 25, 2017

    crypto: support OPENSSL_CONF again

    91a712c
  18. sam-github
    added a commit that references this issue on Apr 17, 2017

    crypto: support OPENSSL_CONF again

    b89ea8a
  19. MylesBorins
    added 2 commits that reference this issue on May 16, 2017

    crypto: support OPENSSL_CONF again

    0fc4955

    crypto: support OPENSSL_CONF again

    f8da60f
  20. andrew749
    added a commit that references this issue on Jul 19, 2017

    crypto: support OPENSSL_CONF again

    a89c6bc
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    cryptoIssues and PRs related to the crypto subsystem.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions