ntbtls: TLS handshake error
Closed, InvalidPublic

Description

NTBTLS (master and 0.1.2 as well) fails like:

$ ./ntbtls-cli --debug 1 www.gnupg.org
ntbtls-cli: connected to 'www.gnupg.org' port 443
ntbtls-cli: starting handshake
ntbtls: server_hello, chosen version: [3:3]
ntbtls: server_hello, chosen ciphersuite: 49200 (TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384)
ntbtls: peer certificate: chain length=2
ntbtls: pk_verify returned: success
ntbtls: fetch_input returned: End of file <TLS>
ntbtls: read_record returned: End of file <TLS>
ntbtls-cli: handshake error: End of file <TLS>
ntbtls-cli: handshake failed
$

I encountered this issue on February in Brussels, but I didn't reproduce in Dusseldorf.
Today, in Japan, I encountered it again.
I'm going to make reproducible minimum test case.

gniibe created this task.Apr 10 2020, 7:10 AM

Because it also fails in 0.1.2 (with no GCM support), it seems that it's not GCM thing.

It seems it's a falure of ECDH.
I ran a server by s_server and saw following error:

$ openssl s_server -key key.pem -cert cert.pem -accept 44330 -www
Using default temp DH parameters
ACCEPT
140203176436992:error:10067064:elliptic curve routines:ec_GFp_simple_oct2point:buffer too small:../crypto/ec/ecp_oct.c:280:
140203176436992:error:1419C010:SSL routines:tls_process_cke_ecdhe:EC lib:../ssl/statem/statem_srvr.c:3245:
gniibe closed this task as Invalid.Apr 10 2020, 8:08 AM

It was a problem of libgcrypt master.
As of today's libgcrypt rC60c179b59e53: sexp: Extend gcry_sexp_extract_param with new format specifiers., it works fine.

werner added a subscriber: werner.Apr 10 2020, 12:23 PM

I think I fixed a memory leak on error but no other changes for old code except that the array to old the args now takes void* and not gcry_mpi_t - which does not make a difference.