Re: [exim] GnuTTS woes
On 2022-09-30, Jeremy Harris via Exim-users wrote: > On 30/09/2022 09:11, Jasen Betts via Exim-users wrote: >> Testssl.sh primes its ALPN requests based on the port number used > > What does it use for 25/465/567 ? I don't know of an actual Standard; > I just picked the obvious for Exim. I think nothing, I have not checked the source. testssl also does replays of stored "TLS Hello"s representing several different browsers they will have whatever ALPN was recorded when they were created. Further IP addresses: 2400:8907::f03c:93ff:fe2d:f557 rDNS (172.105.179.7): 172-105-179-7.ip.linodeusercontent.com. Service detected: Couldn't determine what's running on port 465, assuming no HTTP service => skipping all HTTP checks Testing protocols via sockets except NPN+ALPN SSLv2 not offered (OK) SSLv3 not offered (OK) It seems mostly focussed on testing web servers, It seems to be built around openssl (command line) and does support starttls for the same protocols supported by openssl. -- Jasen. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] OpenSSL IOT woes
On Fri, Sep 30, 2022 at 09:18:08PM +0100, Jeremy Harris via Exim-users wrote: > On 30/09/2022 20:28, Viktor Dukhovni via Exim-users wrote: > > Does "s_client -tls1_1 -cipher ALL:@SECLEVEL=0" work? Let's first > > sort that out. > > It does not. The same Fatal Alert. Presumably it'll work for you if you connect to: [dnssec-stats.ant.isi.edu]:25 The relevant software versions are: $ rpm -q postfix openssl postfix-3.6.4-1.fc36.x86_64 openssl-3.0.5-1.fc36.x86_64 And indeed Postfix is linked against OpenSSL 3.x: $ ldd /usr/libexec/postfix/smtpd ... libssl.so.3 => /lib64/libssl.so.3 (0x7fdc3588f000) libcrypto.so.3 => /lib64/libcrypto.so.3 (0x7fdc35467000) ... So the barrier is some interaction between Exim and OpenSSL that makes TLS 1.0 and 1.1 unavailable. Clients that don't support TLS 1.2 are of course increasingly rare, but pockets of holdouts still linger on... -- Viktor. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] OpenSSL IOT woes
On 30/09/2022 20:28, Viktor Dukhovni via Exim-users wrote: Does "s_client -tls1_1 -cipher ALL:@SECLEVEL=0" work? Let's first sort that out. It does not. The same Fatal Alert. -- Cheers, Jeremy -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] OpenSSL IOT woes
On Fri, Sep 30, 2022 at 08:14:20PM +0100, Jeremy Harris via Exim-users wrote: > > Does its cipherlist end with ":@SECLEVEL=0" (or does it explicitly > > set the security level via the OpenSSL API). > > The latter. > > I can add calls to read out bit of setup just before SSL_accept, if you > can suggest one. I'm out of ideas. All I can say with certainty is that underlying OpenSSL library (Fedora36 OpenSSL 3.0.5, same as yours I think) is perfectly happy to do TLS 1.1 when SECLEVEL=0. Why that's not happening with Exim is outside my area of expertise. > If it matters: I'm using the OP's very minimal Client Hello, > not s_client. Does "s_client -tls1_1 -cipher ALL:@SECLEVEL=0" work? Let's first sort that out. -- Viktor. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] OpenSSL IOT woes
On 30/09/2022 19:17, Viktor Dukhovni via Exim-users wrote: openssl_options = -no_sslv3 -no_tlsv1_1 -no_tlsv1 doesn't change the result. That sets a floor, rather than clearing it. You're explicitly turning off SSL 3.0, TLS 1.0 and TLS 1.1. No. This is the exim option not an s_client option; +no_sslv3 would be setting that bit (and thereby disallowing sslv3). -no_sslv3 clears the bit. Here's the processing going on: 19:51:24 64677 openssl option, removing from 42004000: 0200 (no_sslv3 -no_tlsv1_1 -no_tlsv1) 19:51:24 64677 openssl option, removing from 40004000: 1000 (no_tlsv1_1 -no_tlsv1) 19:51:24 64677 openssl option, removing from 40004000: 0400 (no_tlsv1) The result from that is fed to SSL_CTX_set_options(). Do you have a test server reachable from the Internet that's running the version of Exim in question over OpenSSL? Unfortunately no; this is my devel laptop. Does its cipherlist end with ":@SECLEVEL=0" (or does it explicitly set the security level via the OpenSSL API). The latter. I can add calls to read out bit of setup just before SSL_accept, if you can suggest one. If it matters: I'm using the OP's very minimal Client Hello, not s_client. -- Cheers, Jeremy -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] OpenSSL IOT woes
On Fri, Sep 30, 2022 at 07:05:52PM +0100, Jeremy Harris via Exim-users wrote: > On 30/09/2022 18:34, Viktor Dukhovni via Exim-users wrote: > > Do you also have a TLS version floor? "protocol version" sure sounds > > like it. > > Not as far as I know, and >openssl_options = -no_sslv3 -no_tlsv1_1 -no_tlsv1 > doesn't change the result. That sets a floor, rather than clearing it. You're explicitly turning off SSL 3.0, TLS 1.0 and TLS 1.1. > There is indeed a "protocol version" fatal alert sent according to > wireshark. That's what it looks like. > > Anyway, this is perhaps a distraction from the GnuTLS issue, > > which you've identifies IIRC (SSL 3.0-compatible handshake with no TLS > > extensions fails against Exim + GnuTLS as reported). > > While it's true the Exim bug with GnuTLS is now fixed, having the > regression test passing for both the TLS libraries we claim to support > would be good. $subject changed to reflect that. Do you have a test server reachable from the Internet that's running the version of Exim in question over OpenSSL? Does its cipherlist end with ":@SECLEVEL=0" (or does it explicitly set the security level via the OpenSSL API). The Postfix server on the DANE survey host linked with OpenSSL 3.0.5 (Fedora 36) completes a TLS 1.1 handshake just fine: $ openssl s_client -quiet -starttls smtp -tls1_1 -cipher "ALL:@SECLEVEL=0" -connect $(uname -n):25 depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = R3 verify return:1 depth=0 CN = dnssec-stats.ant.isi.edu verify return:1 250 CHUNKING quit 221 2.0.0 Bye An Exim server linked with OpenSSL 3.0.5 should be able to do likewise, barring protocol version floors, cipherlists that exclude SHA1, ... -- Viktor. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
[exim] OpenSSL IOT woes
On 30/09/2022 18:34, Viktor Dukhovni via Exim-users wrote: Do you also have a TLS version floor? "protocol version" sure sounds like it. Not as far as I know, and openssl_options = -no_sslv3 -no_tlsv1_1 -no_tlsv1 doesn't change the result. There is indeed a "protocol version" fatal alert sent according to wireshark. Anyway, this is perhaps a distraction from the GnuTLS issue, which you've identifies IIRC (SSL 3.0-compatible handshake with no TLS extensions fails against Exim + GnuTLS as reported). While it's true the Exim bug with GnuTLS is now fixed, having the regression test passing for both the TLS libraries we claim to support would be good. $subject changed to reflect that. -- Cheers, Jeremy -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] GnuTTS woes
On Fri, Sep 30, 2022 at 06:02:35PM +0100, Jeremy Harris via Exim-users wrote: > On 30/09/2022 16:46, Viktor Dukhovni via Exim-users wrote: > >> 00C0C6000800:error:0A0C0103:SSL > >> routines:tls_process_key_exchange:internal > >> error:ssl/statem/statem_clnt.c:2254: > >> > >> I'll try to find some time to file a bug. Feel free to beat me to it. > > > Actually, this is expected behaviour: > > > > https://github.com/openssl/openssl/issues/15335#issuecomment-843843617 > > Including that error line? > > > No obvious difference with that "ciphers" :- > > 17:39:23 59777 SMTP>> 220 TLS go ahead > 17:39:23 59777 Calling SSL_accept > 17:39:23 59777 SSL hshake_start: before SSL initialization > 17:39:23 59777 SSL SSL_accept,state_chg: before SSL initialization > 17:39:23 59777 SSL SSL_accept,state_chg: before SSL initialization > 17:39:23 59777 SSL write,alert fatal:protocol version > 17:39:23 59777 SSL SSL_accept,hshake_exit: error in error > 17:39:23 59777 TLS error '(SSL_accept): error:100C0102:BIO routines::passed a > null parameter' Do you also have a TLS version floor? "protocol version" sure sounds like it. Anyway, this is perhaps a distraction from the GnuTLS issue, which you've identifies IIRC (SSL 3.0-compatible handshake with no TLS extensions fails against Exim + GnuTLS as reported). -- Viktor. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] GnuTTS woes
On 30/09/2022 16:46, Viktor Dukhovni via Exim-users wrote: 00C0C6000800:error:0A0C0103:SSL routines:tls_process_key_exchange:internal error:ssl/statem/statem_clnt.c:2254: I'll try to find some time to file a bug. Feel free to beat me to it. Actually, this is expected behaviour: https://github.com/openssl/openssl/issues/15335#issuecomment-843843617 Including that error line? No obvious difference with that "ciphers" :- 17:39:23 59777 SMTP>> 220 TLS go ahead 17:39:23 59777 Calling SSL_accept 17:39:23 59777 SSL hshake_start: before SSL initialization 17:39:23 59777 SSL SSL_accept,state_chg: before SSL initialization 17:39:23 59777 SSL SSL_accept,state_chg: before SSL initialization 17:39:23 59777 SSL write,alert fatal:protocol version 17:39:23 59777 SSL SSL_accept,hshake_exit: error in error 17:39:23 59777 TLS error '(SSL_accept): error:100C0102:BIO routines::passed a null parameter' The lines starting "SSL " are SSL_CTX_set_info_callback() events; the "error in error" is a ret<0 with SSL_state_string_long() of "error" (not very helpful). The "TLS error" is a <=0 from SSL_accept() with SSL_get_error() being SSL_ERROR_SSL; the "null param" bit could have been directly from that error or could have been from earlier. -- Cheers, Jeremy -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] GnuTTS woes
On Fri, Sep 30, 2022 at 11:23:47AM -0400, Viktor Dukhovni via Exim-users wrote: > I just reproduced the problem with a fresh build of 3.0.6-dev from > github (built on FreeBSD 12.3): > > $ LD_LIBRARY_PATH=/var/tmp/openssl/lib /var/tmp/openssl/bin/openssl > s_client -starttls smtp -tls1_1 -quiet -connect localhost:25 > Can't use SSL_get_servername > depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1 > verify error:num=20:unable to get local issuer certificate > verify return:1 > depth=1 C = US, O = Let's Encrypt, CN = R3 > verify return:1 > depth=0 CN = <...> > verify return:1 > 00C0C6000800:error:0A0C0103:SSL > routines:tls_process_key_exchange:internal > error:ssl/statem/statem_clnt.c:2254: > > I'll try to find some time to file a bug. Feel free to beat me to it. Actually, this is expected behaviour: https://github.com/openssl/openssl/issues/15335#issuecomment-843843617 To get SHA1 ciphers to work, one needs to set the security level to 0. $ openssl s_client -quiet -starttls smtp -tls1_1 -cipher "ALL:@SECLEVEL=0" -connect $(uname -n):25 depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = R3 verify return:1 depth=0 CN = <...> verify return:1 250 CHUNKING quit 221 2.0.0 Bye Jeremy, if you retry with "@SECLEVEL=0", you should see OpenSSL work as expected. -- Viktor. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] GnuTTS woes
On Fri, Sep 30, 2022 at 11:05:57AM -0400, Viktor Dukhovni via Exim-users wrote: > > Clearing either no_tlsv1_1 or no_sslv3 has no effect. > > Of course, if there's no support, the CLI flags don't matter. TLS 1.1 does > not work with OpenSSL 3.0.5, Though it looks more like a bug to me: > > $ openssl s_client -quiet -starttls smtp -tls1_1 -connect $(uname -n):25 > depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1 > verify return:1 > depth=1 C = US, O = Let's Encrypt, CN = R3 > verify return:1 > depth=0 CN = dnssec-stats.ant.isi.edu > verify return:1 > C0A1EBA5F27F:error:0A0C0103:SSL > routines:tls_process_key_exchange:internal > error:ssl/statem/statem_clnt.c:2252: I just reproduced the problem with a fresh build of 3.0.6-dev from github (built on FreeBSD 12.3): $ LD_LIBRARY_PATH=/var/tmp/openssl/lib /var/tmp/openssl/bin/openssl s_client -starttls smtp -tls1_1 -quiet -connect localhost:25 Can't use SSL_get_servername depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1 verify error:num=20:unable to get local issuer certificate verify return:1 depth=1 C = US, O = Let's Encrypt, CN = R3 verify return:1 depth=0 CN = <...> verify return:1 00C0C6000800:error:0A0C0103:SSL routines:tls_process_key_exchange:internal error:ssl/statem/statem_clnt.c:2254: I'll try to find some time to file a bug. Feel free to beat me to it. -- Viktor. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] GnuTTS woes
On Fri, Sep 30, 2022 at 03:48:18PM +0100, Jeremy Harris via Exim-users wrote: > OpenSSL 3.0.5 5 Jul 2022running on Fedora 36 > > I think using the distro standard package > openssl-1:3.0.2-4.fc36.x86_64 > (though I note the numbers don't exactly line up) > > The failure mode is a TLS Alert complaining about version > (I forget the precise wording, sorry) > and followed by what looks like a library internal bug-triggered > error for a BIO operation error. > > Clearing either no_tlsv1_1 or no_sslv3 has no effect. Of course, if there's no support, the CLI flags don't matter. TLS 1.1 does not work with OpenSSL 3.0.5, Though it looks more like a bug to me: $ openssl s_client -quiet -starttls smtp -tls1_1 -connect $(uname -n):25 depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = R3 verify return:1 depth=0 CN = dnssec-stats.ant.isi.edu verify return:1 C0A1EBA5F27F:error:0A0C0103:SSL routines:tls_process_key_exchange:internal error:ssl/statem/statem_clnt.c:2252: Things work better with TLS 1.2: $ openssl s_client -quiet -starttls smtp -tls1_2 -connect $(uname -n):25 depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = R3 verify return:1 depth=0 CN = dnssec-stats.ant.isi.edu verify return:1 250 CHUNKING QUIT 221 2.0.0 Bye If this is still broken in 3.0.6-dev, a bug report may be appropriate. -- Viktor. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] GnuTTS woes
On 30/09/2022 15:48, Jeremy Harris wrote: OpenSSL 3.0.5 5 Jul 2022 running on Fedora 36 I think using the distro standard package openssl-1:3.0.2-4.fc36.x86_64 (though I note the numbers don't exactly line up) Correction: openssl-1:3.0.5-1.fc36.x86_64 probably from the Fedora "updates" repo. -- Cheers, Jeremy -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] GnuTTS woes
On Fri, Sep 30, 2022 at 02:09:19PM +0200, Cyborg via Exim-users wrote: > My POV here: "why waiting". Encryption doesn't slow down todays cpus > anymore as it has 15 years ago, same for a smartphone soc. Mobile devices have batteries, and large RSA keys have a real packet size and latency cost. Keys larger than 2048-bits are largely futile. No plausible classical attack can brute-force them. Various OS packages are typically signed with 2048-bit keys, transmitted via TLS connections authenticated with 2048-bit RSA, ... My take is that 3072-bit RSA and especially 4096-bit RSA is for most users a fashion statement, rather than a technically sound choice. -- Viktor. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] GnuTTS woes
On 30/09/2022 15:33, Viktor Dukhovni via Exim-users wrote: On Fri, Sep 30, 2022 at 02:04:51PM +0100, Jeremy Harris via Exim-users wrote: Note that this client won't work against current OpenSSL default builds. When you say "current" you mean 3.1-dev? What is the observed failure mode? It "works" against the latest OpenSSL 1.1.1 (the server responds with server hello, certificate, ..., server hello done). Perhaps TLS 1.1 is not enabled in your build? OpenSSL 3.0.5 5 Jul 2022running on Fedora 36 I think using the distro standard package openssl-1:3.0.2-4.fc36.x86_64 (though I note the numbers don't exactly line up) The failure mode is a TLS Alert complaining about version (I forget the precise wording, sorry) and followed by what looks like a library internal bug-triggered error for a BIO operation error. Clearing either no_tlsv1_1 or no_sslv3 has no effect. Let me know if you need a repeat run. -- Cheers, Jeremy -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] GnuTTS woes
On Fri, Sep 30, 2022 at 02:04:51PM +0100, Jeremy Harris via Exim-users wrote: > Ah, the difference is the total lack of TLS extensions > in the Client Hello. > > Commit ece23f05d6 pushed. > > Note that this client won't work against current OpenSSL > default builds. When you say "current" you mean 3.1-dev? What is the observed failure mode? It "works" against the latest OpenSSL 1.1.1 (the server responds with server hello, certificate, ..., server hello done). Perhaps TLS 1.1 is not enabled in your build? -- Viktor. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] GnuTTS woes
On 30/09/2022 09:14, Jeremy Harris via Exim-users wrote: On 30/09/2022 06:06, Jasen Betts via Exim-users wrote: It seems to be ALPN causing the problem. this was the commit that "broke" it... commit f50a063dc0b96ac95b3a7bc0aebad3b3f2534c02 (HEAD) Curious, given that the testsuite makes non-ALPN connections all over the place. I'll try to duplicate your config and connection within the testsuite... Ah, the difference is the total lack of TLS extensions in the Client Hello. Commit ece23f05d6 pushed. Note that this client won't work against current OpenSSL default builds. -- Cheers, Jeremy -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] GnuTTS woes
Am 29.09.22 um 12:19 schrieb Evgeniy Berdnikov via Exim-users: corps and gov entities, which states, that 2048 bit RSA keys, for any purpose,*should* not be used anymore in 2022. https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.pdf?__blob=publicationFile=10 Comment to table 3.1: | For a period of use beyond 2022, it is recommended to use RSA/DLIES | keys of 3000 bits length to achieve a consistent level of security in | all recommended asymmetric encryption schemes. The key length of 2000 | bits will remain compliant with this Technical Guideline for DLIES | keys until the end of 2022, and also transitionally for RSA keys until | the end of 2023. So, BSI statement is significantly different from what you wrote. "recommended" is a suggestion to do something, not an enforcement. So "should" is the correct form. To shorten this up: 'You "should" use bigger keys, for a usage beyond 2022, but you don't need to.' (to stay compliant with the tr) My POV here: "why waiting". Encryption doesn't slow down todays cpus anymore as it has 15 years ago, same for a smartphone soc. best regards, Marius OpenPGP_0x048770A738345DD3.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] GnuTTS woes
On 30/09/2022 09:11, Jasen Betts via Exim-users wrote: Testssl.sh primes its ALPN requests based on the port number used What does it use for 25/465/567 ? I don't know of an actual Standard; I just picked the obvious for Exim. -- Cheers, Jeremy -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] GnuTTS woes
On 30/09/2022 06:06, Jasen Betts via Exim-users wrote: It seems to be ALPN causing the problem. this was the commit that "broke" it... commit f50a063dc0b96ac95b3a7bc0aebad3b3f2534c02 (HEAD) Curious, given that the testsuite makes non-ALPN connections all over the place. I'll try to duplicate your config and connection within the testsuite... -- Cheers, Jeremy -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] GnuTTS woes
On 2022-09-30, Andrew C Aitchison via Exim-users wrote: > On Fri, 30 Sep 2022, Jasen Betts via Exim-users wrote: > >> On 2022-09-30, Viktor Dukhovni via Exim-users wrote: >>> On Fri, Sep 30, 2022 at 01:21:21AM -, Jasen Betts via Exim-users wrote: >>> > With the older Exim, GnuTLS appears to consider six cipher suites before > finding a suitable choice (after skipping all the DHE candidates). I can disable DHE_RSA by saying tls_require_ciphers = NORMAL:%COMPAT:!DHE-RSA and now it chooses the same suite that 4.94 was choosing but there is still an error after the suite is chosen. >>> >>> You could keep debugging GnuTLS, or just use a version of Exim with TLS >>> support via OpenSSL, which will likely just work. Your call. >>> >>> Some resource that GnuTLS expects to use is not available when it is >>> initialised by the problem version of Exim. If not a DHE group, >>> likely something else related cryptography. To debug, you'd need >>> to figure out where that error is raised. Lack of help from strace >>> is not unexpected. >> >> It seems to be ALPN causing the problem. >> >> this was the commit that "broke" it... >> >> commit f50a063dc0b96ac95b3a7bc0aebad3b3f2534c02 (HEAD) >> Author: Jeremy Harris >> Date: Tue Jun 22 23:04:59 2021 +0100 >> >>TLS: as server, reject connections with ALPN indicating non-smtp use >> >> The problem seems to be "gnutls_ext_raw_parse" returning >> GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE when ALPN is not being used. >> (or when no extensions are being used?) this is undocumented >> behaviour, but is sematically compatible with the description of that >> function. > > IIRC you were testing on port 443. Recently I changed to testing on 465. Testing 4.96 on 443 showed negative results for many web browsers (unsurprisingly now) versin 4.94 (which was released just before ALPN was implemented in exim) gives positive results. > Just out of interest, > what happens if you use a port without a special TLS meaning ? Recently I've just been replaying the recorded Paradox "TLS hello" for testing. Testssl.sh primes its ALPN requests based on the port number used (but that can probably be overridden) -- Jasen. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
