86.47 KB, image/png
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.
Summary: Handle delete attachment feature with crypto-signed mails → Handle delete/detach attachment feature with crypto-signed mails
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).
> 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.
*** 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!).
(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.
> 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.
> 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.
(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.
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?
(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.
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.
(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)
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).
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.
You can't detach/delete attachments from smime mails, at least on trunk it's disabled.
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.
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?
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).
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?
Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.
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.
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.
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"
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
@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.
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.