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.
_______________________________________________ Gnutls-devel mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnutls-devel
