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

Support for encrypted PKCS8 or PKCS12 private keys #2834

Closed
ennoucas opened this issue Dec 25, 2022 · 4 comments
Closed

Support for encrypted PKCS8 or PKCS12 private keys #2834

ennoucas opened this issue Dec 25, 2022 · 4 comments
Labels
docs enhancement evaluation needed proposal needs to be validated or tested before fully implementing it in k6 new-http issues that would require (or benefit from) a new HTTP API

Comments

@ennoucas
Copy link

Feature Description

Hello, encrypted pkcs8 and pkcs12 keys are the only format available in my company. When do you think this will become available with k6? Or do you have any other way / library / extension to make it work with k6 already?

Thanks,
Lucas

Suggested Solution (optional)

No response

Already existing or connected issues / PRs (optional)

No response

@na--
Copy link
Member

na-- commented Jan 3, 2023

Please explain your use case in detail. What exactly do you mean by "Support for encrypted PKCS8 or PKCS12 private keys"? Support where? What do you want to do with these keys?

If it's about making requests with such client keys, I think the tlsAuth option already supports them, though I am not 100% sure. Unfortunately, it is only globally configurable (#2186), so it's not very flexible 😞

Or do you want to encrypt/decrypt arbitrary data with such keys during the k6 script execution? If so, we are already working on implementing the WebCrypto APIs in k6 in https://github.com/grafana/xk6-webcrypto. That extension will likely be merged as a built-in k6/experimental module in the not-too-distant future, so it might suit your needs 🤞

Or do you want to do something else with such keys? 😅 Please elaborate with your specific use case and needs.

@na-- na-- added evaluation needed proposal needs to be validated or tested before fully implementing it in k6 awaiting user waiting for user to respond labels Jan 3, 2023
@ennoucas
Copy link
Author

ennoucas commented Jan 3, 2023

Hi,
If you try to use encrypted PKCS8 cert with tlsAuth option you'll get an error saying k6 does not support encrypted private keys.
If you try to use PKCS12 with tlsAuth it does not work either.

I want to be able to do api calls with the certs provided by my company that only provide these formats. There's not a lot of documentation on what type of certification is permitted with tlsAuth option.

@na--
Copy link
Member

na-- commented Jan 3, 2023

Ah, I see, this is the relevant part of the k6 code:

k6/lib/options.go

Lines 166 to 169 in d81bb41

blockType := block.Type
if blockType == "ENCRYPTED PRIVATE KEY" {
return nil, fmt.Errorf("encrypted pkcs8 formatted key is not supported")
}

It was added in #2488 and the limitation seems quite intentional. I think it is because the Go standard library doesn't have support for it, and probably doesn't plan to add support for it any time soon, see golang/go#8860 🤔

Not sure we'd want to import some custom library just to deal with this corner case... Maybe it will be better to solve #2186 and rely on WebCrypto's ability to decode PKCS8 keys 🤔

In any case, until this issue is solved in either way, it seems like k6 only supports private keys that are encrypted like this, though I am unsure how you can convert your keys to that format, sorry:

k6/lib/options_test.go

Lines 336 to 345 in d81bb41

name: "encrypted key and valid password",
privateKey: "-----BEGIN EC PRIVATE KEY-----\n" +
"Proc-Type: 4,ENCRYPTED\n" +
"DEK-Info: AES-256-CBC,DF2445CBFE2E5B112FB2B721063757E5\n" +
"o/VKNZjQcRM2hatqUkQ0dTolL7i2i5hJX9XYsl+TMsq8ZkC83uY/JdR986QS+W2c\n" +
"EoQGtVGVeL0KGvGpzjTX3YAKXM7Lg5btAeS8GvJ9S7YFd8s0q1pqDdffl2RyjJav\n" +
"t1jx6XvLu2nBrOUARvHqjkkJQCTdRf2a34GJdbZqE+4=\n" +
"-----END EC PRIVATE KEY-----",
password: "12345",
hasError: false,

@na-- na-- added enhancement docs new-http issues that would require (or benefit from) a new HTTP API and removed feature awaiting user waiting for user to respond labels Jan 3, 2023
@imiric
Copy link
Contributor

imiric commented Mar 28, 2023

This will be solved by the WebCrypto extension, and won't be implemented in core k6. Recently decryption was added for AES keys, and support for PKCS formats is on the roadmap.

Since tlsAuth is a global option, it wouldn't work with the WebCrypto API as you'd want to decrypt these keys during script execution, so such TLS configuration will be part of the new HTTP API (initial design document), which we're starting to work on now.

I'll close this issue, so please follow the development of the WebCrypto extension, and suggest any features in its repo, as well as the new HTTP API developments.

@imiric imiric closed this as not planned Won't fix, can't repro, duplicate, stale Mar 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs enhancement evaluation needed proposal needs to be validated or tested before fully implementing it in k6 new-http issues that would require (or benefit from) a new HTTP API
Projects
None yet
Development

No branches or pull requests

3 participants