Project

General

Profile

Feature #15923

Autocrypt forces unencrypted messages

Added by sajolida 2 months ago. Updated 7 days ago.

Status:
Confirmed
Priority:
Elevated
Assignee:
Category:
-
Target version:
Start date:
09/07/2018
Due date:
% Done:

0%

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


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

History

#1 Updated by sajolida 2 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 2 months ago

#3 Updated by goupille 2 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 2 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 2 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 2 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 2 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 about 2 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 about 1 month ago

#10 Updated by sajolida about 1 month 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 25 days ago

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

#12 Updated by hefee 8 days ago

  • Assignee changed from intrigeri to hefee

#13 Updated by intrigeri 7 days ago

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

#14 Updated by intrigeri 7 days 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 7 days 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.

Also available in: Atom PDF