2010400 - TLS is (almost) broken when server requests a client certificate

Status: UNCONFIRMED

(MailNews Core :: Networking, defect)

Description

[jl92]

Attachment: TLS negociation.png

Steps to reproduce:

After switching from Debian 13 providing Thunderbird 140 to Fedora 43 providing Thunderbird 146, fetching or sending email became extremely slow. It even fails to send emails sometimes, Thunderbird is then informing of a timeout with the SMTP server. Displaying emails from the mailbox is really slow, too.

The issue can also be seen in the Account Settings, by using the "Test connection to server" tool in the "Server Settings" page of the incoming server : pretty often, but not aways, this test fails with this error "Connection to server xxx:993 failed." after 10 seconds. Repeating this test sometimes leads to a successful one.

As stated, the client is now Thunderbird 146.
The mailbox is using IMAP over TLS to fetch mail. Connection security is set to "TLS Certificate".
The outgoing server is using SMTP over TLS, without an authentication mechanism. The same TLS certificate is used for authentication.

On the server side, I have Postfix 3.10.6 and Dovecot 2.4.2.
Of course since I'm using certificate authentication, Postfix and Dovecot are configured to request a client certificate. With Dovecot this is achieved via ssl_server_request_client_cert=yes, and with smtpd_tls_ask_ccert=yes in Postfix.

Now if I disable "ssl_server_request_client_cert" in Dovecot, the connection test in Server Settings produces an instant positive result all the time. Of course I can no longer access my mailbox since I'm exclusively using certificate authentication.

No issue at all with K-9 mail.

Capturing network traffic between the client and the server in the problematic state shows the client (Thunderbird) hangs while setting up the TLS session. In the attached screenshot from a packet capture, frame 7 is sent by the SMTP server. It’s immediately acknowledged (from a TCP standpoint) by the client (Thunderbird) in frame 8. Then 20 seconds later, the client goes on with the TLS negociation. It can be stuck like that for almost a minute sometimes.

This was an example with SMTP. The observed behaviour is similar with IMAP.
Switching to STARTTLS doesn't change this behaviour.

Looks like it's related to TLS, therefore affecting any protocol depending on it.

Actual results:

Very slow performance fetching or sending an email. Sometimes eventually fails.

Expected results:

Instant TLS session setup, like with TBird 140 previously.