230576 - Cannot encrypt message without own certificate

Status: NEW

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

Description

[Christian Eyrich]

Also having a signed mail and thus the public key of the mails recipient, one is
not able to encrypt the mail without self having a certificate. That limits the
use of this security mechanism.

Mozilla obviously has this restriction because a message not also encrypted
using the senders certificate won't be readable after encryption by himself.

While this isn't that nice, we should leave the decission to the user if he want
to nevertheless send the message or not.

Comment 1

[Christian Eyrich]

Attachment: proposed patch

This patch removes the limiting tests for mSelfEncryptionCert and replaces the
error message in the js to an informational message where the process can be
stopped or not.
It also adds "Not For Sender" as a status between "Not possible" and "Yes" in
the Message Security window. This is true when the recipients certificate is
available but none for the sender.

Maybe the test for the senders cert should be moved from the js to
MimeCryptoHackCerts(). That's because at the moment the test (and if true the
alert) is only done once (when clicking "Encrypt this Message"), so changing
the From after this stage isn't detected.
I don't know what's better, and the old check was there too.

Comment 2

[David :Bienvenu]

Comment on attachment 138758 [details] [diff] [review]
proposed patch

changing requestee to Kaie.

Comment 3

[David :Bienvenu]

Kaie will know if this is the right thing to do or not.

Comment 4

[Kai Engert (:KaiE:)]

I am fine to relax the check. I have planned this change in the context of some
larger change of the encryption behaviour, but I never got to finish it.

However, I'm not sure we need all the additional user feedback.

First, I think "Not For Sender" is unclear.
I think "Yes, but not for sender" is better.
But I see situations where this statement is incorrect, and I suggest we do not
make statements, when we can't be 100% sure.

For example, the user might have a personal certificate for another email
address imported, and might have configured to automatically cc: each message
sent to the other identity. In this situation, the user will be able to read the
message, although we say he won't. And a user, who must make sure that archived
messages will not be readble by self, can run into trouble, if what we send
actually is readable by self.

I think, a message "sender will not be able to read" only were a good idea, if
we made a check that for none of the recipient certificates a private key is
present.

But I'm not suggesting to make this check. 
I would rather suggest we leave out the additional messages to the user.

However, I'm fine with the simple change to allow sending an encrypted message,
without having a personal certificate configured, which is the most important
thing you are trying to achieve.

If you attach a new patch that simply removes the check in
msgCompSMIMEOverlay.js and has your code from nsMsgComposeSecure.cpp, I'll r= it.

Comment 5

[Christian Eyrich]

I see your subject to display a not 100% true message.
But leaving out the message at all is dangerous too. This will in fact cause
dataloss for some people (not having the sent message and having a not readable
message is the same).

What about modifying the text:
"Yes, but not for sending e-mail address"
and
"NoSenderEncryptionCert=You specified encryption for this message, but the
application failed to find a valid encryption certificate for the senders e-mail
address.\n
In this case the sender will be unable to read the message once it has been
encrypted. Continue nevertheless?"

I know I should be happy to relax the check. But without a propper warning I
guess it won't take long users complaining about data loss and we have to think
about a warning again.

Comment 6

[Christian Eyrich]

Kai, would you please have a look at this again? I want to make this ready for
early 1.8a.

Comment 7

[Christian Eyrich]

Attachment: patch v2

Address objection from comment #4 by modifying the messages.

As I already wrote, not warning the user that he probably won't be able to read
the message after sending it, is very dangerous.
So I now refer more precisely to "the sending e-mail address" instead of "the
sender" and also modified the alert text (it's quite complicated, but so are
the facts).

Comment 8

[Christian :Biesinger (don't email me, ping me on IRC)]

*** Bug 173080 has been marked as a duplicate of this bug. ***

Comment 9

[zug_treno]

*** Bug 320121 has been marked as a duplicate of this bug. ***

Comment 10

[Ben]

Please correct me if I am wrong, but I believe the following is happening (at least in Thunderbird 1.5):

When a user sends an encrypted message, then:

* the message that is transmitted is encrypted by the recipient's public key, i.e. the recipient's certificate. This allows the recipient to decrypt the received message.

* the message that is stored in the Sent Items box is encrypted with the user's own public key, i.e. the certificate of the sender. This allows the sender to decrypt the message that he/she sent. Mozilla needs a certificate from the user itself to encrypt this copy of the message.

Now, what I understand from the submitter's request is to be able to send an encrypted message without having a certificate from the sender. This is perfectly feasible as long as the sender's copy is not encrypted. The only change that is needed is a warning that the local copy will not be encrypted.

So, simply adding a warning such as

"You do not have a certificate yourself and therefore the local copy of the message that you are about to send cannot be encrypted for your personal use. However, the message will travel to the recipient(s) in an encrypted form.

Do you want to continue and store an unencrypted copy locally in your Sent box?"


Any comments? The wording might be better.

Comment 11

[Frank J. Andersen]

(In reply to comment #10)
> Please correct me if I am wrong,.......
> snip ....
> 
> So, simply adding a warning such as
> 
> "You do not have a certificate yourself and therefore the local copy of the
> message that you are about to send cannot be encrypted for your personal use.
> However, the message will travel to the recipient(s) in an encrypted form.
> 
> Do you want to continue and store an unencrypted copy locally in your Sent
> box?"
> 
> 
> Any comments? The wording might be better.
> 

Absolutely right! That would do it..

Comment 12

[TT]

I don't like the idea of that dialog box popping up every time an encrypted message is sent.  There should be a way, preferably on the dialog box itself, to turn that off.

Wouldn't it be a lot easier if 

A) the message were stored unencrypted, or
B) Mozilla were to generate a key on its own, just for internal purposes

I prefer (A) over (B) because I think it's simpler.

If this both this bug (with either of the above two methods) and bug 135636 were fixed, then we could almost turn on encryption by default.  Almost :-)

I really think SeaMonkey and Thunderbird need to make it much easier to use encrypted email.  Both of these bugs are critical, IMHO, in that goal.

Comment 13

[Ben]

(In reply to comment #12)
> I don't like the idea of that dialog box popping up every time an encrypted
> message is sent.  There should be a way, preferably on the dialog box itself,
> to turn that off.

Simply adding a: "Do not ask me again" or "Remember this answer" or similar would do, don't you think?

Comment 16

[Magnus Melin [:mkmelin]]

Christian: would be good to get this in for tb3. The patch has bitrotted though...

Comment 17

[Nelson Bolyard (seldom reads bugmail)]

In reply to comment 10, 
Ben, message encryption doesn't work the way you described in comment 10.  
An encrypted message is only encrypted once, and only sent once, to all 
recipients simultaneously.  It is encrypted using a random key, not the 
keys of any of the recipients.  Then, that random key (the Bulk Encryption
Key or BEK) is encrypted once with each and every recipient's public key.  
Presently, the sender is treated as a recipient for purposes of encrypting 
the BEK.  Then the encrypted message, and all these separately encrypted 
copies of the BEK are put into the single message. That one message is sent 
to all the recipients, and is put into the user's Sent folder.  

Here are some comments about "Patch v2".

1. I think the following text is misleading.

+NoSenderEncryptionCert=You specified encryption for this message, but the 
 application failed to find a valid encryption certificate for the senders 
 e-mail address. In this case you'll be unable to read the message once it 
 has been encrypted unless you're also one of the recipients. Continue 
 nevertheless?

The "unless you're also one of the recipients" is the wrong part. Perhaps
I am misunderstanding the patch, but the patch does not appear to me to be 
causing an unencrypted copy of the sent message to be sent to anyone nor to 
be stored in the Sent folder.  Consequently, if the sender does not have an
encryption cert, then it won't matter whether he makes himself one of the recipients or not.  He still won't be able to decrypt it.  

Also, Please ask "Continue anyway?" rather than "Continue nonetheless?".

2.  The following comment leaves the reader with unanswered questions,

+ <strong>Note</strong>: Unless you also encrypt with an own certificate, 
you will be unable to read the message once it has been encrypted.</li>

which are:
a) What is "an own certificate"?  (Say "your own certificate")
b) How do I encrypt with my own certificate?  

I think this should say: 

+Unless Thunderbird has an encryption certificate for your own email address, 
you will be unable to read any copies of the message once it has been sent.

Comment 18

[Christian Eyrich]

My involvement in this is quite some time ago, so I don't remember everything.

> The "unless you're also one of the recipients" is the wrong part.

I guess I wanted to cover the possibility that the sender sends the message to one of his own addresses too, which mustn't be the from address. Though I don't know (anymore) if it's possible to send an encrypted mail if not all of the recipient addresses have a certificate.

But maybe the alert shouldn't take every situation into account in favour of readability.

Comment 19

[Nelson Bolyard (seldom reads bugmail)]

When a message is sent encrypted, ALL of the recipients must be able to 
receive an encrypted message; that is, we must have an email encryption 
cert for all of the recipients.  It's a huge security hole to send the 
message encrypted to some remote recipients and unencrypted to others.
It basically defeats the whole purpose of encrypting the message.

Comment 20

[Kai Engert (:KaiE:)]

Comment on attachment 146178 [details] [diff] [review]
patch v2

Sorry, I failed to look at this in time after you attached this v2.
Now the patch no longer applies :(

Comment 21

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Comment on attachment 146178 [details] [diff] [review]
patch v2

This patch is unfortunately way too bitrotted. Christian, any chance of a new patch?

Comment 22

[Felix Kraus]

I have the same problem. I've got a signed message, but i can't reply encrypted without having a certificate.

Comment 23

[Ludovic Hirlimann [:Usul]]

Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.