Handle delete/detach attachment feature with crypto-signed mails

NEW
Unassigned

Status

14 years ago
2 years ago

People

(Reporter: BenB, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

14 years ago
Split-off from bug 2920 comment 419 and bug 2920 comment 60:

If the mail client deletes attachments of a mail that happened to be
cryptographically signed by the sender, the signature gets invalid.

That's as designed, because the sig proves that the msg is not tampered with, in
the state that the sender sent it, and that intentionally includes attachments,
otherwise they wouldn't be included in the sig wrapper.

The problem here is that our mail client shows a "broken" signature, which may
be confusing to users.

Question is what to do.
- Comment 60 suggested as one solution to disable the "delete attachment"
feature completely for mails that are signed.
- Another solution would be to allow deletion of attachments, and then treat the
msg as if it never had a signature.
- Another suggestion (of mine) would be to show a special msg telling the user
that the msg used to be signed by foo, but no longer is, because the attachments
have been stripped. That poses the risk that users then treat the msg as if the
signature was still valid, which would open (social) attacks where the attacker
forges msgs which *pose* as exactly that.

Updated

14 years ago
Summary: Handle delete attachment feature with crypto-signed mails → Handle delete/detach attachment feature with crypto-signed mails

Comment 1

14 years ago
Why is the product (the discontinued) "Moz App Suite"? Shouldn't this be "Core"
or "Thunderbird"? If not, should i file a new bug on "Core" or "Thunderbird"?

(In reply to comment #0)
> If the mail client deletes attachments of a mail that happened to be
> cryptographically signed by the sender, the signature gets invalid.

Not only "invalid" but completely *blank*. 

NOTE: This also happens with signed + *encrypted* messages (reword summary?).

> - Comment 60 suggested as one solution to disable the "delete attachment"
> feature completely for mails that are signed.

That is a problem for users who sign *all* their e-mails; and for the futurewhen
hopefully more users will be using digital signatures.

> - Another solution would be to allow deletion of attachments, and then treat the
> msg as if it never had a signature.

That would be unfortunate. Perhaps add some text to the bottom of the message
(below the attachment-removal note?):

"The digital signature has been removed from this message because the attachment
was removed, thus altering the e-mail."

> - Another suggestion (of mine) would be to show a special msg telling the user
> that the msg used to be signed by foo, but no longer is, because the attachments
> have been stripped. That poses the risk that users then treat the msg as if the
> signature was still valid, which would open (social) attacks where the attacker
> forges msgs which *pose* as exactly that.

This _may_ not be a big problem because messages with detached/deleted
attachments will likely only reside on the detacher's/deleter's local machine,
not the inbox (as unread), and not sent to someone (this would be a
"reply/forward", which would strip the original sig anyhow - and validly replace
it with the new sender's sig).
(Reporter)

Comment 2

14 years ago
> Why is the product (the discontinued) "Moz App Suite"?

Because bug 2920 is there.

> not the inbox (as unread)

Sigs are also important later on to prove (e.g. in court) that the msg was
unaltered.

> "reply/forward", which would strip the original sig anyhow

Sure? I thought fwd as attachments retains the msg as-is (incl sigs).
(In reply to comment #1)
> Why is the product (the discontinued) "Moz App Suite"? Shouldn't this be "Core"
> or "Thunderbird"? If not, should i file a new bug on "Core" or "Thunderbird"?

just filed bug 288981 for tbird.
(Reporter)

Comment 4

14 years ago
*** Bug 288981 has been marked as a duplicate of this bug. ***
I'm moving this over to Core: MN attachments so that it can be nominated for
aviary1.1 (which will also help me better with my queries).
Component: Security → MailNews: Attachments
Product: Mozilla Application Suite → Core
Version: unspecified → Trunk
nominating for tbird 1.1 (if there are cycles available!).
Flags: blocking-aviary1.1?

Comment 7

14 years ago
(In reply to comment #1)
> > - Comment 60 suggested as one solution to disable the "delete attachment"
> > feature completely for mails that are signed.

The intention was to get rid of those huge Megabytes of attachments.
It does not help if there are types left that can't be reduced.

> That is a problem for users who sign *all* their e-mails; and for the futurewhen
> hopefully more users will be using digital signatures.

Ok, then it's important to have this feature for signed msg. too.
Btw, in my opinion encryption is more important than signing.
For real contracts I would prefer paper and ink.

> That would be unfortunate. Perhaps add some text to the bottom of the message
> (below the attachment-removal note?):

Yes, this would also be my favourite.

> > have been stripped. That poses the risk that users then treat the msg as if the
> > signature was still valid, which would open (social) attacks where the >
This _may_ not be a big problem because messages with detached/deleted
> attachments will likely only reside on the detacher's/deleter's local machine,

If it's an explicit wish of the user to alter the message, he should know
what he is doing. The replacement message even proves that the signature was
valid before. Of course somebody could break into the user's machine. But then
also digital certificates could be altered. I don't see the problem.

The message would not have a good reputation in court trials any more,
but that's up to the user to throw away signatures or not.
In a private environment I don't care much about signatures. 
Even for the usual business messages sigatures are irrelevant.
You should let the user decide to employ them and how to handle them.
(Reporter)

Comment 8

14 years ago
> Btw, in my opinion encryption is more important than signing.

It's not, but irrelevant discussion here.

> The replacement message even proves that the signature was valid before.

No, it does *not*. That's what I said in my initial description.

Any implementation would have to ensure that the msg can only be added by the
local application. That means: Not in body or even headers, but stored in
internal meta-data, in ways that provably cannot be seeded by incoming, fwrd
etc. msgs, and displayed in the header pane.

Note that this msg would be lost when looked at on IMAP on a different machine,
after a copy to another machine etc., and definitely when forwarded (see above).
THe msg would then appear completely unsigned (which it is).

> Of course somebody could break into the user's machine. But then
> also digital certificates could be altered.

No, they could not. The display could, yes. But a break-in is not my main concern.
(Reporter)

Comment 9

14 years ago
> this msg would be lost when looked at on IMAP on a different machine,
> after a copy to another machine etc.

unless there's a way to store that on the IMAP server. A manual copy or backup
would have to include the meta-data.
But that must not work with forwards and other transfers to third parties.

Comment 10

14 years ago
(In reply to comment #8)
> > The replacement message even proves that the signature was valid before.
> No, it does *not*. That's what I said in my initial description.

Depends on your assumtions. Of course not for a court trial any more.
You can't avoid that loss when removing the attachment.
But the message is a marker for the mailbox owner that the signature was
valid in the moment when he stripped the attachment. Of course with the
assumtion that nobody broke into the mailbox and that the incoming mail did not
already contain that message. But that's up to the recepient, quite obvious.

More is not possible when the message was altered.
The modification could be signed by the recepient, but that does not
help him very much.
With forwared messages the forwarder can sign again, that's
already implemented.

> Any implementation would have to ensure that the msg can only be added by the
> local application. That means: Not in body or even headers, but stored in
> internal meta-data, in ways that provably cannot be seeded by incoming, fwrd
> etc. msgs, and displayed in the header pane.

But that would mean new data structures and complexity for the implementation.
The security gain is not very big. The case when the incoming new mail already
contained that removal message is quite ovious for the recepient. He could
simply delete that unauthorized mail. Or Mozilla would additionally add a
comment like "warning: removal message forged" ...

> Note that this msg would be lost when looked at on IMAP on a different machine,
> after a copy to another machine etc., and definitely when forwarded (see above).
> THe msg would then appear completely unsigned (which it is).

Yes, but it would be impossible to secure such a long trust chain.
We should stay with the simple "signature removed" marker.
Everything else would be very difficult and could not improve security
very much.

> > Of course somebody could break into the user's machine. But then
> > also digital certificates could be altered.
> No, they could not. The display could, yes. But a break-in is not my main concern.

I would agree that we assume trust for the own machine and mailbox.
That is not sufficient for court trials, but if you want that we could
not implement the removal feature at all.

Securing the removal message would mean kind of local signing with local
certificates. These could be altered by somebody with access to this machine.
It would help when the messages are stored in an untrusted IMAP folder.
You will run into really complex security issues.

So, just keep it simple. 
Just strip off the signature and insert the removal message.

Comment 11

14 years ago
A dialog when stripping an attachment from a signed/encrypted message would be
needed to warn the user of hidden consequences (loss of sig/encrypto). Since the
dialog could get annoying, and especially since having locally stored message
that are signed/encrypted is less important, one of those nifty "annoy me
again?" checkboxes would be needed (UNchecked by default).

+===========================================================+
|                                                           |
|  / \  Removing the attachment(s) will also remove the     |
| / | \ signature/encryption from this message.             |
| -----                                                     |
| Do you still want to remove the attachment(s)?            |
|                                                           |
| [ ] Show this alert the next time I remove an attachment  |
|     from a signed/encrypted message.                      |
|                                                           |
|           [[ Yes ]]      [ No ]      [ Help... ]          |
+-----------------------------------------------------------+

Of course, the dialog would only appear when removing attachments from signed
and/or encrypted messages.

PS. Should bug 288273 and this bug (was Suite, now Core) be dupes?

Updated

14 years ago
Flags: blocking-aviary1.1? → blocking-aviary1.1-

Comment 12

14 years ago
(In reply to comment #11)

Summary of this Comment: 
The key long-term consideration in altering any message is maintaining the chain
of responsibility for the message's content. Users should understand that there
are consequences in altering a message. Peter's suggested warning dialog box
would work for me if it contained the option for users who remove attachments to
"sign" that action with their own digital signatures, thereby establishing
responsibility for the act of altering the message.

Detailed Comment:
I won't argue the case for the original bug (2920) here. I assume that all are
in agreement that the fix is valuable.

For me, this bug (288700) has been part of bug 2920 from the very start, because
the vast majority of the messages I receive are signed -- well, at least the
ones that I need to archive without attachments. Preserving the original
signature is not necessary as long as the person who removes the original
signature takes responsibility for having done so. The key issue is whether
there is someone who takes RESPONSIBILITY for any changes to the original
message, not whether there are any changes at all. At least, that's the
long-term consideration for my purposes. 

Here's the criterion: My mail archives must constitute an accurate record of
what happened -- a record of who did what, and when they did it -- that a
historian can use 200 years from now to accurately reconstruct the progression
of today's events. The burden of proof as to authenticity is mine.

Yes...I understand all the arguments asserting that someone might break into my
machine and somehow falsify the record, but let's assume for the moment that
I've taken measures to make that virtually impossible. Let's assume that there's
no (known) way for anyone (including me) to falsify the record without being
detected (true). Let's assume that the situation is no more complicated than this: 

• I want to remove attachments (which entails also removing the original
sender's signature)
• I want to certify that I have done so by signing that action with my own
identity-trusted signature
• My digital signature on that action is good enough to establish the chain of
responsibility for the message for archival purposes.

Clearly, the responsibility for altering the original message in any way must be
on the person who makes such alterations. If I absolutely need to have the
original message intact (say, for use in a legal case) I will simply leave it
intact -- end of story. But for any other purpose that I can imagine, it's
perfectly acceptable to alter the message as long as that action is...er,
"certified" by my digital signature. That puts me on the hook for having made
the alteration, and also for ensuring that the entire process is secure -- by
which I mean that I'm on the hook for proving that nobody else tampered with it.
I wouldn't have altered the message if I weren't prepared to accept
responsibility for it, but that's not relevant here. 

Here's the relevant question: Have we designed the application in a way that
enables users to accept responsibility for their actions, and informs them that
they need to make that decision?

I believe that everyone has put enough thought into this bug to have addressed
all the issues that we can reasonably be expected to have addressed. From an
application design standpoint, our responsibility to do social engineering is
minimal. The best we can do is enable users to take responsibility for their
actions. Whether they choose to do so is up to them.

That's why the warning dialog is such a good idea. The user should understand
that there are consequences in altering the message. Peter's suggested warning
dialog box addresses most of the requirements that the mail application should
cover, except for "signing" the action as I've described above. In other words,
Peter's dialog would work for me if it contained the option for users who remove
the attachments to "sign" that action with their own digital signatures.

Comment 13

13 years ago
There seemed some great discussion on this 12 months ago, but nothing of late. Is anything being considered on this bug?  It's infuriating when I digitally sign all my outgoing e-mails, but generally don't want to store them with attachments in my sent mail folder (where in fact it matters not in the slightest to me whether there is a valid digital signature or not).  My sent mail folder has become unnecessarily huge.

Comment 14

13 years ago
(In reply to comment #13)
The "Detach..." and "Delete" features exist in SeaMonkey, but as of version 1.0.2 they are useless for messages that are signed or encrypted (or both). Detaching (which allows saving the attachment) or deleting the attachment altogether breaks the signature and removes the entire content of the message body. 

The original idea behind the bug—which is to preserve the content of the message while deleting the bulky, unnecessary attachments—is completely ignored by the current implementation. You can either save the whole signed and/or encrypted message with the attachment, or you can "detach" everything from the message (but "detach" really means delete everything from the message...signature, attachment, and message body content -- everything is lost) except the header. 

Hence, for signed and/or encrypted messages the feature is utterly useless as a means of saving the message but deleting only the bulky attachment.

BTW, I notice that there are still only two votes for this bug -- yours and mine. (sigh)

Comment 15

12 years ago
I ran into this bug today. Can an agreement on the fix be reached? I wouldn't mind creating a patch for this if it isn't too hard (I'm a beginning developer).

Comment 16

12 years ago
Removing the signature on removal of attachment seems good to me. But, one nit-pick. I think it should be "Don't ask me again" instead of "Ask me next time". It's consistent with the rest of the interface, and with this the user has to agree to not show it again, which seems to make more sense.

Updated

12 years ago
Duplicate of this bug: 300148

Updated

11 years ago
QA Contact: seamonkey → attachments
You can't detach/delete attachments from smime mails, at least on trunk it's disabled.
(Assignee)

Updated

11 years ago
Product: Core → MailNews Core
(In reply to comment #18)
> You can't detach/delete attachments from smime mails, at least on trunk it's
> disabled.

When did that change go into effect?  
That was NOT the case when this bug was submitted.

Was there a bug number associated with that change?  If so, what bug number?
That would be bug 288273, landed 2005-06-10.
So, to resolve bug 288273, someone decided to disable the feature rather 
than fix it.  :(
(In reply to comment #19)
> (In reply to comment #18)
> > You can't detach/delete attachments from smime mails, at least on trunk it's
> > disabled.
> 
> When did that change go into effect?  
> That was NOT the case when this bug was submitted.
> 
> Was there a bug number associated with that change?  If so, what bug number?

(In reply to comment #20)
> That would be bug 288273, landed 2005-06-10.

Does this makes this bug INVALID ?
No.  The "fix" for bug 288273 was considered by its authors to be an 
interim measure.  They designed a longer term fix that would allow 
attachments to be detached again (see bug 288273 comment 6) but did not
implement it.  Bug 288273 comment 9 says an RFE will be fixed to request
that that feature be implemented.  This "bug" is that RFE.

Updated

9 years ago
Duplicate of this bug: 453490

Updated

8 years ago

Updated

7 years ago
Flags: blocking-aviary1.5-

Comment 25

7 years ago
Just stumbled over this bug while searching the internet for a solution to remove attachments from signed mails.
I'm aware of the implication that the signature would no longer be valid. Since I'm also signing all of my outgoing mails and my account is constantly growing I'd love to see a solution for this problem.
Has this bug never been addressed since its submission over 7 years ago? Or is there already another solution I didn't find?

Updated

7 years ago
Assignee: mozilla → nobody

Comment 26

6 years ago
I've created a new report for an issue which is related but apparently distinct: Bug 838674 deals with removing signed attachments from *unsigned* e-mails.  (The fix suggested in Bug 288273 Comment 6 isn't applicable, since there's no question of any signature being lost.)  If I'm wrong please feel free to mark it as a duplicate of this one.
Created attachment 8622054 [details]
UI: delete/detach for attachment of signed message not available

TB 31.7 still does not allow to delete attachments from signed messages. Attached is a screenshot that shows the delete/detach functions "greyed out" (disabled).

Comment 28

3 years ago
Totally agree with comment 25: I often send signed mails with big attachments, and I need to keep trace of the mails sent, the attachments attached, and the text of the mails, but I do NOT need the attachments themselves. While deleting/detaching attachments is impossible since 10 years, marking the attachment and hitting the delete button still works and leaves an empty message.

The proposed resolution is clear since 10 years: remove the signature/encryption when deleting an attachment, and warn the user about it, preferably with option not to warn again.

David Bienvenu, who proposed this RFE 2005, retired from this bug after 7 years without any proposed patch. Anybody there who is willing to implement this rather basic fix?

Comment 29

3 years ago
Unfortunately, it's _not_ a "rather basic fix," because the MIME handling code in Thunderbird is a mess which makes even seemingly small changes difficult.

I believe someone is in the process of rewriting all the MIME handling stuff in JavaScript which will eventually replace the old, messy, C++ MIME code. Once that happens this fix will probably be easier to implement. _Probably_.
Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.

Comment 31

2 years ago
Given the increasing number of security issues and fraud with emails, it becomes very important to sign emails. My organisation recently moved to signed emails but we really need a feature to delete/detach attachments from emails. Is there a way to get this feature implemented soon? e.g. as an add-on? I'm happy to test that and give feedback. 

Apparently, several people in the community would love to have this feature. See also: https://support.mozilla.org/en-US/questions/1128673

Thank you in advance for your help.

Comment 32

2 years ago
It cannot be that difficult to finally solve this problem.

What I've been doing as a workaround for years is the following:
* use any tool/editor capable of manipulating the email (header), e.g., the HeaderToolsLite extension.
* Change in the "Content-Type" entry the "multipart/signed" to "multipart/mixed" and remove (or even better, rename) the "protocol" parameter, e.g.:
replace
  Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
	micalg=SHA1; boundary="----=_NextPart_000_0000_01D1D126.351C61F0"
by
  Content-Type: multipart/mixed; protocol="application/x-pkcs7-disabled-signature";
	micalg=SHA1; boundary="----=_NextPart_000_0000_01D1D126.351C61F0"
* As a result, the email is not considered signed anymore, while the signature is now treated as a regular attachment.
* Detach/detect any attachments as you want.

Note that this way there is still an indication that the email was signed originally, yet without a disturbing "broken signature" symbol being shown.

In case you later restore the signature MIME header after manipulating the attachments (or the remaining body), the signature will of course show broken.

If you did not change anything in the body including the attachments (or restore it), you can easily restore the valid signature by reverting the small header changes mentioned above.

BTW, TB apparently blocks deleting/detaching attachments as long as it finds "application/x-pkcs7-signature" as a substring(!) of the Content-Type entry, which is bad hack. It should rather check that there is a parameter with (full) name "protocol" and (full) value "application/x-pkcs7-disabled-signature"

Hope this helps as a hint how to design and implement a solution smoothly.

Comment 33

2 years ago
Oops, correcting a copy&paste error in my but-last paragraph above:

BTW, TB apparently blocks deleting/detaching attachments as long as it finds "application/x-pkcs7-signature" as a substring(!) of the Content-Type entry, which is bad hack. It should rather check that there is a parameter with (full) name "protocol" and (full) value "application/x-pkcs7-signature"

Comment 34

2 years ago
David, thanks for the workaround. It seems that this and other tickets a more about dealing with errors about broken signature and not about the thing that a user should be able to deal with attachments no matter if it will show an error or not.

+1 annoyed Thunderbird user

Comment 35

2 years ago
@wroot, if you more carefully read my post of 2016-06-28 01:49:32 PDT you will see that my workaround does not only prevent an error message, but also does enable removing attachments.

I also indicated a sloppiness in TB's way of detecting that a message is signed (when determining whether it allows to remove attachments).

The whole issue could have been solved pretty easily already some ten years ago, but like with most other reported bugs/problems, nobody actually takes it up.

Comment 36

2 years ago
David, yes i understood that correctly and was able to remove attachments;) My second statement wasn't directed at you, but at the situation in general.
You need to log in before you can comment on or make changes to this bug.