Re: [exim] TLS error no shared cipher with SSL_accept: error in error
On 2021-06-01 Marcin Gryszkalis via Exim-users wrote: [...] > so I checked what is the difference between these two boxes - and finally > found it - problematic exim uses EC certificate, while mail.fuze.pl uses (as > you could see) RSA. The change was caused by > switch of defaults in deydrated Let's Encrypt client: [...] Just for the archives: I had the same problem with GnuTLS built exim where it shows up as 2021-02-20 12:13:53 TLS error on connection from [...] (gnutls_handshake): No supported cipher suites have been found. in the log. I am now running exim dual-stacked, with both RSA and secp384r1 certificates. 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/
Re: [exim] TLS error no shared cipher with SSL_accept: error in error
On 31.05.2021 23:29, Viktor Dukhovni via Exim-users wrote: I see, the version of OpenSSL may be relevant here. Is the server in question "mail.fuze.pl"? On port 25 for that server I This is not the server but It uses the same configuration and same FreeBSD/openssl version - but as I tested it with s_client it didn't fail! openssl s_client -connect mail.fuze.pl:465 -tls1_2 -curves P-256 Server Temp Key: ECDH, P-256, 256 bits New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384 so I checked what is the difference between these two boxes - and finally found it - problematic exim uses EC certificate, while mail.fuze.pl uses (as you could see) RSA. The change was caused by switch of defaults in deydrated Let's Encrypt client: https://github.com/dehydrated-io/dehydrated/commit/174616becd96c202e3ff6dc0f28b3b435644f623 The EC cert is secp384r1 / P-384 so forcing P-256 only causes the alert. In fact, testing with s_client and -curves P-256:P-384 is successful. Server Temp Key: ECDH, P-256, 256 bits New, TLSv1/SSLv3, Cipher is ECDHE-ECDSA-AES256-GCM-SHA384 Server public key is 384 bit So I think I'll switch back to RSA for few more years ;) thank you all for helping to debug this stuff, best regards -- Marcin Gryszkalis, PGP 0xA5DBEEC7 http://fork.pl/gpg.txt -- ## 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] TLS error no shared cipher with SSL_accept: error in error
On Mon, May 31, 2021 at 11:19:23PM +0200, Marcin Gryszkalis via Exim-users wrote: > On 31.05.2021 22:59, Viktor Dukhovni via Exim-users wrote: > >> I checked on exim built on FreeBSD 12 (with openssl 1.1) and it works fine > >> - but fails on other installation with openssl 1.0. > > > > So what version of FreeBSD and OpenSSL are on the system with the > > reported issue? Support for negotiated ECDHE groups has evolved in > > OpenSSL over time. With older OpenSSL releases unless group selection > > is explicitly set to "auto", the server picks some single default group, > > which may not match this particular client's choice. > > Sorry, I forgot to mention this. > > This is OpenSSL 1.0.2u (base version for FreeBSD 11.4). I see, the version of OpenSSL may be relevant here. Is the server in question "mail.fuze.pl"? On port 25 for that server I see: No client certificate CA names sent Peer signing digest: SHA512 Peer signature type: RSA Server Temp Key: ECDH, P-256, 256 bits --- SSL handshake has read 3757 bytes and written 475 bytes Verification: OK --- New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 4096 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher: ECDHE-RSA-AES256-GCM-SHA384 Session-ID: ... Session-ID-ctx: Master-Key: ... PSK identity: None PSK identity hint: None SRP username: None Start Time: 1622494851 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no Which does show working support for ECDHE with P-256. I'd also humbly suggest not bothering with 4096 bit RSA certs, they're rather pointless. The major CAs are all using 2048 bit RSA. RSA 4096 is just bloat. > I could switch to 1.1.1k from ports but that would require rebuilding > exim and the rest. > I also could switch to libressl or even GnuTLS... I would not recommend either of those two, but OpenSSL 1.1.1 would be a much better choice, 1.0.2 has been EOL for quite some time. -- 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] TLS error no shared cipher with SSL_accept: error in error
On 31.05.2021 22:59, Viktor Dukhovni via Exim-users wrote: I checked on exim built on FreeBSD 12 (with openssl 1.1) and it works fine - but fails on other installation with openssl 1.0. So what version of FreeBSD and OpenSSL are on the system with the reported issue? Support for negotiated ECDHE groups has evolved in OpenSSL over time. With older OpenSSL releases unless group selection is explicitly set to "auto", the server picks some single default group, which may not match this particular client's choice. Sorry, I forgot to mention this. This is OpenSSL 1.0.2u (base version for FreeBSD 11.4). I could switch to 1.1.1k from ports but that would require rebuilding exim and the rest. I also could switch to libressl or even GnuTLS... best regards -- Marcin Gryszkalis, PGP 0xA5DBEEC7 http://fork.pl/gpg.txt -- ## 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] TLS error no shared cipher with SSL_accept: error in error
On Mon, May 31, 2021 at 11:08:22PM +0300, Evgeniy Berdnikov via Exim-users wrote: > > SSL-Session: > > Protocol : TLSv1.2 > > Cipher: ECDHE-ECDSA-AES256-GCM-SHA384 > > Session-ID: ... > > Session-ID-ctx: > > Master-Key: ... > > Key-Arg : None > > PSK identity: None > > PSK identity hint: None > > SRP username: None > > Start Time: 1622470949 > > Timeout : 7200 (sec) > > Verify return code: 0 (ok) > > > > > > But - I tried to specify the curve and it failed > > > > openssl s_client -connect 127.0.0.1:465 -tls1_2 -cipher > > ECDHE-ECDSA-AES256-GCM-SHA384 -curves prime256v1 This cipher requires the server to have an ECDSA certificate, you've probably only configured an RSA certificate. The support SHA384 ciphers in OpenSSL 1.1.1 are: $ OpenSSL_1_1_1/bin/openssl ciphers -s -tls1_2 -v ALL+SHA384 ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA384 ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384 ECDHE-ECDSA-CAMELLIA256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=Camellia(256) Mac=SHA384 ECDHE-RSA-CAMELLIA256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=Camellia(256) Mac=SHA384 > It looks like recent libssl considers ECDHE-ECDSA-AES256-GCM-SHA384 > as TLSv1.3-only cipher. And post-handshake message mentions it > in some other manner: That's not the case. -- 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] TLS error no shared cipher with SSL_accept: error in error
On Mon, May 31, 2021 at 04:42:55PM +0200, Marcin Gryszkalis via Exim-users wrote: > openssl s_client -connect 127.0.0.1:465 -tls1_2 -cipher > ECDHE-ECDSA-AES256-GCM-SHA384 > But - I tried to specify the curve and it failed > > openssl s_client -connect 127.0.0.1:465 -tls1_2 -cipher > ECDHE-ECDSA-AES256-GCM-SHA384 -curves prime256v1 > > CONNECTED(0004) > 34380884168:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake > failure:/usr/src/crypto/openssl/ssl/s3_pkt.c:1498:SSL alert number 40 > 34380884168:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake > failure:/usr/src/crypto/openssl/ssl/s3_pkt.c:659: > > prime256v1 = secp256r1 > > I checked on exim built on FreeBSD 12 (with openssl 1.1) and it works fine - > but fails on other installation with openssl 1.0. So what version of FreeBSD and OpenSSL are on the system with the reported issue? Support for negotiated ECDHE groups has evolved in OpenSSL over time. With older OpenSSL releases unless group selection is explicitly set to "auto", the server picks some single default group, which may not match this particular client's 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] TLS error no shared cipher with SSL_accept: error in error
On Mon, May 31, 2021 at 04:42:55PM +0200, Marcin Gryszkalis via Exim-users wrote: > openssl s_client -connect 127.0.0.1:465 -tls1_2 -cipher > ECDHE-ECDSA-AES256-GCM-SHA384 > > SSL-Session: > Protocol : TLSv1.2 > Cipher: ECDHE-ECDSA-AES256-GCM-SHA384 > Session-ID: ... > Session-ID-ctx: > Master-Key: ... > Key-Arg : None > PSK identity: None > PSK identity hint: None > SRP username: None > Start Time: 1622470949 > Timeout : 7200 (sec) > Verify return code: 0 (ok) > > > But - I tried to specify the curve and it failed > > openssl s_client -connect 127.0.0.1:465 -tls1_2 -cipher > ECDHE-ECDSA-AES256-GCM-SHA384 -curves prime256v1 My quick experiments on openssl/libssl 1.1.1k with s_server <--> s_client show that combination "s_client ... -tls1_2 -cipher ECDHE-ECDSA-AES256-GCM-SHA384" always leads to such SSL alert number 40, even if server is running with "-cipher ALL". Running "s_server ... -tls1_2" leads to similar result. It looks like recent libssl considers ECDHE-ECDSA-AES256-GCM-SHA384 as TLSv1.3-only cipher. And post-handshake message mentions it in some other manner: SSL-Session: Protocol : TLSv1.3 Cipher: TLS_AES_256_GCM_SHA384 Session-ID: ... Session-ID-ctx: Resumption PSK: ... PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 7200 (seconds) It seems this behaviour reflects some unstable internals of libssl and has no relation to Exim. -- 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] TLS error no shared cipher with SSL_accept: error in error
On 31/05/2021 13:27, Viktor Dukhovni via Exim-users wrote: 40884 SSL_accept: error in error 40884 SSL_accept: error in error I haven't seen that one much. Perhaps an issue in the Exim OpenSSL glue code. Best guess is that is from an info callback into Exim from OpenSSL ( registered via SSL_CTX_set_info_callback() ), with a "where" of SSL_CB_EXIT and that second "error" string helpfully provided by SSL_state_string_long(). -- 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] TLS error no shared cipher with SSL_accept: error in error
On 31/05/2021 12:44, Marcin Gryszkalis via Exim-users wrote: extended_master_secret is not supported by exim Exim supports it if the OpenSSL version (both compile-time and run-time) supports it. -- 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] TLS error no shared cipher with SSL_accept: error in error
On 31.05.2021 14:42, Cyborg via Exim-users wrote: The client did not offer a cipher you have allowed. But it's not true (see details in my reponse to Viktor's mail). You can do various tests to find out with openssl's s_client: with s_client I always succeed - eg. when I use first cipher from Client Hello openssl s_client -connect 127.0.0.1:465 -tls1_2 -cipher ECDHE-ECDSA-AES256-GCM-SHA384 SSL-Session: Protocol : TLSv1.2 Cipher: ECDHE-ECDSA-AES256-GCM-SHA384 Session-ID: ... Session-ID-ctx: Master-Key: ... Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1622470949 Timeout : 7200 (sec) Verify return code: 0 (ok) But - I tried to specify the curve and it failed openssl s_client -connect 127.0.0.1:465 -tls1_2 -cipher ECDHE-ECDSA-AES256-GCM-SHA384 -curves prime256v1 CONNECTED(0004) 34380884168:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:/usr/src/crypto/openssl/ssl/s3_pkt.c:1498:SSL alert number 40 34380884168:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake failure:/usr/src/crypto/openssl/ssl/s3_pkt.c:659: prime256v1 = secp256r1 I checked on exim built on FreeBSD 12 (with openssl 1.1) and it works fine - but fails on other installation with openssl 1.0. It's a bit strange as exim advertises this curve when connecting as smtp client - and list_curves also lists is: openssl ecparam -list_curves | grep 256v1 prime256v1: X9.62/SECG curve over a 256 bit prime field -- Marcin Gryszkalis, PGP 0xA5DBEEC7 http://fork.pl/gpg.txt -- ## 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] TLS error no shared cipher with SSL_accept: error in error
On 31.05.2021 14:27, Viktor Dukhovni via Exim-users wrote: On Mon, May 31, 2021 at 01:44:39PM +0200, Marcin Gryszkalis via Exim-users wrote: exim's cipher list is wide ALL:!EXPORT:!DES:!RC2:!RC4:!MD5:!PSK:!aNULL:!eNULL:!EXP:!SRP:!DSS:!DHE:!3DES What is the reason for disabling DHE ciphers? So there's no need to remember to prepare proper dh params, not important anyway I guess. This cipher list looks rather kludgey. Try "DEFAULT". This problem applies to one server only, any other can connect without problems. I left TLS1.0 and 1.1 because they are still used. Here are the stats from exim log: 2 TLS1.2:AES128-GCM-SHA256:128 3 TLS1.2:AES256-SHA:256 12 TLS1.2:AES256-GCM-SHA384:256 15 TLS1.1:ECDHE-ECDSA-AES256-SHA:256 18 TLS1.2:ECDHE-RSA-AES256-SHA:256 43 TLS1.1:ECDHE-RSA-AES256-SHA:256 54 TLS1.2:ECDHE-ECDSA-AES256-SHA384:256 149 TLS1:AES256-SHA:256 156 TLS1.2:DHE-RSA-AES256-GCM-SHA384:256 307 TLS1:DHE-RSA-AES256-SHA:256 313 TLS1.2:ECDHE-RSA-AES128-GCM-SHA256:128 384 TLS1:ECDHE-ECDSA-AES256-SHA:256 672 TLS1.2:ECDHE-ECDSA-AES128-GCM-SHA256:128 1214 TLS1:ECDHE-RSA-AES256-SHA:256 1467 TLS1.2:ECDHE-RSA-AES256-SHA384:256 3192 TLS1.2:ECDHE-ECDSA-AES256-GCM-SHA384:256 15980 TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256 As you can see this list have common part with the list from Client Hello, eg. first one - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) is on the list ( 672 TLS1.2:ECDHE-ECDSA-AES128-GCM-SHA256:128 ) The curve proposed by client (secp256r1) is also supported. 40884 openssl option, adding to 03104000: 0200 (no_sslv3 +no_sslv2 +cipher_server_preference) 40884 openssl option, adding to 03104000: 0100 (no_sslv2 +cipher_server_preference) 40884 openssl option, adding to 03104000: 0040 (cipher_server_preference) 40884 setting SSL CTX options: 0x3504000 40884 Diffie-Hellman initialized from default with 2048-bit prime 40884 ECDH OpenSSL 1.0.2+ temp key parameter settings: autoselection 40884 tls_certificate file '/letsencrypt/certs/mail.domain.com/fullchain.pem' 40884 tls_privatekey file '/letsencrypt/certs/mail.domain.com/privkey.pem' 40884 Initialized TLS 40884 required ciphers: ALL:!EXPORT:!DES:!RC2:!RC4:!MD5:!PSK:!aNULL:!eNULL:!EXP:!SRP:!DSS:!DHE:!3DES 40884 host in tls_verify_hosts? no (option unset) 40884 host in tls_try_verify_hosts? no (end of list) 40884 SMTP>> 220 TLS go ahead 40884 Calling SSL_accept 40884 SSL_accept: before/accept initialization 40884 SSL3 alert write:fatal:handshake failure That rather looks like your own server is initiating the handshake failure. It is writing the alert, not reading a remote alert. I think it says that exim returned handshake error (it did). 40884 SSL_accept: error in error 40884 SSL_accept: error in error I haven't seen that one much. Perhaps an issue in the Exim OpenSSL glue code. could be The server does not believe it has any shared ciphers available. You should also check the system-wide "openssl.cnf" file for any vendor configured protocol or cipher restrictions. it's default FreeBSD's openssl.cnf without any modifications wireshark dump from client hello This does not look like the entire client hello message. I did some cleaning, here is missing prefix: Transport Layer Security TLSv1.2 Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.2 (0x0303) Length: 120 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 116 Version: TLS 1.2 (0x0303) Random: 60b49... GMT Unix Time: May 31, 2021 10:07:16.0 CEST Random Bytes: f233... Session ID Length: 0 Cipher Suites Length: 24 Cipher Suites (12 suites) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d) Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Compression Methods Length: 1 Compression Methods (1 method) Compression Method: null (0) Extensions Length: 51 Extension: supported_groups (len=4) Type: supported_groups
Re: [exim] TLS error no shared cipher with SSL_accept: error in error
On Mon, May 31, 2021 at 01:44:39PM +0200, Marcin Gryszkalis via Exim-users wrote: > exim's cipher list is wide > ALL:!EXPORT:!DES:!RC2:!RC4:!MD5:!PSK:!aNULL:!eNULL:!EXP:!SRP:!DSS:!DHE:!3DES What is the reason for disabling DHE ciphers? And though in modern OpenSSL releases there are no longer any "LOW" ciphers, for some reason you've left those potentially enabled, while making extra sure to delete the export ones twice. The "PSK" and "SRP" ciphers are harmless, since they're off by default anyway, without appropriate configuration. This cipher list looks rather kludgey. Try "DEFAULT". > 40884 openssl option, adding to 03104000: 0200 (no_sslv3 +no_sslv2 > +cipher_server_preference) > 40884 openssl option, adding to 03104000: 0100 (no_sslv2 > +cipher_server_preference) > 40884 openssl option, adding to 03104000: 0040 > (cipher_server_preference) > 40884 setting SSL CTX options: 0x3504000 > 40884 Diffie-Hellman initialized from default with 2048-bit prime > 40884 ECDH OpenSSL 1.0.2+ temp key parameter settings: autoselection > 40884 tls_certificate file '/letsencrypt/certs/mail.domain.com/fullchain.pem' > 40884 tls_privatekey file '/letsencrypt/certs/mail.domain.com/privkey.pem' > 40884 Initialized TLS > 40884 required ciphers: > ALL:!EXPORT:!DES:!RC2:!RC4:!MD5:!PSK:!aNULL:!eNULL:!EXP:!SRP:!DSS:!DHE:!3DES > 40884 host in tls_verify_hosts? no (option unset) > 40884 host in tls_try_verify_hosts? no (end of list) > 40884 SMTP>> 220 TLS go ahead > 40884 Calling SSL_accept > 40884 SSL_accept: before/accept initialization > 40884 SSL3 alert write:fatal:handshake failure That rather looks like your own server is initiating the handshake failure. It is writing the alert, not reading a remote alert. > 40884 SSL_accept: error in error > 40884 SSL_accept: error in error I haven't seen that one much. Perhaps an issue in the Exim OpenSSL glue code. > 40884 TLS error '(SSL_accept): error:1408A0C1:SSL > routines:ssl3_get_client_hello:no shared cipher' > > 40884 LOG: MAIN > 40884 TLS error on connection from mail.externaldomain.com [1.2.3.4] > I=[192.168.1.3]:25 (SSL_accept): error:1408A0C1:SSL > routines:ssl3_get_client_hello:no shared cipher > 40884 TLS failed to start The server does not believe it has any shared ciphers available. You should also check the system-wide "openssl.cnf" file for any vendor configured protocol or cipher restrictions. > > wireshark dump from client hello This does not look like the entire client hello message. > > Cipher Suites Length: 24 > Cipher Suites (12 suites) > Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 > (0xc02b) > Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) > Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 > (0xc023) > Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) > Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) > Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d) > Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c) > Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d) > Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c) > Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) > Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) > Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) > Compression Methods Length: 1 > Compression Methods (1 method) > Compression Method: null (0) > Extensions Length: 51 > Extension: supported_groups (len=4) > Type: supported_groups (10) > Length: 4 > Supported Groups List Length: 2 > Supported Groups (1 group) > Supported Group: secp256r1 (0x0017) > Extension: ec_point_formats (len=2) > Type: ec_point_formats (11) > Length: 2 > EC point formats Length: 1 > Elliptic curves point formats (1) > EC point format: uncompressed (0) > Extension: signature_algorithms (len=20) > Type: signature_algorithms (13) > Length: 20 > Signature Hash Algorithms Length: 18 > Signature Hash Algorithms (9 algorithms) > Signature Algorithm: rsa_pkcs1_sha256 (0x0401) > Signature Hash Algorithm Hash: SHA256 (4) > Signature Hash Algorithm Signature: RSA (1) > Signature Algorithm: rsa_pkcs1_sha384 (0x0501) > Signature Hash Algorithm Hash: SHA384 (5) > Signature Hash Algorithm Signature: RSA (1) > Signature Algorithm: rsa_pkcs1_sha1
Re: [exim] TLS error no shared cipher with SSL_accept: error in error
Am 31.05.21 um 13:44 schrieb Marcin Gryszkalis via Exim-users: Hi, I have problem with one server connecting to my exim. Just after Client Hello server sends "Handshake Failure" and closes connection. exim's cipher list is wide ALL:!EXPORT:!DES:!RC2:!RC4:!MD5:!PSK:!aNULL:!eNULL:!EXP:!SRP:!DSS:!DHE:!3DES and contains ciphers that are mentioned by client, the same for curves, signatures etc. The only difference is extended_master_secret is not supported by exim but I guess it should be ignored. The client did not offer a cipher you have allowed. You can do various tests to find out with openssl's s_client: Firts find out, what you would offer with openssl: $ openssl ciphers now you can compare it with the list the client send or you do it the hard way and test it manually: Examples: $ openssl s_client --connect c1:25 -starttls smtp -ssl3 CONNECTED(0003) 140007688099648:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:ssl/record/rec_layer_s3.c:1543:SSL alert number 40 2021-05-31 14:32:15 TLS error on connection from (mail.example.com) [XXX] (SSL_accept (SSLv3)): error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol $ openssl s_client --connect c1:25 -starttls smtp -tls1 -cipher RSA-PSK-AES128-CBC-SHA ( this one would work with tls1_3+ only ) CONNECTED(0003) 140164130756416:error:141A90B5:SSL routines:ssl_cipher_list_to_bytes:no ciphers available:ssl/statem/statem_clnt.c:3801:No ciphers enabled for max supported SSL/TLS version 2021-05-31 14:34:42 TLS error on connection from (mail.example.com) [XXX] (SSL_accept): error:140940F4:SSL routines:ssl3_read_bytes:unexpected message TLS 1.3: $ openssl s_client --connect c1:25 -starttls smtp -tls1_3 -cipher RSA-PSK-AES128-CBC-SHA 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/
