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] 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/
Re: [exim] GnuTTS woes
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. Just out of interest, what happens if you use a port without a special TLS meaning ? -- Andrew C. Aitchison Kendal, UK and...@aitchison.me.uk -- ## 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, 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.
This patch seems to fix it in my test case. I will try real-world tests next
week.
diff --git a/src/src/tls-gnu.c b/src/src/tls-gnu.c
index 7a6db94e1..9fc921064 100644
--- a/src/src/tls-gnu.c
+++ b/src/src/tls-gnu.c
@@ -1142,8 +1142,9 @@ tls_server_clienthello_cb(gnutls_session_t session,
unsigned int htype,
unsigned when, unsigned int incoming, const gnutls_datum_t * msg)
{
/* Call fn for each extension seen. 3.6.3 onwards */
-return gnutls_ext_raw_parse(NULL, tls_server_clienthello_ext, msg,
+ int rc = gnutls_ext_raw_parse(NULL, tls_server_clienthello_ext, msg,
GNUTLS_EXT_RAW_FLAG_TLS_CLIENT_HELLO);
+ return rc == GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE ? 0 : rc ;
}
--
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] GnuTTS woes
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. -- 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 2022-09-29, Viktor Dukhovni via Exim-users wrote: > On Thu, Sep 29, 2022 at 03:31:59AM -, Jasen Betts via Exim-users wrote: > >> This client called itself "Paradox" in the SMTP ehlo, I think it's >> probably an alarm system. I have an example TLS hello packet now: >> >> 160343013f0302923e9988d02b8fc276bdcf02ccb6fc3900 >> d052828c650ccd8c020040180033003900450088001600350084002f0041 >> 000a000500040100 > > The "tshark" decode for this Client Hello is: > > Transport Layer Security > SSLv3 Record Layer: Handshake Protocol: Client Hello > Content Type: Handshake (22) > Version: SSL 3.0 (0x0300) > Length: 67 > Handshake Protocol: Client Hello > Handshake Type: Client Hello (1) > Length: 63 > Version: TLS 1.1 (0x0302) > Random: > 923e9988d02b8fc276bdcf02ccb6fc3900d052828c650ccd8c020040 > GMT Unix Time: Feb 7, 2106 01:28:15.0 EST > Random Bytes: > 923e9988d02b8fc276bdcf02ccb6fc3900d052828c650ccd8c020040 > Session ID Length: 0 > Cipher Suites Length: 24 > Cipher Suites (12 suites) > Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) > Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) > Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA > (0x0045) > Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA > (0x0088) > Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016) > Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) > Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084) > Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) > Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041) > Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) > Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005) > Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004) > Compression Methods Length: 1 > Compression Methods (1 method) > Compression Method: null (0) > > So this client seems to support SSL 3.0 through TLS 1.1, with RSA and > mostly SHA1. The TLS Client HELLO includes no TLS 1.0 extensions. > >> tls_require_ciphers expands to "NORMAL:%COMPAT" >> 433834 TLS: preloading cipher list for server: NORMAL:%COMPAT >> 433834 GnuTLS<2>: added 6 protocols, 29 ciphersuites, 19 sig algos and 10 >> groups into priority list >> 433838 Initialising GnuTLS server params >> 433838 GnuTLS<2>: checking 00.33 (GNUTLS_DHE_RSA_AES_128_CBC_SHA1) for >> compatibility > > First client cipher chosen. But does the server support TLS 1.1 and > below? Perhaps Exim (or GnuTLS) defaults to TLS 1.2 or higher? > >> 433838 GnuTLS<2>: Selected (RSA) cert based on ciphersuite 0.33: >> GNUTLS_DHE_RSA_AES_128_CBC_SHA1 >> 433838 error -56 from gnutls_handshake: The requested data were not >> available. > > Here, the first ciphersuite is chosen, but perhaps then fails for lack > of appropriate DHE parameters? There may be some adverse interaction > between DHE group selection and TLS 1.1 and below in the newer Exim. > >> 435388 TLS: no SNI presented in handshake. >> 435388 GnuTLS<2>: checking 00.33 (GNUTLS_DHE_RSA_AES_128_CBC_SHA1) for >> compatibility >> 435388 GnuTLS<2>: checking 00.39 (GNUTLS_DHE_RSA_AES_256_CBC_SHA1) for >> compatibility >> 435388 GnuTLS<2>: checking 00.45 (GNUTLS_DHE_RSA_CAMELLIA_128_CBC_SHA1) for >> compatibility >> 435388 GnuTLS<2>: checking 00.88 (GNUTLS_DHE_RSA_CAMELLIA_256_CBC_SHA1) for >> compatibility >> 435388 GnuTLS<2>: checking 00.16 (GNUTLS_DHE_RSA_3DES_EDE_CBC_SHA1) for >> compatibility >> 435388 GnuTLS<2>: checking 00.35 (GNUTLS_RSA_AES_256_CBC_SHA1) for >> compatibility >> 435388 GnuTLS<3>: ASSERT: >> ../../../lib/ext/server_name.c[gnutls_server_name_get]:239 >> 435388 GnuTLS<2>: Selected (RSA) cert based on ciphersuite 0.35: >> GNUTLS_RSA_AES_256_CBC_SHA1 > > 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. 442134 Initialising GnuTLS server params 442134 Loading default hard-coded DH params 442134 GnuTLS<3>: ASSERT: ../../lib/dh.c[gnutls_dh_params_import_pkcs3]:556 442134 Loaded fixed standard D-H parameters 442134 cipher list preloaded 442134 TLS: a client certificate will not be requested 442134 GnuTLS<3>: ASSERT: ../../lib/buffers.c[get_last_packet]:1185 442134 GnuTLS<3>: ASSERT: ../../lib/db.c[_gnutls_server_restore_session]:334 442134 GnuTLS<3>: ASSERT:
Re: [exim] GnuTTS woes
On Thu, Sep 29, 2022 at 10:36:55AM +0200, Cyborg via Exim-users wrote: > There is a BSI ( the german cybersecurity agency ) guideline for > german corps and gov entities, which states, that 2048 bit RSA keys, > for any purpose, should not be used anymore in 2022. The BSI stance is unreasonable for almost all users and threat models. Perhaps there are some sensitive military or diplomatic applications in which RSA is used in key transport mode, and where it is anticipated that classical brute-force attacks with 2^112 cost (~10^12 times the cost of the largest scale attacks demonstrated to date) are somehow possible and economically justified, and 2^128 saves the day. > Can you state, why you think, that this 2048 bit key is only used for > authentication, rather than for TLS encryption? I think, it is used, as > it's presented on port 25. Other than with outdated RSA key transport, almost all TLS clients prefer DHE or ECDHE, where RSA just signs (authenticates) the key exchange, rather than encrypts or decrypts the key. Clients old enough to not support DHE or ECDHE generally have more severe problems than vulnerability to 2^112 attacks. -- 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 29/09/2022 05:59, Viktor Dukhovni via Exim-users wrote: But does the server support TLS 1.1 and below? Perhaps Exim (or GnuTLS) defaults to TLS 1.2 or higher? This will depend on the main-config option "tls_require_ciphers", which for GnuTLS is a "priority string". See the Gnutls docs, eg. https://www.gnutls.org/manual/html_node/Priority-Strings.html The Exim default fo the option (with GnuTLS) is "NORMAL" - you get whatever the GnuTLS library version decides. That could in turn depend on per-system policies. Note that permitting TLSv1.1 is downgrading your security. You might want to only permit it for this client, eg. by using an expansion depending on the IP. Doing so will, however, mean that Exim cannot pre-load that portion of library setup. -- 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 Thu, Sep 29, 2022 at 10:36:55AM +0200, Cyborg via Exim-users wrote: > Am 28.09.22 um 17:51 schrieb Viktor Dukhovni via Exim-users: > > I strongly disagree. There's no need to be a crypto > > exhibitionist/maximalist. The vast majority of issuing CA RSA keys are > > 2048-bits. The use of 4096-bit keys is pointless waste of CPU, > > There is a BSI ( the german cybersecurity agency ) guideline for german > 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. > Can you state, why you think, that this 2048 bit key is only used for > authentication, rather than for TLS encryption? I think, it is used, as it's > presented on port 25. You have better to study basics of TLS, really. -- Eugene Berdnikov -- ## 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 28.09.22 um 17:51 schrieb Viktor Dukhovni via Exim-users: On Wed, Sep 28, 2022 at 05:08:37PM +0200, Cyborg via Exim-users wrote: But your key is a bit short. I suggest to upgrade it to at least 4096 bits. I strongly disagree. There's no need to be a crypto exhibitionist/maximalist. The vast majority of issuing CA RSA keys are 2048-bits. The use of 4096-bit keys is pointless waste of CPU, There is a BSI ( the german cybersecurity agency ) guideline for german corps and gov entities, which states, that 2048 bit RSA keys, for any purpose, should not be used anymore in 2022. Although, it's an EllipticCurve Key, so it's long enough. I did not considers this in my answere, my fault. Can you state, why you think, that this 2048 bit key is only used for authentication, rather than for TLS encryption? I think, it is used, as it's presented on port 25. best regards, Marius -- ## 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 Thu, Sep 29, 2022 at 03:31:59AM -, Jasen Betts via Exim-users wrote: > This client called itself "Paradox" in the SMTP ehlo, I think it's > probably an alarm system. I have an example TLS hello packet now: > > 160343013f0302923e9988d02b8fc276bdcf02ccb6fc3900 > d052828c650ccd8c020040180033003900450088001600350084002f0041 > 000a000500040100 The "tshark" decode for this Client Hello is: Transport Layer Security SSLv3 Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: SSL 3.0 (0x0300) Length: 67 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 63 Version: TLS 1.1 (0x0302) Random: 923e9988d02b8fc276bdcf02ccb6fc3900d052828c650ccd8c020040 GMT Unix Time: Feb 7, 2106 01:28:15.0 EST Random Bytes: 923e9988d02b8fc276bdcf02ccb6fc3900d052828c650ccd8c020040 Session ID Length: 0 Cipher Suites Length: 24 Cipher Suites (12 suites) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088) Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005) Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004) Compression Methods Length: 1 Compression Methods (1 method) Compression Method: null (0) So this client seems to support SSL 3.0 through TLS 1.1, with RSA and mostly SHA1. The TLS Client HELLO includes no TLS 1.0 extensions. > tls_require_ciphers expands to "NORMAL:%COMPAT" > 433834 TLS: preloading cipher list for server: NORMAL:%COMPAT > 433834 GnuTLS<2>: added 6 protocols, 29 ciphersuites, 19 sig algos and 10 > groups into priority list > 433838 Initialising GnuTLS server params > 433838 GnuTLS<2>: checking 00.33 (GNUTLS_DHE_RSA_AES_128_CBC_SHA1) for > compatibility First client cipher chosen. But does the server support TLS 1.1 and below? Perhaps Exim (or GnuTLS) defaults to TLS 1.2 or higher? > 433838 GnuTLS<2>: Selected (RSA) cert based on ciphersuite 0.33: > GNUTLS_DHE_RSA_AES_128_CBC_SHA1 > 433838 error -56 from gnutls_handshake: The requested data were not > available. Here, the first ciphersuite is chosen, but perhaps then fails for lack of appropriate DHE parameters? There may be some adverse interaction between DHE group selection and TLS 1.1 and below in the newer Exim. > 435388 TLS: no SNI presented in handshake. > 435388 GnuTLS<2>: checking 00.33 (GNUTLS_DHE_RSA_AES_128_CBC_SHA1) for > compatibility > 435388 GnuTLS<2>: checking 00.39 (GNUTLS_DHE_RSA_AES_256_CBC_SHA1) for > compatibility > 435388 GnuTLS<2>: checking 00.45 (GNUTLS_DHE_RSA_CAMELLIA_128_CBC_SHA1) for > compatibility > 435388 GnuTLS<2>: checking 00.88 (GNUTLS_DHE_RSA_CAMELLIA_256_CBC_SHA1) for > compatibility > 435388 GnuTLS<2>: checking 00.16 (GNUTLS_DHE_RSA_3DES_EDE_CBC_SHA1) for > compatibility > 435388 GnuTLS<2>: checking 00.35 (GNUTLS_RSA_AES_256_CBC_SHA1) for > compatibility > 435388 GnuTLS<3>: ASSERT: > ../../../lib/ext/server_name.c[gnutls_server_name_get]:239 > 435388 GnuTLS<2>: Selected (RSA) cert based on ciphersuite 0.35: > GNUTLS_RSA_AES_256_CBC_SHA1 With the older Exim, GnuTLS appears to consider six cipher suites before finding a suitable choice (after skipping all the DHE candidates). -- 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 2022-09-28, Jeremy Harris via Exim-users wrote: > On 28/09/2022 21:10, Viktor Dukhovni via Exim-users wrote: >> You need to analyse some failed handshake full-packet captures with >> "tshark", and collected detailed logs from the clients that are having >> problems. > > For Exim, that's "-d-all+tls" as a minimum. Thanks. This client called itself "Paradox" in the SMTP ehlo, I think it's probably an alarm system. I have an example TLS hello packet now: 160343013f0302923e9988d02b8fc276bdcf02ccb6fc3900 d052828c650ccd8c020040180033003900450088001600350084002f0041 000a000500040100 And I'm able to provoke the error message by replaying it. ( sleep 1 ; xxd -c 32 -r << XDATA 000 160343013f0302923e9988d02b8fc276bdcf02ccb6fc3900 020 d052828c650ccd8c020040180033003900450088001600350084002f0041 040 000a000500040100 XDATA sleep 4 ; echo quit ; echo quit ; sleep 5 ) | nc localhost 465 root@eximtest:~# exim -bd -d-all+tls Exim version 4.96 uid=0 gid=0 pid=433834 D=1000 Support for: crypteq iconv() IPv6 PAM Perl Expand_dlfunc GnuTLS TLS_resume move_frozen_messages Content_Scanning DANE DKIM DNSSEC Event I18N OCSP PIPECONNECT PRDR PROXY Queue_Ramp SOCKS SPF SRS TCP_Fast_Open Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz dbmnz dnsdb dsearch ldap ldapdn ldapm mysql nis nis0 passwd pgsql sqlite Authenticators: cram_md5 cyrus_sasl dovecot external plaintext spa tls Routers: accept dnslookup ipliteral iplookup manualroute queryprogram redirect Transports: appendfile/maildir/mailstore/mbx autoreply lmtp pipe smtp Malware: f-protd f-prot6d drweb fsecure sophie clamd avast sock cmdline Fixed never_users: 0 Configure owner: 0:0 Size of off_t: 8 Compiler: GCC [10.2.1 20210110] Library version: Glibc: Compile: 2.31 Runtime: 2.31 Library version: BDB: Compile: Berkeley DB 5.3.28: (September 9, 2013) Runtime: Berkeley DB 5.3.28: (September 9, 2013) Library version: GnuTLS: Compile: 3.7.1 Runtime: 3.7.1 Library version: IDN2: Compile: 2.3.0 Runtime: 2.3.0 Library version: Stringprep: Compile: 1.33 Runtime: 1.33 Library version: spf2: Compile: 1.2.10 Runtime: 1.2.10 Library version: Cyrus SASL: Compile: 2.1.27 Runtime: 2.1.27 [Cyrus SASL] Library version: PCRE2: Compile: 10.36 Runtime: 10.36 2020-12-04 Library version: MySQL: Compile: 100515 10.5.15 [mariadb-10.5] Runtime: 100515 10.5.15 Library version: SQLite: Compile: 3.34.1 Runtime: 3.34.1 WHITELIST_D_MACROS: "OUTGOING" TRUSTED_CONFIG_LIST: "/etc/exim4/trusted_configs" configuration file is /var/lib/exim4/config.autogenerated log selectors = cffc 64205022 001c cwd=/root 3 args: exim -bd -d-all+tls trusted user admin user dropping to exim gid; retaining priv uid fresh-exec forking for cipher-validate fresh-exec forked for cipher-validate: 433835 postfork: cipher-validate tls_require_ciphers expands to "NORMAL:%COMPAT" Exim pid=433835 (cipher-validate) terminating with rc=0 tls_validate_require_cipher child 433835 ended: status=0x0 433834 creating notifier socket 433834 @/var/spool/exim4/exim_daemon_notify 433834 listening on all interfaces (IPv6) port 25 433834 listening on all interfaces (IPv4) port 25 433834 listening on all interfaces (IPv6) port 465 433834 listening on all interfaces (IPv4) port 465 433834 listening on all interfaces (IPv6) port 587 433834 listening on all interfaces (IPv4) port 587 433834 listening on all interfaces (IPv6) port 443 433834 listening on all interfaces (IPv4) port 443 433834 pid written to /run/exim4/exim.pid 433834 LOG: MAIN 433834 exim 4.96 daemon started: pid=433834, no queue runs, listening for SMTP on port 25 (IPv6 and IPv4) port 587 (IPv6 and IPv4) and for SMTPS on port 465 (IPv6 and IPv4) port 443 (IPv6 and IPv4) 433834 GnuTLS global init required 433834 TLS: basic cred init, server 433834 tls_set_watch: '/etc/exim4/duck.certkey' 433834 watch dir '/etc/exim4' 433834 TLS: preloading server certs 433834 GnuTLS<3>: ASSERT: ../../../lib/x509/attributes.c[_x509_parse_attribute]:103 433834 GnuTLS<3>: ASSERT: ../../../lib/x509/attributes.c[_x509_parse_attribute]:174 433834 GnuTLS<3>: ASSERT: ../../../lib/x509/x509_ext.c[gnutls_subject_alt_names_get]:111 433834 GnuTLS<3>: ASSERT: ../../../lib/x509/x509.c[get_alt_name]:1848 433834 GnuTLS<3>: ASSERT: ../../../lib/nettle/mpi.c[wrap_nettle_mpi_print]:60 433834 TLS: cert/key 0 /etc/exim4/duck.certkey registered 433834 TLS: not preloading CA bundle for server 433834 TLS: preloading cipher list for server: NORMAL:%COMPAT 433834 GnuTLS<2>: added 6 protocols, 29 ciphersuites, 19 sig algos and 10 groups into priority list 433834 TLS: basic cred init, client 433834 TLS: not preloading client certs, for
Re: [exim] GnuTTS woes
On 28/09/2022 21:10, Viktor Dukhovni via Exim-users wrote: You need to analyse some failed handshake full-packet captures with "tshark", and collected detailed logs from the clients that are having problems. For Exim, that's "-d-all+tls" as a minimum. -- 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 Wed, Sep 28, 2022 at 07:58:27PM -, Jasen Betts via Exim-users wrote: > > You said that ECDHE ciphers are not available, but a default connection > > with "posttls-finger" gives TLS 1.3 with an ECDHE cipher: > > I did say that, I was working from scraped web pages of a third-party > analysis at the time... I've since found testssl.sh (which is easier to > use) and by tweaking the priority string have turned on the same > cyphers. > > accordingto testssl.sh The only feature currently missing is > maximum_fragment_size, (and the ability to support several client platforms) > I think I may have to run a bisection search on the source code to figure out > where that fell off. That particular extension is hardly likely to be particularly important. I think you're barking up the wrong tree. Whatever the problem is, it is likely somewhere entirely different. You need to analyse some failed handshake full-packet captures with "tshark", and collected detailed logs from the clients that are having problems. -- 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
Sorry for the slow replies, my mailing list subscription was misconfigured On 2022-09-28, Viktor Dukhovni via Exim-users wrote: > On Tue, Sep 27, 2022 at 02:39:19AM -, Jasen Betts via Exim-users wrote: > >> it's reachable here: eximtest.duckdns.org >> >> eg: $ testssl eximtest.duckdns.org:465 >> > > You said that ECDHE ciphers are not available, but a default connection > with "posttls-finger" gives TLS 1.3 with an ECDHE cipher: > I did say that, I was working from scraped web pages of a third-party analysis at the time... I've since found testssl.sh (which is easier to use) and by tweaking the priority string have turned on the same cyphers. accordingto testssl.sh The only feature currently missing is maximum_fragment_size, (and the ability to support several client platforms) I think I may have to run a bisection search on the source code to figure out where that fell off. -- 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] GnuTTS woes
On Wed, Sep 28, 2022 at 05:08:37PM +0200, Cyborg via Exim-users wrote: > But your key is a bit short. I suggest to upgrade it to at least 4096 bits. I strongly disagree. There's no need to be a crypto exhibitionist/maximalist. The vast majority of issuing CA RSA keys are 2048-bits. The use of 4096-bit keys is pointless waste of CPU, especially given that these are *authentication* keys, not encryption keys, so don't need to remain secure after they're replaced. And keep in mind tht SMTP clients mostly still ignore the server certificate entirely. -- 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
Am 28.09.22 um 16:28 schrieb Viktor Dukhovni via Exim-users: Ditto on port 465 and with IPv4: $ posttls-finger -c -lmay -Lsummary -w -o inet_protocols=ipv4 -p TLSv1.2 "[eximtest.duckdns.org]:465" posttls-finger: Untrusted TLS connection established to eximtest.duckdns.org[172.105.179.7]:465: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) Same with openssl: TLS 1.3 openssl s_client --connect eximtest.duckdns.org:25 -starttls smtp CONNECTED(0003) depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1 ... New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is 2048 bit TLS 1.2: New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported But your key is a bit short. I suggest to upgrade it to at least 4096 bits. 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 Wed, Sep 28, 2022 at 09:39:43AM -0400, Viktor Dukhovni via Exim-users wrote: > On Tue, Sep 27, 2022 at 02:39:19AM -, Jasen Betts via Exim-users wrote: > > > it's reachable here: eximtest.duckdns.org > > > > eg: $ testssl eximtest.duckdns.org:465 > > > > You said that ECDHE ciphers are not available, but a default connection > with "posttls-finger" gives TLS 1.3 with an ECDHE cipher: > > posttls-finger: Untrusted TLS connection established > to eximtest.duckdns.org[2400:8907::f03c:93ff:fe2d:f557]:25: > TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) > key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) > server-digest SHA256 > > If I force TLS 1.2, I get (slightly less detailed cipher breakdown for > TLS 1.2 in Postfix): > > posttls-finger: Untrusted TLS connection established > to eximtest.duckdns.org[2400:8907::f03c:93ff:fe2d:f557]:25: > TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) > > Either this is not the server in question, or ECDHE is working just > fine... Ditto on port 465 and with IPv4: $ posttls-finger -c -lmay -Lsummary -w -o inet_protocols=ipv4 -p TLSv1.2 "[eximtest.duckdns.org]:465" posttls-finger: Untrusted TLS connection established to eximtest.duckdns.org[172.105.179.7]:465: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) -- 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 Tue, Sep 27, 2022 at 02:39:19AM -, Jasen Betts via Exim-users wrote: > it's reachable here: eximtest.duckdns.org > > eg: $ testssl eximtest.duckdns.org:465 > You said that ECDHE ciphers are not available, but a default connection with "posttls-finger" gives TLS 1.3 with an ECDHE cipher: posttls-finger: Untrusted TLS connection established to eximtest.duckdns.org[2400:8907::f03c:93ff:fe2d:f557]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256 If I force TLS 1.2, I get (slightly less detailed cipher breakdown for TLS 1.2 in Postfix): posttls-finger: Untrusted TLS connection established to eximtest.duckdns.org[2400:8907::f03c:93ff:fe2d:f557]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) Either this is not the server in question, or ECDHE is working just fine... -- 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 2022-09-24, Viktor Dukhovni via Exim-users wrote: > On Fri, Sep 23, 2022 at 05:50:29AM -, Jasen Betts via Exim-users wrote: > >> My testing mainly involves telling exim to listen on poert 443 with >> implicit SSL and then hitting it with www.sslcheck.com >> >> tls_on_connect_ports = 465:443 >> daemon_smtp_ports = 25:465:587:443 >> >> and this testing also shows a change in the availalbe suites. >> >> It mainly seems to be ECDH suites that are no longer avaialable. > > There's a big difference between "ECDH" and "ECDHE", the "fixed" DH/ECDH > ciphers are deprecated, rarely used, and should not be used. While DHE > and ECDHE ciphers are preferred. If GnuTLS disabled these, no harm done. > > If you post the name of the server, it would be possible for others to > confirm your observations and perhaps offer more detailed help. the server is nothing special, basically a stock debian 11 with exim installed from debian backports, and a certificate from letsencrypt. I'm working towards minimum steps to reproduce by eliminating as many other factors as possible.. I'm using a free dynamic domain name to protect the guilty. it's reachable here: eximtest.duckdns.org eg: $ testssl eximtest.duckdns.org:465 once I find a good configuration I will deploy it on production servers. -- 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] GnuTTS woes
On 2022-09-24, Andreas Metzler via Exim-users wrote: > On 2022-09-23 Jasen Betts via Exim-users wrote: >> upgrading from 4.94 to 4.96 seems to have dramatically reduced the TLS >> connectivity (as a server). > >> I'm using libgnutls3.7.1 on debian 11 and the Exim package from backports > >> customers are complaining about TLS not not working > >> my testing mainly involves telling exim to listen on poert 443 with >> implicit SSL and then hitting it with www.sslcheck.com I have since discovered the script testssl.sh which gives the same results, faster. >> and this testing also shows a change in the availalbe suites. > >> It mainly seems to be ECDH suites that are no longer avaialable. > > Hello, > > I suspect you have only installed a EC/ECDSA certificate, you will also > need a RSA certificate for maximum compatibility. On my test server I'm using an RSA certificate from letsencrypt. it doesn't seem to make any difference. I can align the list cipher suites on both versions by disabling DHE-RSA on the new server, but that didn't help. according to testssl.sh the only protocol difference seems to be that the new version isn't offering tls extension "max fragment length/#1" I can't find a way to enable this to test if it makes any difference. -- 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] GnuTTS woes
On 2022-09-24, Jeremy Harris via Exim-users wrote: > On 23 September 2022 06:50:29 BST, Jasen Betts via Exim-users > wrote: >>upgrading from 4.94 to 4.96 seems to have dramatically reduced the TLS >>connectivity (as a server). >> >>I'm using libgnutls3.7.1 on debian 11 and the Exim package from >>backports > > > > Did the GnuTLS version change? > If so it could be that rather than > the Exim version change. > > You need to disentangle. the version of gnutls is the same: this one. lrwxrwxrwx 1 root root 20 Aug 7 14:30 x86_64-linux-gnu/libgnutls.so -> libgnutls.so.30.29.1 lrwxrwxrwx 1 root root 20 Aug 7 14:30 x86_64-linux-gnu/libgnutls.so.30 -> libgnutls.so.30.29.1 -rw-r--r-- 1 root root 2086552 Aug 7 14:30 x86_64-linux-gnu/libgnutls.so.30.29.1 -- 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] GnuTTS woes
On Fri, Sep 23, 2022 at 05:50:29AM -, Jasen Betts via Exim-users wrote: > My testing mainly involves telling exim to listen on poert 443 with > implicit SSL and then hitting it with www.sslcheck.com > > tls_on_connect_ports = 465:443 > daemon_smtp_ports = 25:465:587:443 > > and this testing also shows a change in the availalbe suites. > > It mainly seems to be ECDH suites that are no longer avaialable. There's a big difference between "ECDH" and "ECDHE", the "fixed" DH/ECDH ciphers are deprecated, rarely used, and should not be used. While DHE and ECDHE ciphers are preferred. If GnuTLS disabled these, no harm done. If you post the name of the server, it would be possible for others to confirm your observations and perhaps offer more detailed help. -- 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 23 September 2022 06:50:29 BST, Jasen Betts via Exim-users wrote: >upgrading from 4.94 to 4.96 seems to have dramatically reduced the TLS >connectivity (as a server). > >I'm using libgnutls3.7.1 on debian 11 and the Exim package from >backports Did the GnuTLS version change? If so it could be that rather than the Exim version change. You need to disentangle. -- 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-23 Jasen Betts via Exim-users wrote: > upgrading from 4.94 to 4.96 seems to have dramatically reduced the TLS > connectivity (as a server). > I'm using libgnutls3.7.1 on debian 11 and the Exim package from backports > customers are complaining about TLS not not working > my testing mainly involves telling exim to listen on poert 443 with > implicit SSL and then hitting it with www.sslcheck.com > tls_on_connect_ports = 465:443 > daemon_smtp_ports = 25:465:587:443 > and this testing also shows a change in the availalbe suites. > It mainly seems to be ECDH suites that are no longer avaialable. Hello, I suspect you have only installed a EC/ECDSA certificate, you will also need a RSA certificate for maximum compatibility. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- ## 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] GnuTTS woes
upgrading from 4.94 to 4.96 seems to have dramatically reduced the TLS connectivity (as a server). I'm using libgnutls3.7.1 on debian 11 and the Exim package from backports customers are complaining about TLS not not working my testing mainly involves telling exim to listen on poert 443 with implicit SSL and then hitting it with www.sslcheck.com tls_on_connect_ports = 465:443 daemon_smtp_ports = 25:465:587:443 and this testing also shows a change in the availalbe suites. It mainly seems to be ECDH suites that are no longer avaialable. I'm not sure how to proceed. -- 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/
