Application crashes due to error "Couldn't get ecpoint"
Describe the bug My application crashes during TLS 1.3 handshake with below error:
exception error: {badarg,{"ecdh.c",169},"Couldn't get ecpoint"}
in function crypto:compute_key/4 (crypto.erl, line 1811)
*** argument 1: Couldn't get ecpoint
*** (Found in the internal file ecdh.c at line 169)
in call from tls_handshake_1_3:calculate_handshake_secrets/5 (tls_handshake_1_3.erl, line 900)
in call from tls_server_connection_1_3:send_hello_flight/2 (tls_server_connection_1_3.erl, line 535)
in call from tls_server_connection_1_3:negotiated/3 (tls_server_connection_1_3.erl, line 257)
in call from gen_statem:loop_state_callback/11 (gen_statem.erl, line 1395)
in call from tls_server_connection_1_3:init/1 (tls_server_connection_1_3.erl, line 114)
Expected behavior Exception should not lead to application crash
Affected versions 26.2.5.15
Thanks in advance. Need help to understand how this can be handled.
Are you running a FIPS enabled crypto-lib? In such a case this kind of error could occur due to that the filtering out of algorithms not supported by FIPS may not work. See #10312
yes, we are using FIPS enabled crypto-lib. Does this PR #10312 Will resolve this issue. If not how to handle this as this is leading to application crash.
The intent of that PR is to try and solve this. The possible workaround is to find out what algorithms that are available in your OpenSSL version that FIPS disallows and that are enabled in default values for ssl, and then provide your own configuration option to ssl where these algorithms are not present.
I would start checking what ssl:groups(). return on your system.
I'm seeing application crash in Non-FIPS mode as well. Here are the application groups which is same in both FIPS & Non-FIPS mode:
~ # erl
Erlang/OTP 26 [erts-14.2.5.11] [source] [64-bit] [smp:2:2] [ds:2:2:10] [async-threads:1] [jit:ns]
Eshell V14.2.5.11 (press Ctrl+G to abort, type help(). for help)
1> ssl:start().
ok
2> ssl:groups().
[x25519,x448,secp256r1,secp384r1,secp521r1,ffdhe2048,
ffdhe3072,ffdhe4096,ffdhe6144,ffdhe8192]
3>
Is above PR #10312 relevant for Non-FIPS scenario as well ? Also, If you could suggest what else I should check that would be helpful.
-Thanks
No the PR is only relevant for FIPS mode that will forbid some algorithms allowed in normal OpenSSL mode but will not reflect this properly when asked for supported algorithms but rather cause runtime errors. If it fails in normal mode it may be if you have an ECDSA certificate using signing algorithm other than ecdsa_secp521r1_sha512, ecdsa_secp384r1_sha384, ecdsa_secp256r1_sha256 which are the only ECDSA algorithms supported in TLS-1.3.
That should lead to error right ? How can we prevent a crash here even if that is the case . Thanks in advance
Well no it should not crash. I expect that you should get ILLEGAL_PARAMETER alert. Also it is strange because the line numbers in the crash report does not seem to match 26.2.5.15.
Anyway I would try tracing:
dbg:rtracer().
dbg:p(all, [call]).
dbg:tpl(tls_handshake_1_3, calculate_shared_secret, cx).
That should give you the inputs to crypto:compute_key so you can figure out why it does not like them.
Erlang/OTP 26 [erts-14.2.5.11] [source] [64-bit] [smp:2:2] [ds:2:2:10] [async-threads:1] [jit:ns]
Eshell V14.2.5.11 (press Ctrl+G to abort, type help(). for help) 1> dbg:rtracer(). ** exception error: undefined function dbg:rtracer/0 2> dbg:p(all, [call]). {error,no_tracers} 3> dbg:tpl(tls_handshake_1_3, calculate_shared_secret, cx). {ok,[{saved,cx}]} 4>
Here is the output
I made a typo, first command isdbg:tracer(). (there was an r that should not be there, which you might have realized if you had put some more time into reading the error messages).
My bad i didn't realized it. Thanks for pointing it . Here is the output 2> dbg:tracer(). {ok,<0.90.0>} 3> dbg:p(all, [call]). {ok,[{matched,nonode@nohost,45}]} 4> dbg:tpl(tls_handshake_1_3, calculate_shared_secret, cx). {ok,[{matched,nonode@nohost,1},{saved,cx}]} 5>
@vanand123 this just enables the tracing, you now also need to perform a failing connection so that you get results from the tracing. Otherwise there is not much point!