1681960 - handle more cases of bad certificates with proper user feedback

Status: NEW

(Thunderbird :: Security, defect, P2)

Description

[Magnus Melin [:mkmelin]]

+++ This bug was initially created as a clone of Bug #1590474 +++

We should give some feedback for at least:

• bug 1178497 comment 13: cert from a self-signed CA (not self-signed certificate)
• bad SSL version (maybe just output in console)

Comment 1

[Magnus Melin [:mkmelin]]

And when bad domain (bug 1674542). There are also other overridable special cases.
https://searchfox.org/comm-central/search?q=ErrorIsOverridable&path=

Comment 3

[Nils Ohlmeier [:drno]]

I spend several hours debugging the following:

After renewing the Lets Encrypt cert on my IMAPS server Thunderbird stopped silently fetching emails from my server. It turned out that it was caused by LE using a new root cert and my server not sending the whole certificate chain over to Thunderbird. It seems the previous root cert was trusted directly by Thunderbird so only sending over the cert itself worked. But with the new root cert it was no longer trusted without seeing the chain.

Some kind of warning that the cert was not trusted would have been super helpful.

Comment 4

[xandrah]

Seem to be having issues lately with LE/ZeroSSL after renewing my latest certs to hmailserver, Thunderbird refuses to fetch the new certificate, prompting this error, "unable to obtain identification status for this site" and because of this I cannot add an exception, anyone else getting these issues?

Comment 5

[Mads Kiilerich]

It is my experience that bug 1590474 wasn't fully resolved. No doubt the resolution there is fine, but there seems to be more to it for Thunderbird. This bug seems to created to track something like that. I will add my observations, summarizing and testing what I picked up.

First: On Fedora 33 with thunderbird-78.6.0 , when connecting to a server with an unknown self-signed certificate, Thunderbird will hang after "Connected to server". I would expect the "Confirm Security Exception" dialog to pop up, both for SSL/TLS and STARTTLS.

I see this with dovecot-2.3.11.3 , where the server logs "ssl3_read_bytes:sslv3 alert bad certificate:ssl/record/rec_layer_s3.c:1543:SSL alert number 42" - not very helpful.

This behaviour can be reproduced without dovecot, just using openssl-1.1.1i :

openssl req -new -x509 -nodes -out cert.pem -keyout key.pem -days 365 -config <(cat << EOF
[ req ]
default_bits = 4096
encrypt_key = yes
distinguished_name = req_dn
x509_extensions = cert_type
prompt = no
[ req_dn ]
CN=imap.example.com
[ cert_type ]
nsCertType = server
EOF
)

openssl x509 -in cert.pem -noout -subject -fingerprint -text

openssl s_server -cert cert.pem -key key.pem -accept 993

(For testing, ensure a clean starting point with Preferences > Privacy & Security > Manage Certificates > Servers > Delete . The manually whitelisted self-signed certicates will in ~/.thunderbird/*/cert_override.txt ... but while looking here is useful for diagnosing problems, the file should not be edited.)

The problem discussed here is solved when it gets as far as reporting a "CIPHER" instead of "sslv3 alert bad certificate" and "SSL alert number 42".

The "Confirm Security Exception" dialog can be triggered in a couple of other ways ... but it doesn't really work in Thunderbird out of the box. It will just report "No Information Available" "Unable to obtain identification status for this site". The hidden root cause is self-imposed and can be worked around - https://www-archive.mozilla.org/projects/netlib/portbanning :
Preferences > General > Config Editor > Right click > New > String > network.security.ports.banned.override > 143,993
That could perhaps be the default in Thunderbird ... but to avoid security regressions, the banning should probably just also be disabled for the IMAP Certificate dialogs (as it seems to be for SMTP).
Bug 966689 was closed, since the foundation in "MailNews Core" makes it possible to solve the problem, but the problem has not actually been fixed in Thunderbird. That needs tracking somewhere.

With the ports unbanned, it is possible to whitelist self-signed SSL/TLS certificates:
Preferences > Privacy & Security > Manage Certificates > Servers > Add Exception > Location: localhost:993 > Get Certificate > Confirm Security Exception
Note: that only works for SSL/TLS sockets - not for STARTTLS. It would be nice with some better UI in that dialog, hinting how it can and can't be used (how to specify the SSL/TLS host:port, and even more what to do with STARTTLS).

Whitelisting of STARTTLS certificates is more tricky but can be triggered with the mail account wizard:
Account Settings > Account Actions > Add Mail Account > Configure manually > Server: localhost (OUTGOING: existing default )> SSL: STARTTLS > Re-test > Done > Confirm Security Exception > (the exception has been added and the wizard can be cancelled)
The wizard is however very magic, with fields triggering changes to each other, fields we don't care about because we only want the side effect, and apparently 3 levels of checking: socket, TLS, and authentication.
The certificate found from testing will be loaded in the "certificate error" dialog, and, confusingly, "Get Certificate" will spoil it.
This workaround is thus not a good workaround.

Some of these observations / workarounds might be relevant for https://support.mozilla.org/en-US/kb/cannot-receive-messages .

Comment 6

[Wayne Mery (:wsmwk)]

If there are any potential fixes that require strings, if it is wanted for version 91 then it will need to land this week.