[gnutls-devel] GnuTLS | GNUTLS error at the end of connection (#1739)
Read-only notification of GnuTLS library development activities
gnutls-devel at lists.gnutls.org
Thu Sep 18 20:54:10 CEST 2025
alavrentiev created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1739
Please consider the following retrieval command:
```
$ curl -vi -X POST -d 'qdata=<?xml version="1.0" encoding="utf-8"?><query_batch version="2.0" xmlns="http://www.crossref.org/qschema/2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><head><doi_batch_id>SCVBID:1426270910:2452:2</doi_batch_id></head><body><query><doi>10.1002/cne.23771</doi></query></body></query_batch>' "https://doi.crossref.org/servlet/query?format=unixref&pid=noreply%40ncbi.nlm.nih.gov"
```
It runs without issues, yet when the retrieval is done with GNUTLS using socket I/O callbacks, it triggers an error when the remote closes the sending end of the connection:
```
</doi_record>
09/18/25 14:52:53 SSOCK#1000[3]@18.205.36.254:443: EOF hit at offset 24398
09/18/25 14:52:53 GNUTLS10: READ: Got 0 bytes from 0x1693330
09/18/25 14:52:53 GNUTLS10: READ: read 0 bytes from 0x1693330
09/18/25 14:52:53 TRACE: GNUTLS error -110(fatal) -> CONNECT GNUTLS status Unknown
09/18/25 14:52:53 TRACE: SSOCK#1000[3]@18.205.36.254:443: The TLS connection was non-properly terminated while reading at offset 24398
```
When the same code is used with mbedTLS and its callbacks, it completes successfully, just as `curl` does:
```
</doi_record>
09/18/25 14:44:28 MBEDTLS2: 0x26d0760: => read
09/18/25 14:44:28 MBEDTLS2: 0x26d0760: => read record
09/18/25 14:44:28 MBEDTLS2: 0x26d0760: => fetch input
09/18/25 14:44:28 MBEDTLS2: 0x26d0760: in_left: 0, nb_want: 5
09/18/25 14:44:28 SSOCK#1000[3]@18.205.36.254:443: EOF hit at offset 24398
09/18/25 14:44:28 MBEDTLS2: 0x26d0760: in_left: 0, nb_want: 5
09/18/25 14:44:28 MBEDTLS2: 0x26d0760: ssl->f_recv(_timeout)() returned 0 (-0x0000)
09/18/25 14:44:28 MBEDTLS1: 0x26d0760: mbedtls_ssl_fetch_input() returned -29312 (-0x7280)
09/18/25 14:44:28 MBEDTLS1: 0x26d0760: ssl_get_next_record() returned -29312 (-0x7280)
09/18/25 14:44:28 TRACE: SSOCK#1000[3]@18.205.36.254:443: Read 0 bytes at offset 24398
09/18/25 14:44:28 TRACE: MbedTlsClose(0x26d0760): Enter
09/18/25 14:44:28 MBEDTLS2: 0x26d0760: => write close notify
09/18/25 14:44:28 MBEDTLS2: 0x26d0760: => send alert message
09/18/25 14:44:28 MBEDTLS3: 0x26d0760: send alert level=1 message=0
09/18/25 14:44:28 MBEDTLS2: 0x26d0760: => write record
09/18/25 14:44:28 MBEDTLS2: 0x26d0760: => encrypt buf
09/18/25 14:44:28 MBEDTLS4: 0x26d0760: dumping 'before encrypt: output payload' (2 bytes)
09/18/25 14:44:28 MBEDTLS4: 0x26d0760: 0000: 01 00 ..
09/18/25 14:44:28 MBEDTLS3: 0x26d0760: dumping 'CID' (0 bytes)
09/18/25 14:44:28 MBEDTLS4: 0x26d0760: dumping 'IV used (internal)' (12 bytes)
09/18/25 14:44:28 MBEDTLS4: 0x26d0760: 0000: dd 92 25 b2 6b 24 cd 49 32 1e 83 46 ..%.k$.I2..F
09/18/25 14:44:28 MBEDTLS4: 0x26d0760: dumping 'IV used (transmitted)' (0 bytes)
09/18/25 14:44:28 MBEDTLS4: 0x26d0760: dumping 'additional data used for AEAD' (5 bytes)
09/18/25 14:44:28 MBEDTLS4: 0x26d0760: 0000: 17 03 03 00 20 ....
09/18/25 14:44:28 MBEDTLS3: 0x26d0760: before encrypt: msglen = 16, including 0 bytes of padding
09/18/25 14:44:28 MBEDTLS4: 0x26d0760: dumping 'after encrypt: tag' (16 bytes)
09/18/25 14:44:28 MBEDTLS4: 0x26d0760: 0000: 40 2c ca 66 7b 6d e6 19 cc f7 62 17 93 d6 8f 6f @,.f{m....b....o
09/18/25 14:44:28 MBEDTLS2: 0x26d0760: <= encrypt buf
09/18/25 14:44:28 MBEDTLS3: 0x26d0760: output record: msgtype = 23, version = [3:3], msglen = 32
09/18/25 14:44:28 MBEDTLS4: 0x26d0760: dumping 'output record sent to network' (37 bytes)
09/18/25 14:44:28 MBEDTLS4: 0x26d0760: 0000: 17 03 03 00 20 b3 f3 9b cb ae c2 01 48 c3 45 43 .... .......H.EC
09/18/25 14:44:28 MBEDTLS4: 0x26d0760: 0010: 5f ef 89 a6 c7 40 2c ca 66 7b 6d e6 19 cc f7 62 _....@,.f{m....b
09/18/25 14:44:28 MBEDTLS4: 0x26d0760: 0020: 17 93 d6 8f 6f ....o
09/18/25 14:44:28 MBEDTLS2: 0x26d0760: => flush output
09/18/25 14:44:28 MBEDTLS2: 0x26d0760: message length: 37, out_left: 37
09/18/25 14:44:28 SSOCK#1000[3]@18.205.36.254:443: Written at offset 1150
#################### [BEGIN] Raw Data (37 bytes):
\27\3\3\0 \263\363\233\313\256\302\1H\303EC_\357\211\246\307@,\312f{m\346\31\314\367b\27\223\326\217o\
#################### [_END_] Raw Data
09/18/25 14:44:28 MBEDTLS2: 0x26d0760: ssl->f_send() returned 37 (-0xffffffdb)
09/18/25 14:44:28 MBEDTLS2: 0x26d0760: <= flush output
09/18/25 14:44:28 MBEDTLS2: 0x26d0760: <= write record
09/18/25 14:44:28 MBEDTLS2: 0x26d0760: <= send alert message
09/18/25 14:44:28 MBEDTLS2: 0x26d0760: <= write close notify
09/18/25 14:44:28 TRACE: MbedTlsClose(0x26d0760): Leave(0)
09/18/25 14:44:28 TRACE: MbedTlsDelete(0x26d0760): Enter
09/18/25 14:44:28 MBEDTLS2: 0x26d0760: => free
09/18/25 14:44:28 MBEDTLS2: 0x26d0760: <= free
09/18/25 14:44:28 TRACE: MbedTlsDelete(0x26d0760): Leave
09/18/25 14:44:28 SSOCK#1000[3]@18.205.36.254:443: Closing (in: 24398 bytes, out: 1187 bytes)
</doi_records>
09/18/25 14:44:28 Closing connection
09/18/25 14:44:28 Completed successfully
09/18/25 14:44:28 TRACE: CORE_SetLOG(0x26cb
```
We think that the remote closing the TCP connection without sending some sort of a TLS message that it's going to do so (an alert?) beforehand somehow upsets GNUTLS, but we don't know much about the intricacies of TLS and would really appreciate if you could take a look as to why GNUTLS can't handle the request above.
Thank you.
--
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1739
You're receiving this email because of your account on gitlab.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20250918/7b2023d1/attachment-0001.html>
More information about the Gnutls-devel
mailing list