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.

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.

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

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

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

I can't explain that either.

Confirmed as a server problem.