ECDH TLS groups support in Keymgmt #395
Comments
|
I am trying to reproduce this error without success. What confuses me a little is why you give "server" labeled certs and key to the s_client, while use req_client.crt in the server ... What do you need keys for in the client? I get another fatal error unfortunately due to the fact ssh_handshake_hash in openssl relies on being able to copy digest contexts, which is not really support by any pkcs#11 token (even though it is in theory via status operations ... |
|
Hi @simo5, Sorry my mistake, but it's just a naming related issue, if you want, I can change the description. Yes, we are trying TLS mutual authentication, hence client certificate is required. Server*file contains ECDSA key and it has been generated using below command:- Which tool you are using with pkcs#11 token? I am using pkcs11-tool. |
|
I am just reusing the certs we generate for the tests, so whatever I have handy, it's either softokn or softhsm. Ok I realized it was mutual TLS later on, but was diverted to fix other issues, I will retry with mutual to see if that triggers the specific issue you see. |
|
What version of openssl are you testing with? |
|
I am testing it on openssl 3.2.1 version. |
|
I have used the same commands you did, just with prime256v1 as the named_curve, however I need to ensure a proper set of CA signed certs, to exclude the possibility that failed verification makes openssl take different code paths. In the process I found different issues which I am fixing in #408 so i is also possible that different behavior is triggered by different mechanisms being available between softoken and your token, as some of the operations are conditionally exposed based on the mechanisms returned by the token. |
|
@kshitizvars I have a patch I was testing at some point that might address some of your problem, any chance you want to test it? |
|
Hi @simo5, I am getting below issue while compiling your simo5@75cc2c3 repo with yocto:- Used devtool command for changing source code:- The token I am using supports below mechanism: - So, will I get this issue on my end? |
|
not sure what devtool is, but it is trying to use autotools when the project has moved to meson ... |
|
[Hi] @Simo, We are trying to check whether key exchange operations are getting offloaded to pkcs11-provider, for this we have added logs in src/exchange.c functions but seems like no function is getting hit. We are using ECDHE-ECDSA-AES128-GCM-SHA256 cipher suite with tls1.2. Can you please take a look? diff_patch.txt Commands used:- Client side:- |
|
Are you still forcing the use of pkcs11 provider via |
|
Hi @simo5 I have tried running below command on server side:-
and below command on client side:- Getting Segmentation fault error on server side And client side stops abruptly. Also tried adding provider in default properties like below in openssl.cnf file:- But still getting the same segmentation fault. Seems like there is some issue in pkcs11-provider. Can you please comment on this. debug logs:- |
|
It would be nice if you could run the server in gdb --args and capture a backtrace so we can see where it fails. |
|
Hi @simo5, Please find the below backtrace of openssl s_server command:- |
|
I have used your repo with PR #408, I was able to resolve seg fault issue with your changes, after doing some changes in recipe file:- Now, I am not getting any segmentation fault, but still not able to offload key exchange operations (ECDHE) on pkcs11-provider code. Btw, I have also applied simo5@75cc2c3 patch on the top of above seg fault related changes, but still no luck. debug logs:- |
|
The log ends with a successful signature and no other operations, would you be able to provide a minimal reproducer, perhaps a script and instructions on how to set up the Tee ? |
|
Hi @simo5, For TEE build steps, follow https://optee.readthedocs.io/en/latest/building/index.html. Conf changes:- Commands Used:- |
|
Hi @simo5, Any update on this? |
|
Sorry I am caught up on other things at the moment, I will try to get to this soonish, thanks for the instructions, should make things simpler to try to reproduce and then find the actual issue. |
|
Hi @simo5, Server side command:- Client side command:- Getting segmentation fault. GDB trace:- |
|
Hi @simo5 During debugging, I have some observations to share:-
Server side:- client side:- Issue observed:- Logs:- whereas no issue is observed when we run it without provider.
Please share your observations on the same. |
|
Hi @simo5 any updates? |
|
I tried looking into this and reproducing the issue, but I did not see any crashes when running against either of the three software tokens we have. I created a reproducer based on your configuration in #422, where it works as expected until I add the following configuration snippet, which forces all operations to the token: then it starts failing on the problems with signatures using RSA-PSS: Looking into that a bit further (in kryoptic run), it goes a bit further, managing to create signature, but fails to verify it (or some other?): Not sure if I got into another different rabbit hole or it is something you/Simo saw before. |
|
The debug log you posted has a path |
|
Hi @Jakuje , |
|
Hi @simo5 @Jakuje ,
Is our observation correct? |
|
Yes, at the moment we can set OSSL_PKEY_PARAM_ENCODED_PUBLIC_KEY but it cannot be retrieved, that will have to be fixed. |
|
Ok #423 should address returning OSSL_PKEY_PARAM_ENCODED_PUBLIC_KEY |
|
@kshitizvars you are correct, we focused first on Asymmetric algorithms which are what is commonly used from Hardware tokens. |
|
Hi @simo5 We are able to run ECDH key exchange operations on tls1.2, but facing some issues in tls1.3. On further debugging, it is because of wrong client public key point (EC_POINT) and its length:- TLS1.3 logs TLS1.2 logs Do you have any comments? |
|
@kshitizvars sounds like this is a new issue, do you mind if we close this current bug as resolved and open a new bug for the latter issue? Looking at the log I see that the last few steps for both cases are similar until the crash, but in the TLS 1.3 I also see different steps before getting to the ECDH derive. If you can open a new bug about the crash specifically and provide me a reproducer script (openssl commands with s_client and s_server like before is fine) I can investigate what is happening. |
|
Sure, you can close this bug. opened #437 new issue with more details. |
|
Thanks! |
Hi
This is my openssl.cnf after applying EVP configuration:-
Server side command:-
openssl s_server -key "pkcs11:model=OP-TEE%20TA;manufacturer=Linaro;serial=0000000000000000;token=kshitiz_test;id=%02;object=ecc-key-521;type=private?pin-value=1234" -cert req_client.crt -accept 443 -Verify 3 -named_curve secp521r1 -ciphersuites 'TLS_AES_256_GCM_SHA384' -tls1_3Client side command:-
./openssl s_client -connect 10.232.132.242:443 -tls1_3 -ciphersuites 'TLS_AES_256_GCM_SHA384' -cert server.crt -key server.key -CAfile ../ca.crtError recieved on server side:-
Am I doing something wrong here? And one more thing, that if we are able to reach to optee in sign verification operation without applying EVP configuration change, so why this change is required for exchange operation? Any specific reason?
Originally posted by @kshitizvars in #389 (reply in thread)
The text was updated successfully, but these errors were encountered: