Closed Bug 1163314 Opened 9 years ago Closed 8 years ago

Mail sent unencrypted w/o warning despite S/MIME encryption chosen (using Enigmail)

Categories

(Thunderbird :: Security, defect)

31 Branch
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: dirk, Assigned: patrick)

References

()

Details

(Whiteboard: [Enigmail bug])

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:37.0) Gecko/20100101 Firefox/37.0
Build ID: 2015041600

Steps to reproduce:

Dear folks,

composed 2-3 mails, went to menu button "S/MIME" --> "Encrypt Mail", respective lock icon was clearly shown in the lower right corner of the composing window. Signing was picked also -- by default.

Thunderbird 31.6.0 (Enigmail 1.7.2 too, but wasn't configured in this mail to sign or encrypt, neither in this cases nor by default).

Recipients' keys are in my keystore.



Actual results:

Mail was send UNENCRYPTED and I didn't get ANY warning that it was supposed to be send in clear text. 

(side observation: also it was unsigned. But only those mails which were supposed to send encrypted.

Can't remember seeing this in 31.5.0 or 31.4.0.




Expected results:

If there's a technical problem I would expect a warning. However in the first place I would expect to be send encrypted if I tell so.
I judged this by the BCC I sent myself which was not encryped/signed.
Severity: normal → critical
OS: Unspecified → Linux
Hardware: Unspecified → x86_64
This may have been caused by Enigmail! Please update to current release or nightly and try to reproduce.
(In reply to Olav Seyfarth from comment #2)
> This may have been caused by Enigmail! Please update to current release or
> nightly and try to reproduce.

dirk does it also fail in 38? 
https://www.mozilla.org/en-US/thunderbird/all-beta.html
Flags: needinfo?(dirk)
Guys, you can't be seriously requesting that I do experiments to send mails again to my costumer just to check whether it was sent encrypted or not?

It was embarrassing enough to me that this happened.

Now changing hat as a free software developer. I appreciate what you guys are doing, understand well that this is a complex matter. But I would appreciate functional tests which cover those cases if you want serious people (continue) using your software. I suppose that didn't happen.

Also the least I would expect is that if a user chooses to encrypt -- whatever method -- that there's a sanity check whether it was really encrypted after internally putting the mail together and BEFORE sending.

Thx, Dirk
Flags: needinfo?(dirk)
Nothing was said about sending mail to a specific person.

Anyway, enigmail is involved here, so did you check https://www.enigmail.net/support/troubles.php and also the known defects list?


(In reply to dirk from comment #0)
> User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:37.0) Gecko/20100101
> 
> Thunderbird 31.6.0 (Enigmail 1.7.2 too, but wasn't configured in this mail
> to sign or encrypt, neither in this cases nor by default).
> 
> Recipients' keys are in my keystore.
>..
> Can't remember seeing this in 31.5.0 or 31.4.0.

you might test this theory by reinstalling those releases from http://releases.mozilla.org/pub/mozilla.org/thunderbird/releases/
Wayne, please treat me like a user here.

Unfortunately I do not have time currently to worry about lists and catches or trying whether this or that works. Take this as a sincere bug report from an educated user. 

PS: I am always using http://releases.mozilla.org for Thunderbird.

Cheers, Dirk
(In reply to dirk from comment #6)
> Wayne, please treat me like a user here.

Fair enough.  What you are reporting is not caused by Thunderbird. You will need to report this to enigmail.  https://addons.mozilla.org/en-US/thunderbird/addon/enigmail/ has the link to the support site, where you can "report a defect".

Closing this as invalid, not because you are not having a problem (you are) but because this is not likely a defect in Thunderbird.
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → INVALID
Wayne, maybe you're right that it is in Engimail -- can't tell.

But again I was using S/MIME encryption and that mail went out NOT ENCRYPTED.

So I can't understand that you <exaggerating> clap your hands and close this issue and just forward this to enigmail</exaggerating>. I am not ok with this alone.

What I would expect from Mozilla is at least a final sanity check warning if a user chooses to encrypt and is about to send out text/plain , text/html that it stops there.

Besides your consideration for the latter I hope I can expect more attention to this -- in terms of security -- highly critical issue.

Thx, Dirk
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Dirk, do you still see this if you disable Enigmail and send with S/MIME, which does not require Enigmail?

I realize that you have already said "I do not have time currently to worry about lists and catches or trying whether this or that works" but since your report is unique, there is no other way for us to gather additional information. The way that we can give "consideration ... to this -- in terms of security -- highly critical issue" is to pester you for additional information.
(In reply to dirk from comment #8)
> What I would expect from Mozilla is at least a final sanity check warning if
> a user chooses to encrypt and is about to send out text/plain , text/html
> that it stops there.

Being the author of Enigmail, I actually don't agree with your expectation. If an add-on like Enigmail messes up with a standard function in Thunderbird (that would work perfectly fine without the add-on installed), then it's up to the add-on to ensure that standard Thunderbird works correctly in all cases. I'm not saying that this is necessarily the case here -- this is just a generic statement.

There is just no way for Thunderbird to check whether its functions are working properly if some add-on manipulates them.

If you report a defect, then please expect that the developers need more information to find out what's wrong, which often includes you - the reporter.
(In reply to Patrick Brunschwig from comment #10)
> (In reply to dirk from comment #8)
> > What I would expect from Mozilla is at least a final sanity check warning if
> > a user chooses to encrypt and is about to send out text/plain , text/html
> > that it stops there.
> 
> Being the author of Enigmail, I actually don't agree with your expectation.
> If an add-on like Enigmail messes up with a standard function in Thunderbird
> (that would work perfectly fine without the add-on installed), then it's up
> to the add-on to ensure that standard Thunderbird works correctly in all
> cases. I'm not saying that this is necessarily the case here -- this is just
> a generic statement.

Technically I am fine if enigmail raises the hand and claims to be the culprit. 
From a user perspective I have to say I don't care as I (being just an example) 
as long as I works.

> There is just no way for Thunderbird to check whether its functions are
> working properly if some add-on manipulates them.

In this specific case I am still missing a satisfying answer for my question
I asked 2+ times: Why can't thunderbird just check whether the mail which
was intended to be "Content-Type: application/pkcs7-mime" is about to send
as such? Why can a plugin override this?

Sorry for being that ignorant -- I haven't looked into the code (and don't want to) --
but to me it seems that if a plugin can mess up that function completely
seems just a bad idea to me.

> If you report a defect, then please expect that the developers need more
> information to find out what's wrong, which often includes you - the
> reporter.

Ok. Fair enough. Please don't expect an immediate action. I will try again
with a mocked setup to reproduce this within 2 weeks.

Cheers, Dirk
(In reply to dirk from comment #11)
> (In reply to Patrick Brunschwig from comment #10)
> > (In reply to dirk from comment #8)
> > > What I would expect from Mozilla is at least a final sanity check warning if
> > > a user chooses to encrypt and is about to send out text/plain , text/html
> > > that it stops there.
> > 
> > Being the author of Enigmail, I actually don't agree with your expectation.
> > If an add-on like Enigmail messes up with a standard function in Thunderbird
> > (that would work perfectly fine without the add-on installed), then it's up
> > to the add-on to ensure that standard Thunderbird works correctly in all
> > cases. I'm not saying that this is necessarily the case here -- this is just
> > a generic statement.
> 
> Technically I am fine if enigmail raises the hand and claims to be the
> culprit. 
> From a user perspective I have to say I don't care as I (being just an
> example) 
> as long as I works.

we get that you don't care, and that's OK - need need to repeat.
 
> > There is just no way for Thunderbird to check whether its functions are
> > working properly if some add-on manipulates them.
> 
> In this specific case I am still missing a satisfying answer for my question
> I asked 2+ times: Why can't thunderbird just check whether the mail which
> was intended to be "Content-Type: application/pkcs7-mime" is about to send
> as such? Why can a plugin override this?
> 
> Sorry for being that ignorant -- I haven't looked into the code (and don't
> want to) --
> but to me it seems that if a plugin can mess up that function completely
> seems just a bad idea to me.

We don't yet know what all  the isues are - how can anyone at the drop of a hat respond to such a proposal?  You wouldn't expect a doctor to diagnose you without proper investigation. this is no different.


> > If you report a defect, then please expect that the developers need more
> > information to find out what's wrong, which often includes you - the
> > reporter.
> 
> Ok. Fair enough. Please don't expect an immediate action. I will try again
> with a mocked setup to reproduce this within 2 weeks.

no problem/no rush. this is open source - you get out of it what you put into it.
(In reply to dirk from comment #11)
> Sorry for being that ignorant -- I haven't looked into the code (and don't
> want to) --
> but to me it seems that if a plugin can mess up that function completely
> seems just a bad idea to me.

Add-ons can basically override whatever they want, and that is a great strength. 
That's why things like engimail are possible to implement in the first place.
(In reply to Magnus Melin from comment #13)
> (In reply to dirk from comment #11)
> > Sorry for being that ignorant -- I haven't looked into the code (and don't
> > want to) --
> > but to me it seems that if a plugin can mess up that function completely
> > seems just a bad idea to me.
> 
> Add-ons can basically override whatever they want, and that is a great
> strength. 

Depends if you're looking at it from a user or security perspective. As you might have figured out by now ;-) I am for controls of components if it comes to security.
> As you might have figured out by now ;-)

I'm actually not so sure that the reason for sending a message unencrypted is Enigmail. I never wrote this, and I don't even think it's true. And there are even a couple of cases where Enigmail removes the S/MIME encryption status _on purpose_ as part of a feature. Requesting from Thunderbird to watch such changes is simply impossible.
Not so easy to reproduce, hang on pls.

I suspect that was no "normal" circumstances -- but can't tell yet.
I have encountered this bug multiple times in the last 24 hours.
After running through a number of test cases, it appears that Enigmail
is the culprit.  Specifically, the following bug:

  #80 Email fails to encrypt after switching from GPG to S/MIME 
  http://sourceforge.net/p/enigmail/bugs/80/

With Enigmail enabled, I can reproduce it every time if Thunderbird
saves a draft (either automatically or manually) before I enable
S/MIME sign and encrypt.

If I enable S/MIME sign and encrypt before the first draft is saved,
the message will be correctly S/MIME signed and encrypted when
sending.

When I disable the Enigmail extension, saving a draft before
enabling S/MIME sign and encrypt does not result in incorrect
behavior.

With Enigmail set to sign and encrypt by default, when I compose a new
message the following scenarios cause an unsigned and unencrypted
message to be sent:

    1. Save as draft
    2. Disable Enigmail Sign and Encrypt
    3. Enable S/MIME Sign and Encrypt
    4. Send
    ---
    1. Disable Enigmail Sign and Encrypt
    2. Save as draft
    3. Enable S/MIME Sign and Encrypt
    4. Send

In tests that I've run, the following conditions do not appear to have
any affect on this behavior: varying the To and Cc recipients,
attachments, viewing S/MIME info dialog, and replying to an
unencrypted email open in the Inbox view.

Thunderbird Version: 38.2.0
Add-ons:
  - Enigmail 1.8.2
OS: Mac OS X Yosemite 10.10.5 (14F27)
Flags: needinfo?(dirk)
Flags: needinfo?(dirk)
Normally we would probably mark this bug as invalid because it is in an addon, but Enigmail is lobbying to be a shipped addon at some point, so I think we should watch this. We really need to work out with Enigmail how to manage bug reports if they elevate their status.

-41 and -42 are now obsolete, we're clearly not going to hold esr38 release on this, but let's make sure we look at this prior to -45

Anyone who wants to be helpful, please confirm that you can reproduce the issue using the STR in comment 17. Patrick, if there is a corresponding report in an Enigmail bug database, please add a link.
I can imagine that this is the same as the following bug, which was fixed in the latest release (Enigmail v1.8.2):
https://sourceforge.net/p/enigmail/bugs/480/

I have not heard of new errors of this type since that release.
In case someone is able to reproduce this, please attach an Enigmail debug log file, available from menu Enigmail > Debugging Options > View log (you might first need to enable the option "Display Expert Settings and Menus" in the Enigmail Preferences).
I don't think there's anything more to add to this bug.
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago8 years ago
Resolution: --- → INVALID
Summary: Mail sent unencrypted w/o warning despite S/MIME encryption chosen → Mail sent unencrypted w/o warning despite S/MIME encryption chosen (using Enigmail)
Whiteboard: [Enigmail bug, now fixed]
The bug still exists with Thunderbird 38.5.1 and Enigmail 1.8.2. The problem is caused by Enigmail's "encrypt draft messages on saving" option (to be found under accounts settings->OpenPGP
Security->Message Composition Default Options). If this option is checked and a new mail is saved as draft before selecting S/MIME-encryption, it will be send unencrypted without any warning.
I fixed some issues with S/MIME / OpenPGP a while ago. Can you please try this with the latest beta version of Enigmail? 

You can find it here:
https://www.enigmail.net/download/beta/enigmail-1.9-beta1.xpi
Still the same issue with Enigmail 1.9-beta1. If "encrypt draft messages on saving" is enabled and the message is saved before selecting S/MIME-encryption, it will be send unencrypted without warning.
Thanks, yes I can reproduce this. This is certainly a bug in Enigmail, not in Thunderbird.
Assignee: nobody → patrick
Status: RESOLVED → REOPENED
Ever confirmed: true
OS: Linux → All
Hardware: x86_64 → All
Resolution: INVALID → ---
Whiteboard: [Enigmail bug, now fixed] → [Enigmail bug]
Fixed on Enigmail master (see https://www.enigmail.net/download/nightly.php)
Status: REOPENED → RESOLVED
Closed: 8 years ago8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.