Thunderbird-68.9.0-1.el8_2.x86_64 (CentOS 8) hangs on connection to IMAP server with a self-signed certificate
Categories
(Thunderbird :: Untriaged, defect)
Tracking
(Not tracked)
People
(Reporter: vmarusov, Unassigned)
Details
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0
Steps to reproduce:
In CentOS 8 (Important, since the bug isn't observed in Windows) with Thunderbird-68.9.0-1.el8_2.x86_64
- configure an account <Account_Name> on IMAP server <Server_Name> with a self-signed certificate (example: imap.cern.ch), port:993, Connection security: SSL/TLS, Authentication method: Normal password;
- try to connect to the account
Actual results:
- Thunderbird shows in the status bar:
<Account_Name>: Connected to <Server_Name>... - Nothing related to this account is happening
Expected results:
- In case of a problem with connection/authentication Thunderberd should show an error message;
- If no error occurs, Thunderberd should fetch new emails;
|
||
Comment 1•5 years ago
|
||
|
|
||
Comment 2•5 years ago
|
||
Or actually since you say 68 maybe something else. For 78, those would be it and for 68 whatever it was is likely wontfix now.
|
Reporter | |
Comment 3•5 years ago
|
||
I informed CERN HelpDesk of this problem with connecting to imap.cern.ch. Here is their answer:
Ticket No: INC2470929, Opened: 23-06-2020 15:03:24
Short description: Thunderbird-68.9.0-1.el8_2.x86_64 (CentOS 8) hangs on connection to imap.cern.ch (server with a self-signed certificate?)
Message from Thibaut Blanc:
Good morning,
Please read the mail from our Mail admin :
Exchange 2010 does not support TLS versions other than 1.0 for IMAP.
About POP/IMAP
Exchange Server 2010
The Exchange product updates which allow POP/IMAP to dynamically consume the operating system SChannel configuration settings for POP/IMAP connections are not available in Exchange Server 2010. POP/IMAP are still dependent upon SChannel configuration, but are hard coded to allow TLS 1.0 or SSL 3.0 negotiation only in Exchange Server 2010. As of the posting date for this entry, if TLS 1.0 is disabled in SChannel, clients will fallback and attempt to negotiate SSL 3.0. If SSL 3.0 is disabled, client negotiation will fail. There are no current plans to change this product behavior. Microsoft's implementation of TLS 1.0 has no known vulnerabilities but SSL 3.0 use is strongly discouraged. Customers who need to ensure that TLS 1.2 is used for SMTP / HTTPS traffic may need to add servers specifically configured to support TLS 1.0 only for POP/IMAP if needed in their environment.
So there is nothing we can do until we phase out Exchange 2010.
This is affecting Thunderbird on CentOS 8.
As a workaround you can use mmm.cern.ch
You may update this ticket through the CERN Service Portal, or reply directly to this email.
Kind Regards, IT Support
If they are right, then it would be sufficient to add in the advanced settings the option to limit the set of TSL versions while negotiating with particular server.
For CentOS 8 users the problem is "severe", because Thunderbird-68.9.0 is the only version available in DNF repositories, it's not possible to downgrade.
|
|
Reporter | |
Comment 4•5 years ago
|
||
P.S. Since I am not an IT expert, I still don't understand why there is no problem connecting to imap.cern.ch in Thunderbird-68.9.0 for Windows.
|
|
||
Comment 5•5 years ago
|
||
To enable SSL3, set security.tls.version.min to 0 through the Config Editor. I guess that would help
|
|
Reporter | |
Comment 6•5 years ago
|
||
Unfortunately, this didn't solve the problem... and couldn't solve it, I think, because the task is to force Thunderbird to use TLS 1.0 with a specific (imap.cern.ch, Microsoft Exchange 2010) mail server, while having a wider choice for other servers. I still don’t understand why there is no such problem on Thunderbird 68.9.0 for Windows with exactly the same settings.
|
|
Reporter | |
Comment 7•5 years ago
|
||
It wasn't a Thunderbird bug...
The problem was RESOLVED by changing CentOS 8 encryption policies:
sudo update-crypto-policies --set LEGACY
followed by reboot.
This means that the problem is caused by Exchange Server 2010 restrictions, as correctly described by the CERN Mail administrator.
And nothing to do with certificates...
Description
•