Cannot use EC keys with SSL. #15
Assignees
Labels
Comments
|
could you |
|
|
Sorry, I meant |
|
You should be able to reproduce this locally, FWIW. |
|
Sorry, I think I found it. In the mean time, I guess, that |
|
Then we need to somehow tell OpenSSL that this EVP_PKEY can't do SHA512 signing... |
|
That's what I though and where I don't have any clue right now... |
|
It does actually work with |
|
Try adding |
|
That works for the explicit test, just as But when my VPN client has just been given a PEM which happens to be a TPMv2 key, we need it to happen automatically. I bet we'll need something similar for PKCS#11. In GnuTLS I can indicate which hashes are supported by a given privkey. That's what I'm looking for here. |
|
In OpenSSL configuring the sigalgs is done entirely independently of the EVP_PKEY. There is no concept in libssl of querying the EVP_PKEY to test its ability to handle particular hashes. |
|
We need to fix that if we want OpenSSL to support hardware EC keys. |
|
I've gone through the code once more. We actually don't restrict hash algs during creation. I'm totally puzzled. Could you maybe set a breakpoint it gdb and dump inScheme and digest ? https://github.com/tpm2-software/tpm2-tss-engine/blob/master/src/tpm2-tss-engine-ecc.c#L175 is the place... |
|
Hm? The size here was 64, which is SHA512 — the TPM can't do it. All we really want to do here is tell OpenSSL that this particular EVP_PKEY can't do SHA512, but OpenSSL currently lacks a way to handle that. Hence openssl/openssl#7348 Ultimately there isn't a lot we can do on the ENGINE side until OpenSSL gives us a way to tell it we can't do SHA512, is there? |
|
Oh darn... of course... I was confused again... ;-) @mattcaswell Is there also a way to blacklist a sigalg ? (maybe even within an openssl.cnf file ?) |
AndreasFuchsTPM
added
help wanted
|
Not with openssl.cnf. This has to be an attribute of the EVP_PKEY. I'll take a look, once the other bits we're working on are done. |
|
I was wondering about a workaround for right now (tm), with older versions of OpenSSL. I don't want to require users to enumerate all sigalgs depending on their keytype, but instead want to write something into our readme how to blacklist sha512. (if that's possible) |
It doesn't have to be an attribute of the EVP_PKEY if you are blacklisting it universally. That is possible via openssl.cnf. See the "SignatureAlgorithms" configuration file command on this page: https://www.openssl.org/docs/man1.1.1/man3/SSL_CONF_cmd.html |
As ever, I'm looking at the question of how I make this stuff JustWork™ for users, out of the box. Given that context, I'm not sure how to interpret the above suggestion except that we should tell all OS distributions to change their default openssl.cnf in their packaging to disable SHA512 (and SHA384, as it happens) just in case anyone tries using PKCS#11 or TPM or other ENGINE-based hardware EVP_PKEYs that can't support them. And if that's what you're saying, then it would be better for OpenSSL to change its own defaults, surely? |
My comment was made in the context of @AndreasFuchsSIT's comment:
I'm not suggesting this is the right long term answer. I'm just saying that as a workaround it could be used. |
|
OK, thanks for the clarification. I've just been testing with |
|
I posted openssl/openssl#7408 as an attempt to fix this in OpenSSL. We would need to wire up our end to handle |
|
I note we currently set up neither our own |
|
I lied. Turns out OpenSSL does give us a way to tell it we can't do SHA512. There is a OpenSSL doesn't actually honour that, mind you, but it isn't an ABI change to make it do so; no need for the new method in my original PR and limiting it to newer versions. |
|
@AndreasFuchsSIT I'll let you ensure you have an Arguably if you do that, it should be considered a bug in existing versions of OpenSSL that they then ask you to perform any other kind of signature. And in fact, that bug is fixed in my trees at |
|
This is fixed in OpenSSL master now that openssl/openssl#7408 is merged. This bug is all yours now :) |
|
See #31 for updates |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Ubuntu 18.04, OpenSSL 1.1.0g.
This works:
This doesn't:
When I connect to it (
openssl s_client -connect localhost:8443) I get the following...The text was updated successfully, but these errors were encountered: