Thunderbird is not connecting to SSL servers on new machine
Hello! After installing Thunderbird on a new machine and copying over data folder, the app is not connecting to SSL servers. Connection is fine via plaintext. I have gathered debug logs from POP3 on both machines (gathered more or less on the same time).
Old one (working fine): [(null) 22384: Main Thread]: D/POP3 [this=1553F580] LoadUrl() [(null) 22384: Main Thread]: D/POP3 [this=1553F580] Initialize() [(null) 22384: Main Thread]: I/POP3 [this=1553F580] Connecting to server SERVERNAME:995 [(null) 22384: Main Thread]: D/POP3 [this=1553F580] Setting server busy in nsPop3Protocol::LoadUrl() [(null) 22384: Main Thread]: I/POP3 [this=1553F580] Entering NET_ProcessPop3 38 [(null) 22384: Main Thread]: I/POP3 [this=1553F580] Entering state: 1 [(null) 22384: Main Thread]: I/POP3 [this=1553F580] Entering state: 2 [(null) 22384: Main Thread]: I/POP3 [this=1553F580] Entering state: 4 [(null) 22384: Main Thread]: I/POP3 [this=1553F580] RECV: +OK Dovecot SERVERNAME ready. [(null) 22384: Main Thread]: I/POP3 [this=1553F580] Entering state: 28 [(null) 22384: Main Thread]: D/POP3 [this=1553F580] SendCapa()
New one (in UI connection hangs): 2020-10-04 17:49:56.504000 UTC - [(null) 7460: Main Thread]: D/POP3 [this=326C5740] LoadUrl() 2020-10-04 17:49:56.504000 UTC - [(null) 7460: Main Thread]: D/POP3 [this=326C5740] Initialize() 2020-10-04 17:49:56.504000 UTC - [(null) 7460: Main Thread]: I/POP3 [this=326C5740] Connecting to server SERVERNAME:995 2020-10-04 17:49:56.504000 UTC - [(null) 7460: Main Thread]: D/POP3 [this=326C5740] Setting server busy in nsPop3Protocol::LoadUrl() 2020-10-04 17:49:56.642000 UTC - [(null) 7460: Main Thread]: I/POP3 [this=326C5740] Entering NET_ProcessPop3 0 2020-10-04 17:49:56.642000 UTC - [(null) 7460: Main Thread]: I/POP3 [this=326C5740] Entering state: 24 2020-10-04 17:49:56.642000 UTC - [(null) 7460: Main Thread]: I/POP3 [this=326C5740] Entering state: 25 2020-10-04 17:49:56.642000 UTC - [(null) 7460: Main Thread]: D/POP3 [this=326C5740] Clearing server busy in POP3_FREE 2020-10-04 17:49:56.642000 UTC - [(null) 7460: Main Thread]: D/POP3 [this=326C5740] Clearing running protocol in POP3_FREE 2020-10-04 17:49:56.642000 UTC - [(null) 7460: Main Thread]: D/POP3 [this=326C5740] ~nsPop3Protocol() 2020-10-04 17:49:56.642000 UTC - [(null) 7460: Main Thread]: D/POP3 sink: [this=2B896820] Calling ReleaseFolderLock from ~nsPop3Sink 2020-10-04 17:49:56.642000 UTC - [(null) 7460: Main Thread]: D/POP3 sink: [this=2B896820] ReleaseFolderLock haveSemaphore = FALSE
I have also connected manually through openssl s_client library on new machine and it works fine so I am running out of ideas. Please advise!
Seçilen çözüm
It would help if you name the server, so we can check its TLS version. The TLS may be OK, but maybe it's caused by the 'self-signed certificate' bug.
I would also try a new profile, in case copying the old one introduced some unknown factor. Help/Troubleshooting, about:profiles, create a new profile and add an account.
Bu yanıtı konu içinde okuyun 👍 0Tüm Yanıtlar (11)
Unfortunately it doesn't. After degrading TLS version the problem still occurs.
Run in Windows safe mode to test if a startup app such as security/AV is interfering with secure connections (such as Bitdefender, Kaspersky etc. are known to do).
Hi sfhowes, Unfortunately I can't run this setup in safe mode as then WiFi doesn't work (including "Safe mode with networking" option). However I was doing trials with disabling AV system - doesn't help. I am also using the same AV system (ESET) on the old machine.
I am fairly confident that problem lays in Thunderbird itself, but I have no clues where to look for it.
I think you may be able to run in safe mode with networking through wifi by following these instructions.
Changing security.tls.version.min may not be sufficient, if that's the cause:
https://support.mozilla.org/en-US/questions/1295861#answer-1349690
Hi sfhowes, Thanks for linking this post, but unfortunately still no success :( I've set both options (security.tls.version.min to 1 and security.tls.version.enable-deprecated to true) and still no success.
Is there any way to debug SSL connection to see where it hangs? I was trying to play around with logging levels and modules, but I couldn't isolate something that would be helpful for my case.
Seçilen çözüm
It would help if you name the server, so we can check its TLS version. The TLS may be OK, but maybe it's caused by the 'self-signed certificate' bug.
I would also try a new profile, in case copying the old one introduced some unknown factor. Help/Troubleshooting, about:profiles, create a new profile and add an account.
That was peculiar...
I have tried once again - no luck. I have created new profile - it works! So I got back to my profile to compare settings - no difference. And then I tried to fetch mails on my old profile - it worked. Not sure what got changed - I am fairly confident I haven't changed anything between then and now, but it started working after this attempt with new profile... Thanks for everyone involved!
Glad to hear it's working. I suspect ESET did a silent update that corrected its settings.
Are you back to the default TLS version settings in tb?
gd_smith That was also my first suspect after seeing connections passing through, but I double checked - I am on defaults now