https://bugs.exim.org/show_bug.cgi?id=2359

            Bug ID: 2359
           Summary: GnuTLS breakage with outgoing TLS 1.3
           Product: Exim
           Version: 4.91
          Hardware: x86
                OS: Linux
            Status: NEW
          Severity: bug
          Priority: high
         Component: TLS
          Assignee: jgh146...@wizmail.org
          Reporter: eximus...@bebt.de
                CC: exim-dev@exim.org

Created attachment 1160
  --> https://bugs.exim.org/attachment.cgi?id=1160&action=edit
First shot at a fix.

Hello,

exim (4.92 rc2) built against gnutls >= 3.6.5 supports TLS 1.3. However while
incoming connections seem to work, outgoing TLS 1.3 is totally broken, mails
are stuck in the queue.
----------------------
16:09:51 23494 cipher: TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256
16:09:51 23494 Have channel bindings cached for possible auth usage.
16:09:51 23494   SMTP>> EHLO argenau.bebt.de
16:09:51 23494 cmd buf flush 22 bytes
16:09:51 23494 tls_write(0x7ffe02af0cd0, 22)
16:09:51 23494 gnutls_record_send(SSL, 0x7ffe02af0cd0, 22)
16:09:51 23494 outbytes=22
16:09:51 23494 Calling gnutls_record_recv(0x559451c5fe30, 0x7ffe02aefcd0, 4096)
16:09:51 23494 GnuTLS<3>: ASSERT: ../../lib/buffers.c[get_last_packet]:1171
16:09:51 23494 GnuTLS<3>: ASSERT:
../../lib/buffers.c[_gnutls_handshake_io_recv_int]:1431
16:09:51 23494 GnuTLS<3>: ASSERT:
../../lib/record.c[_gnutls_recv_in_buffers]:1560
16:09:51 23494 GnuTLS<3>: ASSERT: ../../lib/record.c[_gnutls_recv_int]:1759
16:09:51 23494 tls_read: err from gnutls_record_recv(
16:09:51 23494 LOG: MAIN
16:09:51 23494   H=ellipsis.scootmail.com [217.146.107.185] TLS error on
connection (recv): Resource temporarily unavailable, try again.
16:09:51 23494   SMTP(No such file or directory)<<
16:09:51 23494 tls_close(): shutting down TLS
16:09:51 23494 GnuTLS<3>: ASSERT:
../../lib/buffers.c[_gnutls_io_write_flush]:696
16:09:51 23494   SMTP(close)>>
16:09:51 23494 LOG: MAIN
----------------------

(Thanks, Jeremy Harris, for help with this and providing a test server to
connect to.)

The error seems to be caused by exim regarding gnutls_record_recv() returning a
value <0 as a fatal error, while GNUTLS_E_AGAIN will happen in a normal TLS1.3
connection, due to the changed handshake.
See https://gitlab.com/gnutls/gnutls/issues/644#note_123363338

Attached patch seems to work for, Jeremy said he had tested something
similarily, so we better use his version.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Reply via email to