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!
Zgjidhje e zgjedhur
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.
Lexojeni këtë përgjigje brenda kontekstit 👍 0Krejt Përgjigjet (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.
Zgjidhja e Zgjedhur
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