Thunderbird 102.0.3 update fixes a crash on Windows 11
The Thunderbird team has released Thunderbird 102.0.3 Stable. The new version of the open source email client fixes a crash on Windows 11 and several other issues in previous versions of the application.
Thunderbird 102.0.3 is already available, either as an in-client upgrade or a manual download from the official project website. Only Thunderbird 102.x installations can be upgraded to the new version. Older Thunderbird installations do not get the upgrade offer to version 102 at this point, but this is going to change in the future.
Thunderbird 102.0.3
Select Help > About Thunderbird to display the current version and check for updates. If the menubar is not displayed, tap on the Alt-key on the keyboard to display it. The client should pick up the update automatically. A restart is required to complete the installation of the update.
The official changelog lists 12 changes that made it into Thunderbird 102.0.3. Windows users who run Thunderbird 102 on Microsoft's Windows 11 operating system may have hade the client crash on startup; this issue has been fixed in the new release.
The only change listed in the changelog is the removal of support for Google Talk chat accounts. Thunderbird 102 supports Matrix, Odnoklassniki, IRC and XMPP currently.
Access to downloaded messages was not provided in previous versions of Thunderbird after folders were compacted by the client. Compacting reduces the storage that Thunderbird requires on the local device. The developers have addressed the issue in the new release.
The following fixes are also listed:
- When using Unified Folders, marking a message as a favorite (starring it) did not update the thread pane.
- When S/MIME was configured, Compose failed to populate some fields.
- The incorrect mime header charset=windows-1250 was set for non-text attachments.
- The incorrect header X-Mozilla-Cloud-Part was set for messages sent as attachments.
- Address book importing and exporting has been improved in the profile importer.
- Unspecified IMAP stability improvements.
- Addressed an issue that made the offline cache unusable for NNTP accounts.
- Signing S/MIME messages failed.
- Unspecified UI improvements.
Thunderbird 102.0.3 is the third point release of version 102 of the email client. Thunderbird 102 was a major new release with a large list of improvements and new features. The point releases 102.0.1 and 102.0.2 addressed issues in the new version, similarly to version 102.0.3.
Now You: do you use Thunderbird 102 already?
@owl
Nope, already tried, again right now to be sure.
The 91.13.0 works even with the OCSP enabled, the 102.x doesn’t work no matter if OCSP disabled.
I think the “added” CA (and also the added trusted servers) are completely ignored in the 102.x.
@owl
Thank you for your answer. I am aware of some antivirus software that intercept SSL connections and behave like man-in-the-middle. Unfortunately this is not the case; none of the machines have any of those software. With those antivirus, even previous versions of Thunderbird don’t work.
I experimented with certificated emitted by a new CA with sha384 (the current use sha256) and different parameters, but no. Current versions don’t work. It seems that the imported (and trusted) CA certificate is completely ignored: the behaviour is exaclty the same as previous versions if I remove the CA cert.
Our CA lacks an OCSP responder but the URI to download the cert is present and working – however even deactivating the relevant OCSP option in Thunderbird doesn’t change anything.
BTW, I am just working remotely to downgrade several Thunderbirds to 91.13.0 and your information about -allow-downgrade really saved my day, so I am particularly thankful!
Andrea
@Andrea Baldoni,
> If you have approved it as a security exception and it is still not working, it seems to me that a timeout by OCSP is the cause.
> Menu > Options > Privacy and Security > Certificates > Query the OCSP responder server for the current validity of the certificate.
> You can disable verification by OCSP
> Corresponds to security.OCSP.enabled in the configuration editor (1 for enabled, 0 for disabled).
I have exactly the same problem. Thunderbird 102.x (included last version 102.2.1) won’t connect anymore to Dovecot, with a (valid and made correctly) certificate issued by our CA.
TLSv1.3, the logged error is
SSL routines::sslv3 alert bad certificate: SSL alert number 42
The CA has been inserted in Thunderbird’s cert authority and trusted. Of course everything worked until 91.9.1.
This is a real problem because Thunderbird (despite they say it won’t) self-upgrades and there are dozen of servers using certs issued by our CA, each used by many thunderbird clients.
Now we are instructing users to downgrade and block further upgrades, but this is complicated by the fact that the profiles are not backward compatible and you should reconfigure all by scratch.
I made an account and informed about the problem in their bugzilla system, but my post curiously disappeared!
A real mess.
Andrea.
Sentence Correction:
Before correction,
Mozilla recommends against using this (scan SSL/TLS) function because “it is similar to a ‘man-in-the-middle attack’,” a method of eavesdropping and tampering”.
After correction,
Mozilla recommends against using this (scan SSL/TLS) function because “it is no difference to a ‘man-in-the-middle attack’,” a method of eavesdropping and tampering”.
Before correction,
If you trust the third-party security vendor unconditionally, you may use it, but it will defeat the purpose of “encrypted communication (data will be collected by the security vendor)” and cause unnecessary trouble.
After correction,
If you trust the third-party security vendor unconditionally, you may use it, but it will defeat the purpose of “encrypted communication” (In that case, all the scan data will definitely be collected by the security vendor) and cause unnecessary trouble.
@Andrea Baldoni,
In this case,
the cause appears to be a “third-party security software function that intervenes and scans SSL/TLS communications”.
What this type of functionality is doing is that the security software interrupts the encrypted communication between the server and the browser, and changes the route from the browser intermediate host server, so that the communication goes through the intermediate host.
Mozilla recommends against using this (scan SSL/TLS) function because “it is similar to a ‘man-in-the-middle attack’,” a method of eavesdropping and tampering”.
If you trust the third-party security vendor unconditionally, you may use it, but it will defeat the purpose of “encrypted communication (data will be collected by the security vendor)” and cause unnecessary trouble.
Security software imports its own root certificates at the same time as the software is installed “to scan SSL/TLS communications”.
But here is the problem: Thunderbird (Firefox), unlike Chrome, Edge, etc., has its own certificate store and does not reference the Windows certificate store by default.
Any software that supports Thunderbird (Firefox) will import certificates to Thunderbird (Firefox) at the same time it imports certificates to Windows.
But then what happens if Thunderbird (Firefox) is re-installed, or if there is a specification change in the version upgrade?
Yes, the encrypted communication is not connected, and Thunderbird (Firefox) thinks it is sending the communication to the server, but it is not reaching the server.
In short,
the solution is to disable “the kind of functionality that intervenes and scans SSL/TLS communications by that third-party security software”, but if it is deemed absolutely necessary, request support for “Thunderbird 102” from that vendor.
If the vendor does not respond, there will be no solution, and until then, you will need to “disable that functionality”.
As a side note,
regarding downgrades:
The “profile” that started with the major upgrade version 102.x cannot be reused with the downgrade version (91.13).
If you want to downgrade and use the same profile,
unable launch older version on profile | Thunderbird Help
https://support.mozilla.org/en-US/kb/unable-launch-older-version-profile
Based on the article “unable launch older version on profile”,
Dedicated profile per Thunderbird installation | Thunderbird Help
https://support.mozilla.org/en-US/kb/dedicated-profile-thunderbird-installation
is details are described in.
Note: Downgrade protection can be overridden by starting Thunderbird from the command line with the –allow-downgrade parameter.
when Thunderbird series version 102 there is security fixes, then jumped from Thunderbird version 91.11.0
Thunderbird 102.x does not allow me to connect to my local Dovecot IMAP server and I see this error in the server’s mail log file:
imap-login: Disconnected: Connection closed: SSL_accept() failed:
error:0A000412:SSL routines::sslv3 alert bad certificate: SSL alert
number 42 (disconnected before auth was ready, waited 0 secs): user=,
rip=XXX.XXX.XXX.XXX, lip=XXX.XXX.XXX.XXX, TLS handshaking: SSL_accept()
failed: error:0A000412:SSL routines::sslv3 alert bad certificate: SSL
alert number 42
Downgrade to Thunderbird 91.x or 68.x solves the problem. Notably, other mail clients (Gnus, Claws-Mail, mutt) have no problem to connect. I guess, it’s a bug that was introduced in TB 102. A brief search revealed that this problem occurred for other versions of TB in the past as well. Playing around with OCSP settings (as sometimes suggested) did not help.
The problem is entirely self made. Why do you run a local server? Anyways it literally tells you that you use a bad cert. Whitelist your self-signed cert in the NSS libs/API. Or stop running local servers. How about a real server with a real DNS entry and access that via domain.
Just some food for thought. There is hacks and there is the professional’s way. But i am happy your security downgrade works so good!
Unfortunately, all your assumptions are wrong.
It is a real server with a real DNS entry with a real domain. And of course self signed certificates must never cause a problem. One just needs to accept the certificate by adding it to the exception list. However, TB 102 does not reach this point asking for the certificate.
Besides, it’s also the wrong approach: The certificate hasn’t changed at all and older TB versions successfully connect to the Dovecot IMAP server, just as *every* other legit MUA. TB has been updated from 91.x to 102.x , not the Dovecot server and not the certificate (which is still valid for several years).
Clearly a TB bug …
Useless to argue about this without knowing what versions of the protocol you run, if the clocks on the systems are set correctly and you don’t use outdated TLSv1.1 or any other standard that is not TLSv1.3
Just because it works on an old version doesn’t mean it is “a bug”. Sounds more like me it doesn’t want to connect to deprecated protocols. Why? Because I can access 5 different email provides perfectly fine on my TB.
Report it to the developers then…
As my name says, TB is not my main MUA and I just use it occasionally. Since I don’t have a bugzilla account and I’m not going to create one for this issue, I’m not going to report it there.
I only mentioned it here for the sake of completeness. My regular MUAs perfectly interact with the Dovecot IMAP sever.
JFTR, it’s an older bug that was already reported, closed as fixed and re-introduced now: https://bugzilla.mozilla.org/show_bug.cgi?id=1629416