Sykje yn Support

Mij stipescams. Wy sille jo nea freegje in telefoannûmer te beljen, der in sms nei ta te stjoeren of persoanlike gegevens te dielen. Meld fertochte aktiviteit mei de opsje ‘Misbrûk melde’.

Mear ynfo

Dizze konversaasje is argivearre. Stel in nije fraach as jo help nedich hawwe.

thunderbird keeps using tls1 for IMAP

  • 6 antwurd
  • 1 hat dit probleem
  • 1 werjefte
  • Lêste antwurd fan marek.zukal

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

Keazen oplossing

Confirmed as a server problem.

Dit antwurd yn kontekst lêze 👍 0

Alle antwurden (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

Bewurke troch christ1 op

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

Keazen oplossing

Confirmed as a server problem.