Skip to content

/node

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

RFC: support for HSM private keys in TLS handshake #28973

Open
wants to merge 1 commit into
base: master
from
+112 −0

Conversation

@OYTIS
Copy link

commented Aug 5, 2019 •
edited

The use-case is briefly described here: #28921. I want to use a private key managed by an OpenSSL engine to establish a TLS connection.

Another option, sigalgs, is useful, among the other things, to adapt to the limitations of the hardware (e.g. if it doesn't support RSAPSS). I can make it a separate PR if it makes more sense.

Usage example:

tls = require('tls')
tls_ctx = tls.createSecureContext( {'privateKeyEngine':'mycoolengine',
                                    'engineKey':'myenginekey',
                                    'ca':ca_cert,
                                    'cert':client_cert,
                                    'sigalgs' : 'RSA+SHA384:RSA+SHA256'})
socket = tls.connect({'host':'host.domain.tld','port':8080,'secureContext':tls_ctx})

@nodejs-github-bot nodejs-github-bot added C++ lib / src labels Aug 5, 2019

@OYTIS OYTIS force-pushed the OYTIS:hsm_keys branch 2 times, most recently from b020c1b to 33cf16f Aug 5, 2019

@jasnell

This comment has been minimized.

Sign in to view
Copy link
Member

commented Aug 7, 2019

Needs documentation and a unit test

@jasnell jasnell added crypto semver-minor tls labels Aug 7, 2019

@Trott

This comment has been minimized.

Sign in to view
Copy link
Member

commented Aug 8, 2019

@nodejs/crypto
@tniessen

tniessen reviewed Aug 8, 2019
View changes

Show resolved Hide resolved lib/_tls_common.js Outdated
Show resolved Hide resolved lib/_tls_common.js Outdated
Show resolved Hide resolved lib/_tls_common.js Outdated
Show resolved Hide resolved lib/_tls_common.js Outdated
Show resolved Hide resolved lib/_tls_common.js Outdated
Show resolved Hide resolved src/node_crypto.cc Outdated
Show resolved Hide resolved src/node_crypto.cc Outdated
Show resolved Hide resolved src/node_crypto.cc
Show resolved Hide resolved src/node_crypto.cc Outdated
lib/_tls_common.js Outdated
@@ -153,6 +153,38 @@ exports.createSecureContext = function createSecureContext(options) {
}
}

const engineKey = options.engineKey;
const privateKeyEngine = options.privateKeyEngine;
if (engineKey && privateKeyEngine) {

This comment has been minimized.

Sign in to view
Copy link
@tniessen

tniessen Aug 8, 2019

Member

Node.js has traditionally been lazy when it comes to input validation, but new APIs should be stricter: Use !== undefined or something similar to not ignore inputs such as engineKey: 0.

This comment has been minimized.

Sign in to view
Copy link
@tniessen

tniessen Aug 8, 2019

Member

Also, I don't know if it would make sense to validate types even if only one option is given? Or to even throw if only one is given? Is there any use case for only specifying one of these options?

This comment has been minimized.

Sign in to view
Copy link
@OYTIS

OYTIS Aug 10, 2019 •
edited

Author

Is there any use case for only specifying one of these options?

@tniessen From the OpenSSL point of view, you can extract multiple keys from one engine, but since we only have one key in the SecureContext, they should probably go together.

This comment has been minimized.

Sign in to view
Copy link
@tniessen

tniessen Aug 11, 2019

Member

I agree, but I would prefer to throw when only one of the options is given. (Currently, you are ignoring the options if only one is used.) If there is no legitimate use case for only specifying one of the two options, then it is most likely an error or a mistake, and we shouldn't silently ignore that.
@tniessen

This comment has been minimized.

Sign in to view
Copy link
Member

commented Aug 8, 2019

I can't comment much on the matter, maybe @bnoordhuis or @sam-github can, I never used OpenSSL engines. These options would be for server keys then, not for client keys?

The other addition, sigalgs, is completely unrelated, isn't it? Consider splitting these changes into two PRs if you would like. Maybe we should also consider other names for this option.
@OYTIS

This comment has been minimized.

Sign in to view
Copy link
Author

commented Aug 10, 2019 •
edited

@tniessen Thank you for your review, your comments are extremely valuable for a newcomer like myself. I am addressing all of them in the coming version.

These options would be for server keys then, not for client keys?

These options are for the communication party under control of Node.js. If it's a server (which is a more common scenario with Node.js, as far as I know), then it will be server keys, the example in my first comment is rather a client.

@OYTIS OYTIS force-pushed the OYTIS:hsm_keys branch from 33cf16f to 769a786 Aug 11, 2019

@OYTIS

This comment has been minimized.

Sign in to view
Copy link
Author

commented Aug 11, 2019

Fixed hopefully all the issues, added documentation and tests. sigalgs part was removed, another PR is coming
@OYTIS
tls: add an option for keys in OpenSSL engines 
Signed-off-by: Anton Gerasimov <agerasimov@twilio.com>
Loading status checks…
769a786
@vsemozhetbyt

vsemozhetbyt reviewed Aug 11, 2019
View changes

doc/api/tls.md
@@ -1425,6 +1425,11 @@ changes:
passphrase: <string>]}`. The object form can only occur in an array.
`object.passphrase` is optional. Encrypted keys will be decrypted with
`object.passphrase` if provided, or `options.passphrase` if it is not.
* `privateKeyEngine` {string} Name of an OpenSSL engine to get private key
from. Should be use together with `engineKey`, otherwise ignored.

This comment has been minimized.

Sign in to view
Copy link
@vsemozhetbyt

vsemozhetbyt Aug 11, 2019

Contributor

Nit:

Suggested change
from. Should be use together with `engineKey`, otherwise ignored.
from. Should be used together with `engineKey`, otherwise ignored.
@vsemozhetbyt

vsemozhetbyt reviewed Aug 11, 2019
View changes

doc/api/tls.md
* `privateKeyEngine` {string} Name of an OpenSSL engine to get private key
from. Should be use together with `engineKey`, otherwise ignored.
* `engineKey` {string} Identifier of a private key managed by OpenSSL engine.
Should be use together with `privateKeyEngine`, otherwise ignored. Overrides

This comment has been minimized.

Sign in to view
Copy link
@vsemozhetbyt

vsemozhetbyt Aug 11, 2019 •
edited

Contributor

Nit (it seems this needs rewrapping to conform with 80 chars limit):

Suggested change
Should be use together with `privateKeyEngine`, otherwise ignored. Overrides
Should be used together with `privateKeyEngine`, otherwise ignored. Overrides
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@tniessen tniessen

@vsemozhetbyt vsemozhetbyt

Assignees
No one assigned
Labels
C++ crypto lib / src semver-minor tls
Projects
None yet
Milestone
No milestone
6 participants
@OYTIS @jasnell @Trott @tniessen @vsemozhetbyt @nodejs-github-bot
You can’t perform that action at this time.