Feature #15923

Autocrypt forces unencrypted messages

Added by sajolida 2018-09-07 12:14:34 . Updated 2019-02-21 17:59:43 .

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Target version:
Tails_3.13
Start date:
2018-12-03
Due date:
% Done:

100%

Feature Branch:
Type of work:
Research
Blueprint:

Starter:
Affected tool:
Email Client
Deliverable for:

Description

I found today that autocrypt overwrote my Enigmail preferences to force sending unencrypted emails to other Tails contributors, which use Tails (as far as I know).

See attachment.

I asked goupille to do more tests and report back on what my own autocrypt advertises.

This already lead me to send sensitive information unencrypted so I think it will bite many people and it’s a regression. So I’m marking as “Elevated” and for the next release.

Thank you autocrypt for sending unencrypted emails automatically :)

Files

never.png (21695 B) sajolida, 2018-09-07 12:12:00
preferences.png (91651 B) sajolida, 2018-09-07 12:17:02
per-user-edit-rules.png (139138 B) hefee, 2018-11-29 15:37:03

Subtasks

Bug #16186: Disable Autocrypt by default Resolved

100
Feature #16222: set Autocrypt settings via /etc/thunderbird/prefs/thunderbird.js Resolved

100
Feature #16299: Disable Autocrypt even for existing persistent Thunderbird profiles Rejected

100

Related issues

Related to Tails - Feature #15657: Check which version of Enigmail we should ship Resolved 2018-06-15
Related to Tails - Feature #16477: Re-enable Autocrypt Confirmed 2019-02-21
Blocks Tails - Feature #15507: Core work 2019Q1: Foundations Team Resolved 2018-04-08

History

#1 Updated by sajolida 2018-09-07 12:16:31

Something weird is that in my autocrypt preferences, I have unchecked the following preference: Prefer encrypted emails from the people you exchange email with. Why would this be off by default?

#2 Updated by sajolida 2018-09-07 12:17:03

#3 Updated by goupille 2018-09-07 14:51:58

sajolida wrote:
> Something weird is that in my autocrypt preferences, I have unchecked the following preference: Prefer encrypted emails from the people you exchange email with. Why would this be off by default?

This option is not checked for me neither and I’m pretty sure I didn’t do it myself

#4 Updated by sajolida 2018-09-07 17:33:17

So apparently, I have such a rule for goupille but goupille doesn’t have such a rule for me. While we’re both using vanilla Tails… That’s weird…

#5 Updated by sajolida 2018-09-07 17:35:15

Ah, and goupille is just the first such email in the list but I have a whole bunch of others, like Alan and other folks.
I also have per-recipient rules that are marked as “always”. But not everybody :)

#6 Updated by intrigeri 2018-09-11 09:41:50

  • Status changed from New to Confirmed
  • Assignee set to sajolida
  • QA Check set to Info Needed

sajolida wrote:
> Ah, and goupille is just the first such email in the list but I have a whole bunch of others, like Alan and other folks.

Just guessing at this point: it might not be coincidental that goupille and Alan’s key recently expired and was updated late (either very close before the expiration date or after it). Perhaps at some point you’ve received email from them, with their autocrypt attaching their expired key, your autocrypt importing it and deciding it was not usable. It might be useful to check if the “whole bunch of others” are similar cases.

#7 Updated by sajolida 2018-09-11 16:43:43

  • Assignee deleted (sajolida)
  • QA Check deleted (Info Needed)

The “bunch of others” are actually two. I don’t think they have been updated recently because their expiry dates are in early June 2019 and late May 2023, so assuming that when people postpone their keys they postpone it by at least one year that doesn’t match the release of even 3.8 (ie. worse case they were already updated for 3.8).

#8 Updated by intrigeri 2018-09-18 15:38:28

  • Assignee set to intrigeri

goupille wrote:
> sajolida wrote:
> > Something weird is that in my autocrypt preferences, I have unchecked the following preference: Prefer encrypted emails from the people you exchange email with. Why would this be off by default?
>
> This option is not checked for me neither and I’m pretty sure I didn’t do it myself

This maps to the mail.server.default.acPreferEncrypt pref, whose default value is 0 which means “nopreference”; the code has a comment that says “Autocrypt default according spec”.

When this pref is set to 0, a Autocrypt-Prefer-Encrypt: nopreference is added to the “Autocrypt Setup Message” (not sure what this is yet); otherwise a Autocrypt-Prefer-Encrypt: mutual header is added. I think that’s used for some kind of negotiation between MUAs, and once the negotiation is done successfully, per-recipient rules are updated (updateRuleForEmail).

Now, I see there’s a setAutocryptForOldAccounts function that’s supposed to set the Autocrypt prefer-encrypt option to “mutual” for all existing accounts. It’s run by upgradeTo201 which is run if vc.compare(oldVer, "2.0.1a2pre") < 0. So upgrading to Tails 3.8 should have triggered this… if the code works as planned and the upgrade path was indeed followed successfully to the end.

If the migration to 2.0.1+ failed for some reason, and thus acPreferEncrypt is set to 0 for your email account, then I guess the Autocrypt negotiation will lead to per-email rules being added that disable encryption.

Recovering from such failed migration paths is not very easy. It seems doable to force setAutocryptForOldAccounts to run on every Thunderbird startup for a while, so at least Autocrypt negotiation stops generating rules that disable encryption by default. But I guess that won’t do anything about the problematic per-recipient rules, which I’m quite reluctant to touch programmatically, so sadly, perhaps that second part will be better solved through documentation. (Now, some users might have successfully migrated and then opted-out from Autocrypt, which we would revert if we do that.)

FWIW I see Openpgp: preference=signencrypt in the email sent by sajolida recently.

> I also have per-recipient rules that are marked as “always”. But not everybody :)

Just curious: is this an Autocrypt-generated rule i.e. one that says {autocrypt://… in the “Email” column? Don’t spend too much time on this, I doubt I’ll be able to do much with the answer anyway.

Also, I could perhaps debug this more easily if someone affected shared privately with me their ~/.thunderbird/profile.default/enigmail.sqlite. You might want to take a look at it e.g. with sqlitebrowser first though :)

#9 Updated by intrigeri 2018-10-10 14:56:24

#10 Updated by sajolida 2018-10-10 22:22:43

I talked briefly to dkg about that and he told me it had most likely to do with a weird interaction between the migration of preferences of Enigmail to newer versions. And not with Autocrypt itself, Autocrypt being only a set of recommendations for MUA. Still, it’s in the design of Autocrypt in it’s most basic to not encrypt automatically (but let the use opt-in every time).

I understand that’s why the option “Prefer encrypted email from the people you exchange email with” is unchecked by default and maybe that’s the source of the problem. If so, we might consider using a different default for that one in Tails.

An option to investigate this further might be to ask Tails contributors, using Tails or not, to check their Per-Recipient Rules and see if they have any such lines. I haven’t go any new ones since I deleted the 2 I found initially.

#11 Updated by intrigeri 2018-10-20 11:06:06

  • Target version changed from Tails_3.10.1 to Tails_3.11

#12 Updated by hefee 2018-11-06 15:30:49

  • Assignee changed from intrigeri to hefee

#13 Updated by intrigeri 2018-11-07 15:36:41

  • related to Feature #15657: Check which version of Enigmail we should ship added

#14 Updated by intrigeri 2018-11-07 15:43:31

Dear hefee, as discussed yesterday nothing (except the lack of data, since nobody shared with me their enigmail.sqlite) prevents us from investigating this further now, but wrt. implementing workarounds & patching stuff, see Feature #15657#note-10: let’s make sure we don’t duplicate work that’s already been done in newer versions of the relevant packages, and that we don’t spend time on a solution that would become too quickly obsolete :)

#15 Updated by sajolida 2018-11-08 09:15:31

I suggest writing an email to all regular Tails contributors who work
from Tails and ask them to check their Enigmail per-recipient rules for
lines including ‘autocrypt’ and ‘never’.

If hefee is going to do that, I can help him come up with a first list.

#16 Updated by hefee 2018-11-29 16:01:11

Okay I can reproduce this issue. I nailed down the issue: Autocrypt adds own per-recipient rule with (never,never) on top of the rule list and that overwrites the other per-recipient rules. If the rule order is changed (autoencrypt rule moved to the bottom), the other rules are preferred and an encrypted mail is sent by default according to the other rules. If there is no other rule available, the autoencrypt rule is preferred over the general setting “Encrypt messages by default” from “Account Settings”.

  • I would recommend that Autocrypt adds his new rules on the bottom, to not overwrite existing rules.
  • Autoencrypt should not use “never” but better either “yes, if selected in Message Compositor” or even better add an other option, something like “not preferred by recipient”. That should make sure, that the general setting “encrypt messages by default” is not been overwritten by Autocrypt.
  • Enable “Prefer encrypted emails from the people you exchange email with.” by default for Tails. This inform recipients, that you prefer to get encrypted replies. Technically this adds “prefer-encrypt=mutual” to the Autocrypt header.

> This maps to the mail.server.default.acPreferEncrypt pref, whose default value is 0 which means “nopreference”; the code has a comment that says “Autocrypt default according spec”.

not sending this header part means, that you don’t have a preference about, if you want to get encrypted replies or not. That’s why we want this preference to be enabled by default, to indicate, that we prefer encrypted replies.

> When this pref is set to 0, a Autocrypt-Prefer-Encrypt: nopreference is added to the “Autocrypt Setup Message” (not sure what this is yet); otherwise a Autocrypt-Prefer-Encrypt: mutual header is added. I think that’s used for some kind of negotiation between MUAs, and once the negotiation is done successfully, per-recipient rules are updated (updateRuleForEmail).

“Autocrypt Setup Message” is a way to exchange the private key material between your devices. And you also want to exchange, if you prefer receiving encrypted messages, or not. IMO don’t bother about “Autocrypt Setup Message” for this issue, as it has nothing to do with this.

#17 Updated by hefee 2018-11-29 16:01:26

  • Estimated time set to 1 h

#18 Updated by hefee 2018-12-02 10:57:16

  • Estimated time changed from 1 h to 4 h

#19 Updated by intrigeri 2018-12-02 21:51:04

  • Status changed from Confirmed to In Progress

#20 Updated by hefee 2018-12-03 12:47:45

Subject: Tails and Autocrypt
Date: Monday, 3. December 2018, 13:44:00 CET
To: enigmail-users@enigmail.net
CC: dkg@debian.org, Patrick Brunschwig <patrick@enigmail.net>

We are currently facing the issue, that Autocrypt broke existing workflows
The scenario (Tails 3.10.1, thunderbird 60.2.1, enigmail 2.0.7):
A Tails user (Alice) was communication for a long time using OpenGPG and
prefers encrypting messages by default (via “Account Settings”) with Bob
another Tails user. So Alices is used, that the communication is encrypted
with Bob.

But this is broken by Autocrypt:
Bob sends a message to Alice and sends the Autocrypt header without prefer-
encrypt=mutual, as it is disabled by default. Alice answers to that mail and
sends an unencrypted mail, because they didn’t recognized, that the
encryption/signature state were modified by Autocrypt. The wish of Alice to
always encrypt is not taking into account anymore. Even worse, also if Alice
had created a per recipient rule for Bob to explicitly use encryption. This
rule is not followed, as the Autocrypt rule is higher rated [1].

I see the issues so far:

Autocrypt adds own per-recipient rule with (never,never) on top of the rule
list and that overwrites the other per-recipient rules. As the other rules
were done by hand from the user - The user would never expects, that a update
will overwrite his rules silently. If the rule order is changed (autoencrypt
rule would be added to the bottom), the other rules are preferred and an
encrypted mail is sent by default according to the other rules.
I see another conflict of interests, if there is no explicit rule available,
the Autocrypt rule is preferred over the general setting “Encrypt messages by
default” from “Account Settings”.

  • I would recommend that Autocrypt adds his new rules on the bottom, to not
    overwrite existing rules.
  • Autocrypt should not use “never” but better either “yes, if selected in
    Message Compositor” or even better add an other option, something like
    “recipient do not tell to use encryption explicitly”. That should make sure,
    that the general setting “encrypt messages by default” is not been overwritten
    by Autocrypt. This is mostly an issue about interpreting the missing “prefer-
    encrypt” parameter. Does it mean “never encrypt” or “if Alice wishes, it can
    be encrypted” and Alice told encrypt messages by default.
  • Mostly Tails specific: I’d recommend, that Tails enable “Prefer encrypted
    emails from the people you exchange email with.” by default. As our audience
    group expects us that we enable this. This inform recipients, that you prefer
    to get encrypted replies. Technically this adds “prefer-encrypt=mutual” to the
    Autocrypt header.

The issue is tracked at Tails bugtracker:
https://redmine.tails.boum.org/code/issues/15923

hefee

[1] /code/attachments/download/2189/per-user-edit-rules.png

#21 Updated by intrigeri 2018-12-03 15:34:52

  • Assignee changed from hefee to anonym

#22 Updated by hefee 2018-12-03 16:09:15

  • Assignee changed from anonym to hefee

#23 Updated by hefee 2018-12-03 16:19:50

  • Target version changed from Tails_3.11 to Tails_3.12

As this needs to be coordinate with upstream - we need more than “just a few days” to fix it. The Workaround is done in a subtask: Bug #16186

#24 Updated by anonym 2018-12-05 12:04:18

hefee wrote:
> * Autoencrypt should not use “never” but better either “yes, if selected in Message Compositor” or even better add an other option, something like “not preferred by recipient”. That should make sure, that the general setting “encrypt messages by default” is not been overwritten by Autocrypt.

Just an anecdote: on my Sid system I have had one autocrypt entry added, and it did not default to never; it defaulted to possible (which means “yes, if selected in Message Compositor”) which is what you suggest. I am almost 100% sure the entry was added on 17-10-2018 which means I was using thunderbird 1:60.0-3 and enigmail 2:2.0.8-1. So maybe this is fixed now?

#25 Updated by hefee 2018-12-07 19:00:24

anonym wrote:
> hefee wrote:
> > * Autoencrypt should not use “never” but better either “yes, if selected in Message Compositor” or even better add an other option, something like “not preferred by recipient”. That should make sure, that the general setting “encrypt messages by default” is not been overwritten by Autocrypt.
>
> Just an anecdote: on my Sid system I have had one autocrypt entry added, and it did not default to never; it defaulted to possible (which means “yes, if selected in Message Compositor”) which is what you suggest. I am almost 100% sure the entry was added on 17-10-2018 which means I was using thunderbird 1:60.0-3 and enigmail 2:2.0.8-1. So maybe this is fixed now?

Nope this has nothing to do with enigmail 2:2.0.8-1. The relevant part is “prefer-encrypt=mutual” in the mail. If that is set than the added autocrypt entry is like you described.
When mail.server.default.acPreferEncrypt is 0 than NO “prefer-encrypt=mutual” is sent and your enigmail will defaults to “never”.

Please recheck the mail source if you find “prefer-encrypt=mutual”. If not than 2.0.8 really fixes that issue.

#26 Updated by hefee 2018-12-07 19:04:14

Upstream(enigmail) has answerd:

  • the “autocrypt://” rules should not disturb the other rules.
    “You’re right, it’s broken. It looks I ”improved" it the wrong way sometime in one of the last updates"

the other points got no response so far.

#27 Updated by hefee 2018-12-13 16:55:23

Patrick has already fixed the issue with “autocrypt://” rules
(should be fixed in 2.0.9)

#28 Updated by hefee 2019-01-04 10:03:54

  • blocked by deleted (Feature #15506: Core work 2018Q4: Foundations Team)

#29 Updated by hefee 2019-01-04 10:04:45

#30 Updated by anonym 2019-01-30 11:59:33

  • Target version changed from Tails_3.12 to Tails_3.13

#31 Updated by hefee 2019-02-08 15:44:00

  • Assignee changed from hefee to intrigeri

As there are no new issues for Autocrypt to send unencrypted messages, I’ll recommend to close this bug as solved. As I don’t see, that more work is needed. The open parts “Document Autocrypt”/ “Disable Autocrypt even for existing persistent Thunderbird profiles” is tracked in subtickets.

#32 Updated by intrigeri 2019-02-09 15:53:07

  • Status changed from In Progress to Resolved
  • Assignee deleted (intrigeri)

Agreed, even though I thought this ticket was meant to track fixing this upstream so we can re-enable Autocrypt. Perhaps it would be worth to have a “Re-enable Autocrypt” ticket?

I’ve unparented Feature #16223: while it’s related, it’s not a blocker to close this one.

Also, note that we can’t close a parent task as long as it has open subtasks.

#33 Updated by hefee 2019-02-21 17:59:18

#34 Updated by hefee 2019-02-21 17:59:43

intrigeri wrote:
> Agreed, even though I thought this ticket was meant to track fixing this upstream so we can re-enable Autocrypt. Perhaps it would be worth to have a “Re-enable Autocrypt” ticket?

Done Feature #16477