1879023 - No support of self-signed S/MIME certificates

Status: RESOLVED WONTFIX

(MailNews Core :: Security: S/MIME, enhancement)

Description

[stefan.ziegenbalg]

Attachment: test.1.cer

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0

Steps to reproduce:

I attached a self-signed encryption-only test certificate for [e-mail] . Import that certificate and and try to send an encrypted message to that email.

With self-signed I mean truly self-signed with (private key) and not signed with self-generated CA. (That should work by importing the CA certificate.)

Actual results:

When attempting to send a message, Thunderbird emits a cryptic error: "Sending of the message failed.
You specified encryption for this message, but the application either failed to find the encryption certificate specified in your Mail & Newsgroup Account Settings, or the certificate has expired."

Expected results:

Signing certificates by an CA should only be necessary if they indented as digital signature. Emails signed with a self-signed certificates (in order to distribute it) should be treated as unsigned. But using that certificate for encryption should be possible (unless you are funded by institutions like Chinese government or NSA ...)

Desired behavior (feature request): These self-signed certificates could even generated (automatically) by Thunderbird for any email-address. This allows email encryption for everyone (and not just those ones who are willing to purchase a S/MIME certificate or who are able to generate a self-signed one)

Comment 1

[Magnus Melin [:mkmelin]]

Encryption without signing doesn't give you a safe communication channel, so the use case is pretty moot.
S/MIME is not designed for this. If you want self signing, use OpenPGP.

Comment 2

[stefan.ziegenbalg]

How you define "safe communication channel". Is no encryption and no signing more save than encryption without signing ?

OpenPGP won't help if it is not supported on the other end.

opennssl explicitly allows to generate encryption-only S/MIME certificates. Thus, I disagree that S/MIME is not designed for this. Not supporting it, makes internet less secure.

Comment 3

[Magnus Melin [:mkmelin]]

(In reply to stefan.ziegenbalg from comment #2)

How you define "safe communication channel". Is no encryption and no signing more safe than encryption without signing ?

For one message, I'd say not necessarily.
For a communication, certainly. You're might reveal information you wouldn't write otherwise, thinking it's "secure", when that's not the case.

Comment 4

[stefan.ziegenbalg]

(In reply to Magnus Melin [:mkmelin] from comment #3)

For a communication, certainly. You're might reveal information you wouldn't write otherwise, thinking it's "secure", when that's not the case.

Digitally signing and encryption are two different purposes and S/MIME certificates can serve these purposes independently.

Why is encrypting a message to an recipient with unverified identity less save than sending an unencrypted message? Because you might overlook the fact that the identity is unconfirmed and reveal secrets? Really?

If that is you concern, you could add a warning. But that warning should generated every time you email (encrypted or not) to someone without verified identity.

Comment 5

[Magnus Melin [:mkmelin]]

With S/MIME there are no "unverified identities".

Comment 6

[Kai Engert [:KaiE:]]

Hello Stefan,
I would like to give you a more detailed explanation, because I think in the discussion so far, a few arguments weren't fully right.

You said:

Signing certificates by an CA should only be necessary if they indented as digital signature. Emails signed with a self-signed certificates (in order to distribute it) should be treated as unsigned. But using that certificate for encryption should be possible

This isn't correct.

The purpose of obtaining a certificate from a CA isn't that you can use it as a signing certificate.
The purpose is to allow recipients of a (public) certificate to be reasonably certain that the certificate/key belongs to the person who controls the email address listed in the certificate.
The purpose is to protect against MITM attacks.

When simply using encryption, without checking whether a self-signed certificate belongs to the intended person, an attacker could easily trick you into sending an encrypted email using an incorrect key, which could allow the attacker to read the encrypted email.

That's why an S/MIME certificate should have a signature from a well-know CA. The signature on the certificate says that a well-known and audited CA has checked the ownership of key and email address listed in the certificate.

In my opinion Magnus slightly exaggerates the purpose of the signature in an encrypted email. He thinks that an encrypted emails isn't a safe channel without a signature. In my opinion, this statement from Magnus is too strong. For example, if the sender of an email knows that they are using the correct certificate for encrypting the message, then the sender can be certain to have a secure sending channel to the recipient. This is a partial level of security, which might be completely sufficient for some purposes. For example, if sender and recipient have agreed to safely deliver a document, the recipient might be able to conclude the message is indeed originating from the expected sender, based on message contents and previous agreements. It's true that the recipient doesn't get a verifiable signature to confirm their expectation, but as I said, it might be unnecessary in some contexts. For that reason, I consider Magnus' statement to be an imprecise simplification.

The point of the certificate, the fact that the certificate from a CA, is for giving the sender some certainty. Because the certificate has a signature from the CA, the sender can reasonably assume that it's likely indeed the certificate of the intended recipient.

Without this CA signature, by using a self signed certificate, you don't have that certainty. Anyone could have produced the recipient's self signed certificate.

It's true that in theory, applications could support self-signed certificates, and allow users to manually verify that a key belongs to an assumed correspondent, for example by calling that person on the phone, and comparing fingerprints.

However, this approach isn't commonly used with S/MIME. Relying on third party signatures from certificate authorities is how S/MIME works.

If you need the manual verification approach, the right technology to use is indeed OpenPGP, because that technology doesn't require the use of third party authorities, and fully supports the model of manually checking the ownership of keys, and it is also implemented by Thunderbird.

Comment 7

[Kai Engert [:KaiE:]]

At this time, we don't intend to support self-signed S/MIME certificates.

If you really want to use your own certificates, it's possible to run a CA yourself. You would create a self-signed CA certificate, and import it into Thunderbird, and you could chose to mark it as trusted for email certificates. Then you could create an email certificate for yourself, and use your own CA certificate to sign/certify it. This way Thunderbird would allow you to use your own certificate.

Should Thunderbird require that you have a valid certificate for yourself, before it allows you to send an encrypted S/MIME message, the above approach could be a workaround.

It would allow Thunderbird to encrypt the outgoing message both to your recipient, and also to yourself, for the copy of the message that will be stored in your "Sent" email folder.

Comment 8

[Kai Engert [:KaiE:]]

I agree with the resolution status of "invalid", because of the explanations I have given: We deliberately don't support self-signed end-entity email certificates, and because we have a viable workaround, which I described in comment 7.

Comment 9

[stefan.ziegenbalg]

(In reply to Magnus Melin [:mkmelin] from comment #5)

With S/MIME there are no "unverified identities".

Then, the test certificate I attached to the bug report does not exist because 'with S/MIME there are no "unverified identities"' and it was not verified by a CA.

(In reply to Kai Engert (:KaiE:) from comment #7)

If you really want to use your own certificates, it's possible to run a CA yourself. You would create a self-signed CA certificate, and import it into Thunderbird, and you could chose to mark it as trusted for email certificates. Then you could create an email certificate for yourself, and use your own CA certificate to sign/certify it. This way Thunderbird would allow you to use your own certificate.

I already mentioned this possibility in the bug report. The problem is, most people will not manually import CA certificates. In practice this is more option for a working working team or so.

In my opinion (Magnus disagrees), encrypted and self-signed messages are more secure than unencrypted and unsigned messages. That's is why I expected them to work.

The problem with PGP is, that it is not supported widely and usage is more difficult.

A practical example: The tax office only supports communication via S/MIME. The tax advisor communicates unencrypted and unsigned (and with attachments in form of winmail.dat containers!). I can be happy if the latter is sometimes able to purchase and import an S/MIME certificate. I can't expect anyone to setup PGP or install my own CA certificate. Furthermore, a certain amount of verification is usually given because communication is typically related to previous conversation. With encryption, this effect is even larger because no third party would be able to intercept and fake messages inconspicuously.

So again, IMHO the correct treatment of self-signed certificates would be treat them unsigned (i.e. identity unverified, manipulation possible) but use them for encryption. (AFAIK other email clients support self-signed certificates and I assume they are treated as described.)

However, Thunderbird is free software, and you as developers you are free to not implement it.

(P.S.: I meanwhile purchased CA-signed certificates for both, business and private communication.)