[gnutls-help] Bug#964284: guile-gnutls: update to use guile 3.0

Tue Dec 8 17:56:56 CET 2020

Hi,

(+Cc: gnutls-help.  This is about the failure of
‘guile/tests/reauth.scm’ observed on Debian.)

Thanks Rob & Vagrant.  The debugging output Vagrant posted reads:

--8<---------------cut here---------------start------------->8---
[10219|3] Peer requested CA: CN=GNUTLS TEST SERVER,OU=GNUTLS,O=FSF,C=GR
[10219|3] Peer requested CA: CN=GNUTLS INTERMEDIATE TEST CA,OU=GNUTLS,O=FSF,C=GR
[10219|4] checking cert compat with RSA-SHA256
[10219|3] ASSERT: ../../../lib/ext/signature.c[_gnutls_session_sign_algo_enabled]:433
[10219|4] Signature algorithm RSA-SHA256 is not enabled
[10219|4] checking cert compat with RSA-PSS-SHA256
[10219|4] 
throw to `gnutls-error' with args (#<gnutls-error-enum Public key signing has failed.> read_from_session_record_port)
checking cert compat with RSA-PSS-RSAE-SHA256
[10219|4] HSK[0x55c505382030]: CERTIFICATE was queued [693 bytes]
[10219|5] REC[0x55c505382030]: Preparing Packet Handshake(22) with length: 693 and min pad: 0
[10219|5] REC[0x55c505382030]: Sent Packet[8906] Handshake(22) in epoch 2 and length: 715
[10219|4] HSK[0x55c505382030]: signing TLS 1.3 handshake data: using RSA-PSS-RSAE-SHA256 and PRF: SHA384
[10219|3] ASSERT: ../../../lib/nettle/pk.c[_rsa_pss_sign_digest_tr]:805
[10219|3] ASSERT: ../../../lib/nettle/pk.c[_wrap_nettle_pk_sign]:1177
[10219|3] ASSERT: ../../../lib/nettle/pk.c[_wrap_nettle_pk_sign]:1190
[10219|3] ASSERT: ../../lib/privkey.c[privkey_sign_and_hash_data]:1300
[10219|3] ASSERT: ../../lib/tls13-sig.c[_gnutls13_handshake_sign_data]:205
[10219|3] ASSERT: ../../lib/tls13/certificate_verify.c[_gnutls13_send_certificate_verify]:210
[10219|3] ASSERT: ../../lib/tls13/post_handshake.c[_gnutls13_reauth_client]:117
[10219|3] ASSERT: ../../lib/handshake-tls13.c[_gnutls13_recv_async_handshake]:661
[10219|3] ASSERT: ../../lib/record.c[record_add_to_buffers]:1016
[10219|3] ASSERT: ../../lib/record.c[_gnutls_recv_in_buffers]:1578
[10219|3] ASSERT: ../../lib/record.c[_gnutls_recv_int]:1776
--8<---------------cut here---------------end--------------->8---

When uncommenting the debugging output statements in ‘tests/reauth.scm’
(and only then!), I can reproduce the bug, though it is not
systematically in the same spot.

In all cases, it’s the client failing to reauthenticate.  One example is
‘_nettle_rsa_sec_compute_root_tr’ returning 0 and thus leading to
GNUTLS_E_PK_SIGN_FAILED as we see above.  The client’s stack at that
point looks like this:

--8<---------------cut here---------------start------------->8---
(rr) bt
#0  _nettle_rsa_sec_compute_root_tr (pub=pub at entry=0x7ffe9499aed0, key=key at entry=0x7ffe9499af00, random_ctx=random_ctx at entry=0x0, random=random at entry=0x7f4535ff91e0 <rnd_nonce_func>, 
    x=x at entry=0x7f4534ff4e00, m=0x7f4534ff4e80, mn=16) at rsa-sign-tr.c:319
#1  0x00007f4535e37a74 in nettle_rsa_compute_root_tr (pub=pub at entry=0x7ffe9499aed0, key=key at entry=0x7ffe9499af00, random_ctx=random_ctx at entry=0x0, 
    random=random at entry=0x7f4535ff91e0 <rnd_nonce_func>, x=x at entry=0x7ffe9499aec0, m=m at entry=0x7ffe9499ae30) at rsa-sign-tr.c:365
#2  0x00007f4535e38de0 in nettle_rsa_pss_sha256_sign_digest_tr (pub=0x7ffe9499aed0, key=0x7ffe9499af00, random_ctx=0x0, random=0x7f4535ff91e0 <rnd_nonce_func>, salt_length=<optimized out>, 
    salt=0xb98230 "\221\251\260\307\351\300\226\326,o\343\303\001\213\340YT\027\023\227\327\004\065\247\374Kje\177C\024_ending eQ", 
    digest=0xb32e70 "\233\255U\366\235I\001\372}\356\261r\257\213b\316\376\fkh\253X", s=0x7ffe9499aec0) at rsa-pss-sha256-sign-tr.c:59
#3  0x00007f4535ffb709 in _rsa_pss_sign_digest_tr (rnd_ctx=0x0, rnd_func=0x7f4535ff91e0 <rnd_nonce_func>, s=0x7ffe9499aec0, digest=<optimized out>, salt_size=<optimized out>, 
    priv=0x7ffe9499af00, pub=0x7ffe9499aed0, dig=<optimized out>) at pk.c:807
#4  _wrap_nettle_pk_sign (algo=<optimized out>, signature=0x7ffe9499b170, vdata=<optimized out>, pk_params=<optimized out>, sign_params=<optimized out>) at pk.c:1175
#5  0x00007f4535f4b374 in privkey_sign_and_hash_data (signer=0xb823a0, se=0x7f4536093a20 <sign_algorithms+224>, data=<optimized out>, signature=0x7ffe9499b170, params=0x7ffe9499b020)
    at privkey.c:1296
#6  0x00007f4535f4b658 in gnutls_privkey_sign_data2 (signer=signer at entry=0xb823a0, algo=<optimized out>, flags=flags at entry=0, data=data at entry=0x7ffe9499b090, 
    signature=signature at entry=0x7ffe9499b170) at privkey.c:1194
#7  0x00007f4535f61203 in _gnutls13_handshake_sign_data (session=session at entry=0xb893d0, cert=<optimized out>, pkey=0xb823a0, context=0x7f4536089200 <cli_ctx>, 
    signature=signature at entry=0x7ffe9499b170, se=se at entry=0x7f4536093a20 <sign_algorithms+224>) at tls13-sig.c:207
#8  0x00007f4535f608db in _gnutls13_send_certificate_verify (session=session at entry=0xb893d0, again=<optimized out>) at tls13/certificate_verify.c:206
#9  0x00007f4535f65305 in _gnutls13_reauth_client (session=0xb893d0) at tls13/post_handshake.c:115
#10 gnutls_reauth (session=session at entry=0xb893d0, flags=flags at entry=0) at tls13/post_handshake.c:251
#11 0x00007f4535f17a9d in _gnutls13_recv_async_handshake (session=session at entry=0xb893d0) at handshake-tls13.c:657
#12 0x00007f4535f117e2 in record_add_to_buffers (recv=0x7ffe9499b320, bufel=0xb84620, seq=0, htype=4294967295, type=GNUTLS_APPLICATION_DATA, session=0xb893d0) at record.c:1013
#13 _gnutls_recv_in_buffers (session=session at entry=0xb893d0, type=type at entry=GNUTLS_APPLICATION_DATA, htype=htype at entry=4294967295, ms=<optimized out>, ms at entry=0) at record.c:1570
#14 0x00007f4535f12221 in _gnutls_recv_int (session=0xb893d0, type=GNUTLS_APPLICATION_DATA, data=0x7f4535c06290 ".rtl-text", data_size=1, seq=0x0, ms=0) at record.c:1773
#15 0x00007f45360a61d6 in read_from_session_record_port (port=<optimized out>, dst=<optimized out>, start=<optimized out>, count=1) at core.c:1051
#16 0x00007f4539f1d280 in scm_i_read_bytes () from /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2/lib/libguile-3.0.so.1
--8<---------------cut here---------------end--------------->8---

It looks as though the public or private key were corrupt, but nothing
obvious.

Unfortunately, there doesn’t seem to be a similar test case in C.  The
closest one is ‘tls12-rehandshake-cert-auto’, but it uses anonymous
certificates and different priority strings.

Ideas for further debugging would be welcome!

Ludo’.