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

UNCONFIRMED
Unassigned

Status

Thunderbird
Security
--
major
UNCONFIRMED
3 years ago
2 years ago

People

(Reporter: Jim Moe, Unassigned)

Tracking

({regression})

38 Branch
x86_64
All
regression

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [regression:TB38][support], URL)

(Reporter)

Description

3 years ago
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.
(Reporter)

Comment 1

3 years ago
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?

Updated

3 years ago
Severity: critical → major
Priority: P5 → --

Updated

3 years ago
Component: Untriaged → Security
Keywords: regression
Summary: After upgrade to v38.1.0 cannot get emails → After upgrade to v38.1.0 cannot get emails (using self-signed SSL certificates)

Comment 2

3 years ago
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
(Reporter)

Comment 3

3 years ago
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.
(Reporter)

Comment 4

3 years ago
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

3 years ago
[Blocking Requested - why for this release]:
blocking-b2g: --- → 2.0?

Comment 6

3 years ago
(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.
Flags: needinfo?(vseerror)

Comment 7

3 years ago
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
blocking-b2g: 2.0? → ---
Depends on: 1138554
Flags: needinfo?(vseerror) → needinfo?(mkmelin+mozilla)
Summary: After upgrade to v38.1.0 cannot get emails (using self-signed SSL certificates) → After upgrade to v38.1.0 cannot get emails (using self-signed SSL certificates with 512bit keys )

Comment 9

3 years ago
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.
Flags: needinfo?(mkmelin+mozilla)
(Reporter)

Comment 10

3 years ago
(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

3 years ago
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

2 years ago
(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
You need to log in before you can comment on or make changes to this bug.