1886044 - TLS negotiation fails

Status: RESOLVED INVALID

(Thunderbird :: Account Manager, defect)

Description

I need to reopen this as a clone of bug 1870909
The problem is still existing and is NOT limited to WTNET.de
I am observing the same issue on a private server as well.

Nevertheless WTNET has spent a couple of days successfully reproducing this. But with NO final result/workaround.

As the behavior is intermittent (some mails work immediately - some only after several retries) and is NOT observed from Outlook, Roundcube or other MailAgents I expect a timeout issue, where TB is too fast giving up to wait for the correct answer , thus the TLS tunnel fails.

For what I understood, in both cases Postfix is handling the SMTP and as the TLS-tunnel does not come up there are no errors in the mail logs.

These steps to reproduce are from the original post:

-Trying to send message via mail.wtnet.de,
-SMTP, TCP-Port 465, SSL/TLS, password,normal
-checked password settings and renewed password
-no changes at provider according to hotline
-several similar reports in german support forum
-last known message sent successfully : 18. November 2023

Actual results:

Message "Failed to send message for unknown reason ..." appears

Expected results:

Message sent

Comment 1

[Magnus Melin [:mkmelin]]

Bug 1870909 has a log that proves it's a server side issue. The issue is easily reproduced with nmap which is totally unrelated to Thunderbird.
And like you said, WTNET also reproduced. They will have to find out what's wrong on their end.

Comment 2

[Matthias]

If you mind reading the full details, I confirmed the problem is NOT only with WTNET.

If NMAP would be able to discover the full details of the problem there should be an explanation, why the communication works, when sending several mails, often not when sending a single one, but then it helps going offline with TB before sending and releasing it when going online.

As TB does not provide any details not logs about what failed, I have to insist this issue is NOT resolved!

BR
M.

Comment 3

[Magnus Melin [:mkmelin]]

It does, the log says " cipher preference error: Error when comparing TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 and TLS_DHE_RSA_WITH_AES_256_CBC_SHA"

If you google that, it appears the most likely issue is there is some firewall along the network path that is corrupting the traffic.
Or the server is misconfigured, possibly sending two different certs. Possibly one for ipv4 and one for ipv6.

Comment 4

[mrzippy]

As the submitter of the original bug I'd like to add that due to my persistence WTNET checked their SMTP Server configuration and found no issues. I tried another client (eMclient), and interestingly it showed a "certificate error" on automatic configuration, but after manual configuration with the same data as in TB sending messages was no issue.

Comment 5

[Matthias]

why does it work with several mails but not when sending a single one?
Why do other MTAs not suffer?

I also observed, that the NMAP request sometimes takes longer to complete, for what ever reason. But it completes and I fear that TB is simply inpatient.

I expect a timeout issue!

M.

Comment 6

[gene smith]

I expect a timeout issue!

I don't know if you are still seeing this problem. If you suspect a timeout, the only parameter in TB that might affect network timeout is mailnews.tcptimeout which defaults to 100s. But I doubt that this will help unless wtnet is seeing more than 100s for TB or nmap to respond.

I ran the nmap command shown here: bug 1870909 comment 2. I see the same errors reported there and the time to complete the nmap command is 4.83s. I don't know if those errors are significant.

I can also successfully connect using openssl s_client -connect mail.wtnet.de:465 and execute the ehlo charter.net smtp command.

why does it work with several mails but not when sending a single one?

There is a change that is now in 115 that might affect this. But seem like it would have the opposite effect as you describe. But if you are using 115.9 or later and not seeing the problem any more, then this may have fixed it: Bug 1864924.

If you are still having problems, I can do more testing using TB only with a temporary test account at the wtnet server. You can send me the needed credentials via email.

Comment 7

[gene smith]

I made mail.wtnet.de:465 the outgoing server on another test account. So I can attempt to send a message and monitor the response with wireshark. I have attempted the send at least 3 times and each time the TLSv1.3 tunnel is setup successfully and TB sends the initial EHLO command and the WTNET server responds correctly and waits for authentication. Since I don't have a valid username and password, nothing more is sent and, as expected, after a short time wtnet times out the connection.
This indicates that, if there is still a problem, it occurs later and after the TLS connection is established doing SMTP commands. But, based on what I see with this limited test, the errors reported by nmap are red-herrings.

Comment 8

[Matthias]

Hi guys, thanks for the follow up.

I am unable to give the full details, as I am not running the mailserver. Thus I have no access to the logs or else. My only contact was the level-3-supporter at WTNET. I asked for the details but never received anything that would help to debug/improve TBs reactions. But this is what I understood what they found:

They were able to repro the problem and advised to limit TB to TLSv1.2 (security.tls.version.max = 3).
They claim to have fixed it about month ago and I could return to TLSv1.3 (security.tls.version.max = 4).

When they observed the connection during TLS initialization there were two situations:

1. TB was just started and a new connection was created. This is what happens when returning from offline or a fresh start of TB. Problems only later, when a new mail was to be sent.

2. A previous connection (maybe from POP3 on startup) was still pending. This resulted in denial for the second (SMTP) connection with TB reporting "Failed to send message for unknown reason ..." (not really helpful)

They did (unknown to me) changes to their configuration, which resulted in TB now behaving as expected. ("fixed"?)
As
nmap --script ssl-enum-ciphers -Pn -p 465 mail.wtnet.de
still returns the known
cipher preference error: Error when comparing TLS_DHE_RSA_WITH_AES_256_CBC_SHA and TLS_DHE_RSA_WITH_AES_128_CBC_SHA"

I strongly advised them to fix that configuration as well as "... such bugs show their nasty side when you least need them", but yet neither response nor fix. I was hoping for their feedback to give better details here, but maybe someone has an idea how to make TB more resilient and give better error messages. Yet I even have no advise for any new case. ☹️

(I will forward this answer again to their support. Hopefully they give details directly or pass them to me)
Matthias

Comment 9

[Matthias]

(In reply to gene smith from comment #7)

This indicates that, if there is still a problem, it occurs later and after the TLS connection is established doing SMTP commands. But, based on what I see with this limited test, the errors reported by nmap are red-herrings.

Hi Gene,
while I could create a test account for a DEV to test, I see no point in it. Please check my previous comment, as WTNET claims they found a problem that seem to have occurred even BEFORE (or in an early state of) the TLS handshake.

BTW: is there any warning by TB if TLS handshake fails and the transmission is "plain"?
M.

Comment 10

[gene smith]

BTW: is there any warning by TB if TLS handshake fails and the transmission is "plain"?

Not sure I completely understand the question. But TB never falls back to unencrypted (plain) if the TLS handshake fails. If the handshake fails, the tcp/ip connection is dropped so the message is not sent at all. I suspected that's when you see the "Failed to send message for unknown reason".

Comment 11

[Matthias]

Forget that mental hickup, must have mixed something up.
M.

Comment 12

[Wayne Mery (:wsmwk)]

Where to go from here?

Comment 13

[gene smith]

Re-reading this after a few months, I would say there is not much we can do about this. Also, can't really test it completely without a temporary/test account. So without that, I would say close this as invalid.