Bug: Problem to establish ssl-connection with some server-certificates
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-10-14 16:17:44+00:00
Resolved: 2020-10-16 11:31:48+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:81.0) Gecko/20100101 Firefox/81.0

Steps to reproduce:

After the automatic Update to TB 78.x.x connection to an existing Mail-Account is not more possible.

This issue appears only when using TB78.x.x (tested on Windows10Pro and MacOS). Earlier versions of TB (tested up to TB 68.12.1 on different OS) have no connection problems. Other Mailclients like PegasusMail, "Mail" under MacOS and mailclients for Android don't have any problems either.

I tested the pure SSL-connection with the OpenSSL buid-in server:

$> openssl s_server -key mykey.key -cert mycert.pem -accept 993

I tried this with OpenSSL V2.2.2d on OpenSuSE Leap 15.2 and with OpenSSL V2.2.2f on Ubuntu 20.04.


Actual results:

Server side Output when using TB 78.x.x:

Using default temp DH parameters
ACCEPT
ERROR
140378379272640:error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate:ssl/record/rec_layer_s3.c:1544:SSL alert number 42
shutting down SSL
CONNECTION CLOSED

Client shows no popup windows about a security problems with the certificate. There is no error reported by Thunderbird.

Hint: The certificate is self-signed and the server has no "official" name, that can be resolved by a public DNS. Although an entry in the file C:\windows\system32\Drivers\etc\hosts is made.


Expected results:

Output when using TB <=68.12.1

Using default temp DH parameters
ACCEPT
ERROR
140031983149504:error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate:ssl/record/rec_layer_s3.c:1544:SSL alert number 42
shutting down SSL
CONNECTION CLOSED
-----BEGIN SSL SESSION PARAMETERS-----
MG4CAQECAgMEBAITAQQgQdgNFaticUY7+ea63l3BbwwFLgtcnUl7AR4D3rk5Nh0E
IAkZ7WxkjSqyc8p+HydqwnDG+GskDKadJN+2ODlVly0GoQYCBF+HEGeiBAICHCCk
BgQEAQAAAK4HAgUA968doQ==
-----END SSL SESSION PARAMETERS-----
Shared ciphers:TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:AES128-SHA:AES256-SHA
Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA1:RSA+SHA1
Shared Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA1:RSA+SHA1
Supported Elliptic Groups: X25519:P-256:P-384:P-521:0x0100:0x0101
Shared Elliptic groups: X25519:P-256:P-384:P-521
CIPHER is TLS_AES_128_GCM_SHA256
Secure Renegotiation IS NOT supported

After the first server reported error (see above) the client shows a popup window explaining the risks with the certificate. After accepting the security risk the SSL-connection is established.

I expect, that TB 78.x.x behaves like TB 68.12.1 (and other mail-clients). I know about fact that TB 78.x.x does not support TLS1.0 and 1.1 anymore, but OpenSSL 2.2.2d/f supports TLS1.2 and TLS 1.3, so it should be possible to connect to those servers with TB 78.x.x.