Project

General

Profile

Feature #15923

Autocrypt forces unencrypted messages

Added by sajolida 3 months ago. Updated 1 day ago.

Status:
In Progress
Priority:
Elevated
Assignee:
Category:
-
Target version:
Start date:
12/03/2018
Due date:
% Done:

33%

Estimated time:
4.00 h
Spent time:
2.50 h (Total: 2.83 h)
QA Check:
Feature Branch:
Type of work:
Research
Blueprint:
Starter:
Affected tool:
Email Client

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 :)

never.png View (21.2 KB) sajolida, 09/07/2018 12:12 PM

preferences.png View (89.5 KB) sajolida, 09/07/2018 12:17 PM

per-user-edit-rules.png View - minimalized per-recipient-edit-rules (136 KB) hefee, 11/29/2018 03:37 PM


Subtasks

Bug #16186: Disable Autocrypt by defaultFix committed

Feature #16222: change Autocrypt default settingsNew

Feature #16223: Add Autocrypt to wiki/release notesNew


Related issues

Related to Tails - Feature #15657: Check which version of Enigmail we should ship Confirmed 06/15/2018
Blocks Tails - Feature #15506: Core work 2018Q4: Foundations Team Confirmed 04/08/2018

Associated revisions

Revision 929c9cb6 (diff)
Added by anonym 10 days ago

Thunderbird: unconditionally disable Autocrypt.

It is not safe in its current state (refs: #15923).

Will-fix: #16186

History

#1 Updated by sajolida 3 months ago

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 3 months ago

#3 Updated by goupille 3 months ago

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 3 months ago

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 3 months ago

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 3 months ago

  • 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 3 months ago

  • 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 3 months ago

  • 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 2 months ago

#10 Updated by sajolida 2 months ago

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 about 2 months ago

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

#12 Updated by hefee about 1 month ago

  • Assignee changed from intrigeri to hefee

#13 Updated by intrigeri about 1 month ago

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

#14 Updated by intrigeri about 1 month ago

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 #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 about 1 month ago

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 16 days ago

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 16 days ago

  • Estimated time set to 1.30 h

#18 Updated by hefee 13 days ago

  • Estimated time changed from 1.30 h to 4.00 h

#19 Updated by intrigeri 13 days ago

  • Status changed from Confirmed to In Progress

#20 Updated by hefee 12 days ago

Subject: Tails and Autocrypt
Date: Monday, 3. December 2018, 13:44:00 CET
To:
CC: , Patrick Brunschwig <>

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] https://redmine.tails.boum.org/code/attachments/download/2189/per-user-edit-rules.png

#21 Updated by intrigeri 12 days ago

  • Assignee changed from hefee to anonym

#22 Updated by hefee 12 days ago

  • Assignee changed from anonym to hefee

#23 Updated by hefee 12 days ago

  • 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: #16186

#24 Updated by anonym 10 days ago

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 8 days ago

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 8 days ago

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 2 days ago

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

Also available in: Atom PDF