1185060 - After upgrade to v38.1.0 cannot get emails (using self-signed SSL certificates with 512bit keys ) because of Logjam/weak Diffie-Hellman key mitigation

Status: RESOLVED WONTFIX

(Thunderbird :: Security, defect)

Description

[Jim Moe]

linux v3.16.7-21-desktop x86_64
opensuse v13.2

Upgraded to v38.1.0
Selected the Inbox
Selected a message using IMAP (I do not know if this affects POP)
Nothing happens except the spinner (the moving-back-and-forth box) spins forever

The above applies to ALL mailboxes.

Should have opened the message for viewing.

None of these made any difference:
- I ran in Safe Mode with Addons disabled.
- I reverted to v31.x
- I re-installed v38.1.0

Newsgroups work as expected.

Comment 1

[Jim Moe]

The problem is how TB now handles SSL certificates that are self-signed. I.e., it now handles them by hanging forever waiting for something.

We have our own local mail server that uses a self-signed certificate. Since it is local, locally maintained, it is fairly trustworthy. TB apparently feels differently even though it has the server's certificates in its Accept list.

After changing the IMAP protocol to use NO encryption, I can again read emails.

How do I modify this new "feature" so that I may read mail over an encrypted channel?

Comment 2

[Matt]

When using TLS does Thunderbird report in the error console problems with weak Diffie-Hellman? 

Is server using export cipher suites and 512-bit keys?  These are disabled in Thunderbird 38 by Bug 1138554

Comment 3

[Jim Moe]

Error console message:

Timestamp: 07/18/2015 07:55:32 PM
Error: An error occurred during a connection to imap.sma.com:993.
The server certificate included a public key that was too weak.
(Error code: ssl_error_weak_server_cert_key)

The self-signed certificate uses a 512-bit key.

Comment 4

[Jim Moe]

I changed the Certificate on the mail server to use a 2048 key size. TB finds that acceptable.

> "The server certificate included a public key that was too weak"
>
Really? A more explicit message would have been useful, like a pop-up informing the user of the designer's opinion. And who has decided the relative merits of key strength?

Comment 5

[cbn10310]

[Blocking Requested - why for this release]:

Comment 6

[Matt]

(In reply to Jim Moe from comment #4)
> I changed the Certificate on the mail server to use a 2048 key size. TB
> finds that acceptable.
> 
> > "The server certificate included a public key that was too weak"
> >
> Really? A more explicit message would have been useful, like a pop-up
> informing the user of the designer's opinion. And who has decided the
> relative merits of key strength?

A pop up in this day and age,  or anything that interferes with the users flow of actions is not something anyone would seriously consider.  Given the so called export keys (512bits) are out of date by some 15 years, Or at least the restrictions that forced their introduction.

I think the issue is as much, who thinks they should be using encryption that is trivial to break.  Disabling 512bit keys is not really a whim of some designer as you infer.  It is a block imposed to stop a very real risk of a man in the middle attack on a compromised technology.  

I think this bug is invalid, as the failure is by design resulting from Bug 1138554. But before I go there;  
Why is this bug flagged as blocking on Firefox O/S?
Should the bug be re-purposed to improve user notification?  After all failure to functionally connect is fairly fatal in a mail client.

Comment 7

[Wayne Mery (:wsmwk)]

I agree we should be more informative. Perhaps Magnus will have an idea


(In reply to cbn10310 from comment #5)
> [Blocking Requested - why for this release]:

please do not set flags you don't understand

Comment 8

[Wayne Mery (:wsmwk)]

http://thunderbirdtweaks.blogspot.com.au/2015/07/logjam-and-thunderbird.html

https://support.mozilla.org/en-US/questions/1072502
https://support.mozilla.org/en-US/questions/1072227
https://support.mozilla.org/en-US/questions/1072338
https://support.mozilla.org/en-US/questions/1072804
https://support.mozilla.org/en-US/questions/1072209

https://support.mozilla.org/en-US/questions/1072871
https://support.mozilla.org/en-US/questions/1072942
https://support.mozilla.org/en-US/questions/1073218
https://support.mozilla.org/en-US/questions/1073156
https://support.mozilla.org/en-US/questions/1072010
https://support.mozilla.org/en-US/questions/1073841

Comment 9

[Magnus Melin [:mkmelin]]

I agree it would be preferable to be more informative. IIRC from other cases the security libraries doesn't really let us do that, and they were unwilling to make changes in that regard.

Comment 10

[Jim Moe]

(In reply to Matt from comment #6)
> 
> A pop up in this day and age,  or anything that interferes with the users
> flow of actions is not something anyone would seriously consider.
> 
TB had already "interfered with the users actions" by silently refusing to do perform its reason to exist, with no indication of why. If not a popup, then some other method. It is indeed something someone should seriously consider.

If the designers feel sufficiently strong that 512 bit encryption is ridiculously weak, that should also be part of the message of refusal to perform. How is forcing the user to use encryption with 0 (zero) bits a bonus for the user (until the server admin updates the certificate)?

Yes, using this report to fix the silence problem, to provide user notification, is fine by me.

Comment 11

[DanielCra]

I have a similar problem when using self-signed certificates for Email encryption (S-MIME/X.509). Thunderbird 38.1.0 no longer accepts self-signed certificates for this purpose either.

My proposal is to introduce a feature that I found in several other mail clients: in the GUI list of certificates, give the user the possibility to explicitly click "Trust this certificate. Period."

The whole last year I was facing problems with self-signed certificate due to bug 1036338. It has cost me countless hours and now a similar bug breaks encryption again. Please give us a simple way to deal with this. The complex stuff seems out of control. When I install a self-signed certificate, I know that it can be trusted. No need to look for a trust chain.

Manual override is what is needed!

Thank you very much.

Comment 12

[Wayne Mery (:wsmwk)]

(In reply to Jim Moe from comment #10)
>..
> Yes, using this report to fix the silence problem, to provide user
> notification, is fine by me.

iirc, this is covered in bug 1187797

Comment 13

[Randy Barlow]

Fedora is tightening its security policy[0] to require 2048 bit DH primes in the upcoming Fedora 28 release. Thunderbird does not give an error message when it encounters a server with primes shorter than the crypto policy allows, which makes it difficult to debug. I hit this problem today and Thunderbird didn't give any indication that there were errors, it just didn't show me e-mails from my IMAP server. It didn't even indicate that it wasn't connecting to the IMAP server. I ended up using Evolution to see that it was weak DH keys on the server. Can we get Thunderbird to give an error message when this happens?


[0] https://fedoraproject.org/wiki/Changes/StrongCryptoSettings

Comment 14

[Magnus Melin [:mkmelin]]

Randy: please file a new bug for that. If you have a server for testing, that could be useful

Comment 15

[Randy Barlow]

Sure, new bug reported at https://bugzilla.mozilla.org/show_bug.cgi?id=1457575

Comment 16

[Kai Engert [:KaiE:]]

We have two issues.

First, we lack proper UI reporting if SSL/TLS connections go wrong. We should improve that. That should be handled in bug 1187797.

Second, the inability to allow connections to certain servers. This is decided by the maintainers of the NSS security library, who maintain the implementation of the SSL/TLS protocol that Thunderbird uses. From my past experience working with them, they usually make reasonable decisions, to achieve compromises between backwards compatibility, and avoiding new security issues.

If the NSS maintainers decide that a certain type of connection shall no longer be permissible, then Thunderbird should follow that decision. The correct solution is then for server operators to fix their server configuration, which usually is possible without much trouble.

Again, the important part is bug 1187797, in order to allow users to identify the reason for failures, and get server admins to perform the required security hardening.

So, I'd like to mark this bug as wontfix, because we are unable to allow overriding of connections to servers with insecure settings.