Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

thunderbird keeps using tls1 for IMAP

more options

Thunderbird keeps using tls1 for IMAP. I tried setting up a new profile and a new account, nothing helps. I trapped the connection in Wireshark. After the connection is established, the first packet is comming from client and is being decoded as this: 794 194.220989596 192.168.88.212 77.92.222.71 TLSv1 583 Client Hello After that the server (MS exchange) kills the connection.

Gmail works fine and using tls1.2. Thunderbird 68.4.1 (64-bit) distribution package Linux Mint 19.3 Tricia

Thunderbird keeps using tls1 for IMAP. I tried setting up a new profile and a new account, nothing helps. I trapped the connection in Wireshark. After the connection is established, the first packet is comming from client and is being decoded as this: 794 194.220989596 192.168.88.212 77.92.222.71 TLSv1 583 Client Hello After that the server (MS exchange) kills the connection. Gmail works fine and using tls1.2. Thunderbird 68.4.1 (64-bit) distribution package Linux Mint 19.3 Tricia

Chosen solution

Confirmed as a server problem.

Read this answer in context 👍 0

All Replies (6)

more options

Thunderbird 68 still supports TLS 1.0 and 1.1, but it also supports TLS 1.2. Not sure about v1.3 though. If Thunderbird negotiates TLS 1.0 or 1.1 when connecting to the server at 77.92.222.71, then this is the best that server supports.

more options

AFAIK TLS is negotiated by the client first.

Wikipedia says this: "A client sends a ClientHello message specifying the highest TLS protocol version it supports ...

And the first packet send by Thunderbird is as above. Only TLS1, no other connections are established, no other data exchanged. This is the first and only packet of negotiation.

I tried to increase security.tls.version.min in config to 2 or 3 but it did not help either.

there is also security.tls.version.fallback-limit key but I could not find any documentation and it does not seem to influence anything.

None of these config values were tempered with in the clean profile to ensure correct testing.

more options
the first packet is comming from client and is being decoded as this: 794 194.220989596 192.168.88.212 77.92.222.71 TLSv1 583 Client Hello After that the server (MS exchange) kills the connection.

Are you saying TB does not establish a TLS connection to that server at all? What is security.tls.version.min set to when this happens?

I tried to increase security.tls.version.min in config to 2

What happens when security.tls.version.min is set to 1, which is the default in TB68?

I still think the server does not support TLS 1.2.

openssl s_client -connect 77.92.222.71:993 </dev/null CONNECTED(00000003) write:errno=0 </p>

no peer certificate available

No client certificate CA names sent

SSL handshake has read 0 bytes and written 176 bytes Verification: OK

New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session:

   Protocol  : TLSv1.2
   Cipher    : 0000
   Session-ID: 
   Session-ID-ctx: 
   Master-Key: 
   PSK identity: None
   PSK identity hint: None
   SRP username: None
   Start Time: 1584816585
   Timeout   : 7200 (sec)
   Verify return code: 0 (ok)
   Extended master secret: no

Modified by christ1

more options

security.tls.version.min does not have any effect

I tried Evolution client and the results are the same. I tried with the openssl command as you did as well. All behave the same. So you are probably right.

However I still do not understand what determines the first packet content. I tried the same with Gmail and got this result: 23 5.087578452 192.168.88.212 64.233.184.109 TLSv1.3 583 Client Hello

Again, no data from the server before the server. It goes -> SYN <- SYN, ACK -> ACK -> Client hello

more options
However I still do not understand what determines the first packet content.

I can't explain that either.

more options

Chosen Solution

Confirmed as a server problem.