Mailing List Archive

TLS error no shared cipher with SSL_accept: error in error
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.

Debug is not really helpful - especially strange "error in error"
message. I don't know if/how I can get more details about reasons of error.

debug output

40884 openssl option, adding to 03104000: 02000000 (no_sslv3
+no_sslv2 +cipher_server_preference)
40884 openssl option, adding to 03104000: 01000000 (no_sslv2
+cipher_server_preference)
40884 openssl option, adding to 03104000: 00400000
(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
40884 SSL_accept: error in error
40884 SSL_accept: error in error
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

40884 LOG: smtp_connection MAIN
40884 SMTP connection from mail.externaldomain.com [1.2.3.4]
I=[192.168.1.3]:25 closed by EOF



wireshark dump from client hello

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 (0x0201)
Signature Hash Algorithm Hash: SHA1 (2)
Signature Hash Algorithm Signature: RSA (1)
Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403)
Signature Hash Algorithm Hash: SHA256 (4)
Signature Hash Algorithm Signature: ECDSA (3)
Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503)
Signature Hash Algorithm Hash: SHA384 (5)
Signature Hash Algorithm Signature: ECDSA (3)
Signature Algorithm: ecdsa_sha1 (0x0203)
Signature Hash Algorithm Hash: SHA1 (2)
Signature Hash Algorithm Signature: ECDSA (3)
Signature Algorithm: SHA1 DSA (0x0202)
Signature Hash Algorithm Hash: SHA1 (2)
Signature Hash Algorithm Signature: DSA (2)
Signature Algorithm: rsa_pkcs1_sha512 (0x0601)
Signature Hash Algorithm Hash: SHA512 (6)
Signature Hash Algorithm Signature: RSA (1)
Signature Algorithm: ecdsa_secp521r1_sha512 (0x0603)
Signature Hash Algorithm Hash: SHA512 (6)
Signature Hash Algorithm Signature: ECDSA (3)
Extension: session_ticket (len=0)
Type: session_ticket (35)
Length: 0
Data (0 bytes)
Extension: extended_master_secret (len=0)
Type: extended_master_secret (23)
Length: 0
Extension: renegotiation_info (len=1)
Type: renegotiation_info (65281)
Length: 1
Renegotiation Info extension
Renegotiation info extension length: 0

--
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: TLS error no shared cipher with SSL_accept: error in error [ In reply to ]
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: 02000000 (no_sslv3 +no_sslv2 +cipher_server_preference)
> 40884 openssl option, adding to 03104000: 01000000 (no_sslv2 +cipher_server_preference)
> 40884 openssl option, adding to 03104000: 00400000 (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 (0x0201)
> Signature Hash Algorithm Hash: SHA1 (2)
> Signature Hash Algorithm Signature: RSA (1)
> Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403)
> Signature Hash Algorithm Hash: SHA256 (4)
> Signature Hash Algorithm Signature: ECDSA (3)
> Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503)
> Signature Hash Algorithm Hash: SHA384 (5)
> Signature Hash Algorithm Signature: ECDSA (3)
> Signature Algorithm: ecdsa_sha1 (0x0203)
> Signature Hash Algorithm Hash: SHA1 (2)
> Signature Hash Algorithm Signature: ECDSA (3)
> Signature Algorithm: SHA1 DSA (0x0202)
> Signature Hash Algorithm Hash: SHA1 (2)
> Signature Hash Algorithm Signature: DSA (2)
> Signature Algorithm: rsa_pkcs1_sha512 (0x0601)
> Signature Hash Algorithm Hash: SHA512 (6)
> Signature Hash Algorithm Signature: RSA (1)
> Signature Algorithm: ecdsa_secp521r1_sha512 (0x0603)
> Signature Hash Algorithm Hash: SHA512 (6)
> Signature Hash Algorithm Signature: ECDSA (3)
> Extension: session_ticket (len=0)
> Type: session_ticket (35)
> Length: 0
> Data (0 bytes)
> Extension: extended_master_secret (len=0)
> Type: extended_master_secret (23)
> Length: 0
> Extension: renegotiation_info (len=1)
> Type: renegotiation_info (65281)
> Length: 1
> Renegotiation Info extension
> Renegotiation info extension length: 0

And where's the server's reply (HELLO or alert?)?

--
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: TLS error no shared cipher with SSL_accept: error in error [ In reply to ]
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(00000003)
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)
[XXXXXXXXXXX] (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(00000003)
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)
[XXXXXXXXXXX] (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/
Re: TLS error no shared cipher with SSL_accept: error in error [ In reply to ]
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: 02000000 (no_sslv3 +no_sslv2 +cipher_server_preference)
>> 40884 openssl option, adding to 03104000: 01000000 (no_sslv2 +cipher_server_preference)
>> 40884 openssl option, adding to 03104000: 00400000 (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.000000000 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 (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 (0x0201)
>> Signature Hash Algorithm Hash: SHA1 (2)
>> Signature Hash Algorithm Signature: RSA (1)
>> Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403)
>> Signature Hash Algorithm Hash: SHA256 (4)
>> Signature Hash Algorithm Signature: ECDSA (3)
>> Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503)
>> Signature Hash Algorithm Hash: SHA384 (5)
>> Signature Hash Algorithm Signature: ECDSA (3)
>> Signature Algorithm: ecdsa_sha1 (0x0203)
>> Signature Hash Algorithm Hash: SHA1 (2)
>> Signature Hash Algorithm Signature: ECDSA (3)
>> Signature Algorithm: SHA1 DSA (0x0202)
>> Signature Hash Algorithm Hash: SHA1 (2)
>> Signature Hash Algorithm Signature: DSA (2)
>> Signature Algorithm: rsa_pkcs1_sha512 (0x0601)
>> Signature Hash Algorithm Hash: SHA512 (6)
>> Signature Hash Algorithm Signature: RSA (1)
>> Signature Algorithm: ecdsa_secp521r1_sha512 (0x0603)
>> Signature Hash Algorithm Hash: SHA512 (6)
>> Signature Hash Algorithm Signature: ECDSA (3)
>> Extension: session_ticket (len=0)
>> Type: session_ticket (35)
>> Length: 0
>> Data (0 bytes)
>> Extension: extended_master_secret (len=0)
>> Type: extended_master_secret (23)
>> Length: 0
>> Extension: renegotiation_info (len=1)
>> Type: renegotiation_info (65281)
>> Length: 1
>> Renegotiation Info extension
>> Renegotiation info extension length: 0
>


> And where's the server's reply (HELLO or alert?)?

it's next packet:

Transport Layer Security
TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Handshake
Failure)
Content Type: Alert (21)
Version: TLS 1.2 (0x0303)
Length: 2
Alert Message
Level: Fatal (2)
Description: Handshake Failure (40)


--
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: TLS error no shared cipher with SSL_accept: error in error [ In reply to ]
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(00000004)
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: TLS error no shared cipher with SSL_accept: error in error [ In reply to ]
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: TLS error no shared cipher with SSL_accept: error in error [ In reply to ]
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: TLS error no shared cipher with SSL_accept: error in error [ In reply to ]
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: TLS error no shared cipher with SSL_accept: error in error [ In reply to ]
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: TLS error no shared cipher with SSL_accept: error in error [ In reply to ]
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(00000004)
> 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: TLS error no shared cipher with SSL_accept: error in error [ In reply to ]
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: TLS error no shared cipher with SSL_accept: error in error [ In reply to ]
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: TLS error no shared cipher with SSL_accept: error in error [ In reply to ]
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: TLS error no shared cipher with SSL_accept: error in error [ In reply to ]
On 2021-06-01 Marcin Gryszkalis via Exim-users <exim-users@exim.org> 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/