Tails

#2 Updated by segfault 2019-11-10 14:59:33

As @azadi explained over email, the setAccountPrefs() function is called everytime Thunderbird is started. IIUC, that means that if a user configured an account with settings considered insecure, they can still use the account with those settings until they restart Thunderbird for the first time. Then, when Thunderbird is restarted, their settings will be silently overwritten.

That doesn’t seem like the best behavior to me. If we want to enforce certain account settings, then:

1. these settings should be always enforced, not only after Thunderbird is restarted
2. they shouldn’t appear as configurable to the user in the first place.

I think we should go through the settings configured by TorBirdy and discuss whether they should actually be enforced in Tails. I think some settings might already be enforced by the Thunderbird patches we upstreamed, for example the use of SSL ports.

#3 Updated by intrigeri 2019-11-10 15:08:18

> That doesn’t seem like the best behavior to me. If we want to enforce certain account settings, then: […]
> I think we should go through the settings configured by TorBirdy and discuss whether they should actually be enforced in Tails.

+1

#4 Updated by segfault 2019-11-24 12:17:28

I see the following settings being set for all accounts by setAccountPrefs():

• mail.identity.id#.draft_folder to a a local folder ("mailbox://nobodyLocal%20Folders/Drafts"). * mail.server.server#.login_at_startup@
• mail.server.server#.download_on_biff
• mail.server.server#.do_biff
• mail.server.server#.port
• mail.server.server#.socketType
• mail.server.server#.authMethod
• mail.smtpserver.smtp#.port
• mail.smtpserver.smtp#.try_ssl
• mail.smtpserver.smtp#.auth_method

Note that while the setAccountPrefs() function is called everytime Thunderbird is started, these preferences are only set the first time Thunderbird is restarted after TorBirdy was installed (on subsequent calls, extensions.torbirdy.first_run is set to true and setAccountPrefs() returns without setting any preferences).

I think we don’t care about setting the port, socket type, and auth method here, because our patched setup wizard should already enforce secure settings for these. But I’d like @anonym to confirm that.

Regarding mail.identity.id#.draft_folder:

The reason that TorBirdy sets the draft folder to local is to prevent cleartext drafts from being sent to the IMAP server. Enigmail also tries to prevent that, if it’s autoEncryptDrafts setting is set, which it is by default (it’s configurable by the user via the “Encrypt draft messages on saving” option in “Account Settings” -> “OpenPGP Security”). If that setting is enabled, drafts will automatically be encrypted with the user’s own public key before being saved to the drafts folder.

So I understand the behavior of TorBirdy, to still set the draft folder to local, as a precautionary safety measure, to prevent issues like [1] from happening in case that Enigmail’s autoEncryptDrafts is disabled or doesn’t work reliably.

[1] https://tails.boum.org/security/claws_mail_leaks_plaintext_to_imap/index.en.html

I would prefer it if we could keep that behavior, so I tried to set the default value to the local folder by putting this line in /etc/thunderbird/pref/thunderbird.js and defaults/profile/prefs.js in /usr/share/thunderbird/omni.ja (for the latter I also tried using user_pref):

pref("mail.identity.default.draft_folder", "mailbox://nobody@Local%20Folders/Drafts");

But when I set up a new IMAP account, it still defaults to use the IMAP server’s folder.

Now we could spend more time on trying to get this to work, or decide that we drop that setting and rely on Enigmail’s autoEncryptDrafts.

Regarding login_at_startup, download_on_biff, and do_biff:

IIUC, the choice to disable those by default was made on https://trac.torproject.org/projects/tor/ticket/6337.

The reasons don’t seem critical to me. Actually, I think the UX impact of not being notified of incoming email (which is what I expect an email client to do) is worse than the “unnecessary” load to Tor and the email server being able to guess how long the Tor session lasted. And regarding arma’s argument that “We really want to avoid Tor packages that use Tor the whole time whether the user is around or not — it means the directory fetching can never go idle.” - I think that even without Thunderbird running, Tails uses Tor when the user is not around.

I tried to change the default by setting these preferences in the same files as for the draft_folder setting above:

pref("mail.server.default.login_at_startup", false);
pref("mail.server.default.download_on_biff", false);
pref("mail.server.default.do_biff", false);

But that also didn’t work. When I set up a new account, it still has the settings enabled by default.

#6 Updated by intrigeri 2019-11-25 11:51:59

Hi segfault,

first, I did not check if the “3.6.14 Thunderbird” section of our design doc has anything relevant to this ticket or to its parent. Maybe it has :)

> Note that while the setAccountPrefs() function is called everytime Thunderbird is started, these preferences are only set the first time Thunderbird is restarted after TorBirdy was installed (on subsequent calls, extensions.torbirdy.first_run is set to true and setAccountPrefs() returns without setting any preferences).

I’m not sure I understand: how does this work for accounts created after the first run?

> I think we don’t care about setting the port, socket type, and auth method here, because our patched setup wizard should already enforce secure settings for these. But I’d like @anonym to confirm that.

+1

> Regarding mail.identity.id#.draft_folder:

> The reason that TorBirdy sets the draft folder to local is to prevent cleartext drafts from being sent to the IMAP server. Enigmail also tries to prevent that, if it’s autoEncryptDrafts setting is set, which it is by default (it’s configurable by the user via the “Encrypt draft messages on saving” option in “Account Settings” -> “OpenPGP Security”). If that setting is enabled, drafts will automatically be encrypted with the user’s own public key before being saved to the drafts folder.

> So I understand the behavior of TorBirdy, to still set the draft folder to local, as a precautionary safety measure, to prevent issues like [1] from happening in case that Enigmail’s autoEncryptDrafts is disabled or doesn’t work reliably.

This makes sense to me.

> I would prefer it if we could keep that behavior, so I tried to set the default value to the local folder by putting this line in /etc/thunderbird/pref/thunderbird.js and defaults/profile/prefs.js in /usr/share/thunderbird/omni.ja (for the latter I also tried using user_pref):

>

> pref("mail.identity.default.draft_folder", "mailbox://nobody@Local%20Folders/Drafts");
> 

> But when I set up a new IMAP account, it still defaults to use the IMAP server’s folder.

Ouch.

> Now we could spend more time on trying to get this to work, or decide that we drop that setting and rely on Enigmail’s autoEncryptDrafts.

It would be nice to reproduce with a pristine Thunderbird outside of Tails and to ensure this bug is tracked upstream.

But apart of that, IMO it’s acceptable to drop this setting:

• A user who does not use OpenPGP will see their drafts stored in cleartext on the IMAP server. This only leaks info that will not be in the final email they’ll send via their email provider (and probably store in the Sent folder there). I don’t know how common a problem that is but I think it’s an OK trade-off. The problem of “when am I really sending content to a remote server” is more widespread, BTW: for example, when typing text in a text area in the Browser, technically the remote server can get all intermediary states of the text, while the user may be under the impression that it’ll get sent only when they explicitly indicate their desire to do so, e.g. by pressing “Submit”.
• For a user who does use OpenPGP, relying on Enigmail’s autoEncryptDrafts seems good enough to me.

> Regarding login_at_startup, download_on_biff, and do_biff:

> IIUC, the choice to disable those by default was made on https://trac.torproject.org/projects/tor/ticket/6337.

> The reasons don’t seem critical to me. Actually, I think the UX impact of not being notified of incoming email (which is what I expect an email client to do) is worse than the “unnecessary” load to Tor and the email server being able to guess how long the Tor session lasted.

Agreed on these points.

> And regarding arma’s argument that “We really want to avoid Tor packages that use Tor the whole time whether the user is around or not — it means the directory fetching can never go idle.” -

Do you know what are the consequences of “the directory fetching can never go idle”? (I don’t.)
Asking Roger on IRC might be the fastest way to clarify this.

> I think that even without Thunderbird running, Tails uses Tor when the user is not around.

As I understand it, when Roger says “that use Tor”, it refers to clients asking Tor to do stuff; and not, for example, to the network activity that the tor daemon itself does, e.g. keeping a bunch of clean new circuits available.
I’d love if you could share what sort of background Tor usage you have in mind :)

Unfortunately, there’s another argument in favour of Torbirdy’s default behaviour: if I have several email accounts configured and hosted on the same server, then the admins of that server can see that these accounts are very often checked at the same time (and most likely using the same Tor cuircuit). This could allow them to correlate multiple contextual identities. Granted, we explicitly say that Tails does not magically isolate multiple contextual identities, but it could be that users in the real world have expectations that don’t match what we think is “supported” or not: if we really wanted users not to do that because we feel we’re unable to protect them if they do, then we should make it impossible to set up more than 1 account in Thunderbird (no, I’m not saying we should do this!). I’m not sure what conclusion to draw from this.

> I tried to change the default by setting these preferences in the same files as for the draft_folder setting above:
> […]
> But that also didn’t work. When I set up a new account, it still has the settings enabled by default.

Hmmm, since it also did not work for the default drafts folder, to me it sounds like either we’re not setting these in the right place, or this entire “default per-account settings” part of Thunderbird is buggy. I hope that trying to reproduce on a pristine Thunderbird outside of Tails can shed some light on this.

#7 Updated by Anonymous 2019-11-25 16:54:53

intrigeri wrote:

> But apart of that, IMO it’s acceptable to drop this setting:
>
> * A user who does not use OpenPGP will see their drafts stored in cleartext on the IMAP server. This only leaks info that will not be in the final email they’ll send via their email provider (and probably store in the Sent folder there). I don’t know how common a problem that is but I think it’s an OK trade-off. The problem of “when am I really sending content to a remote server” is more widespread, BTW: for example, when typing text in a text area in the Browser, technically the remote server can get all intermediary states of the text, while the user may be under the impression that it’ll get sent only when they explicitly indicate their desire to do so, e.g. by pressing “Submit”.

With regards to storing cleartext information in the “Sent” folder it seems that this setting does indeed not provide additional privacy to a user who is not using OpenPGP. Unless their “Sent” folder is also local. I’m not sure however if this would be simply a Thunderbird setting or if it’s a placebo setting, i.e. I don’t know if the server always stores sent email on itself, or if one can force the server to not to do this by configuring this setting in the mail client.

#8 Updated by segfault 2019-11-25 21:48:13

intrigeri wrote:
> first, I did not check if the “3.6.14 Thunderbird” section of our design doc has anything relevant to this ticket or to its parent. Maybe it has :)

It describes the behavior of TorBirdy to set the drafts folder to local: “Furthermore, when setting up an IMAP account, the drafts folder, instead of being remote, is set to ~$HOME/.thunderbird/Local Folders.”.

We will have to update that section anyway. I just created Feature #17259 for that.

> > Note that while the setAccountPrefs() function is called everytime Thunderbird is started, these preferences are only set the first time Thunderbird is restarted after TorBirdy was installed (on subsequent calls, extensions.torbirdy.first_run is set to true and setAccountPrefs() returns without setting any preferences).
>
> I’m not sure I understand: how does this work for accounts created after the first run?

Good question. The way I understand the code is that the setAccountPrefs() function doesn’t affect those accounts.

> > Regarding mail.identity.id#.draft_folder:
>
> > The reason that TorBirdy sets the draft folder to local is to prevent cleartext drafts from being sent to the IMAP server. Enigmail also tries to prevent that, if it’s autoEncryptDrafts setting is set, which it is by default (it’s configurable by the user via the “Encrypt draft messages on saving” option in “Account Settings” -> “OpenPGP Security”). If that setting is enabled, drafts will automatically be encrypted with the user’s own public key before being saved to the drafts folder.
>
> > So I understand the behavior of TorBirdy, to still set the draft folder to local, as a precautionary safety measure, to prevent issues like [1] from happening in case that Enigmail’s autoEncryptDrafts is disabled or doesn’t work reliably.
>
> This makes sense to me.
>
> > I would prefer it if we could keep that behavior, so I tried to set the default value to the local folder by putting this line in /etc/thunderbird/pref/thunderbird.js and defaults/profile/prefs.js in /usr/share/thunderbird/omni.ja (for the latter I also tried using user_pref):
>
> > […]
>
> > But when I set up a new IMAP account, it still defaults to use the IMAP server’s folder.
>
> Ouch.
>
> > Now we could spend more time on trying to get this to work, or decide that we drop that setting and rely on Enigmail’s autoEncryptDrafts.
>
> It would be nice to reproduce with a pristine Thunderbird outside of Tails and to ensure this bug is tracked upstream.

I’m not sure it’s a bug. I only learned about this option from [1], and there it doesn’t even have a description (and it says that it’s of type Boolean, which I’m pretty sure that it’s not). I just git grep’d the thunderbird git repo and the only occurrence of that preference is:

comm/mailnews/mailnews.js:pref("mail.identity.default.draft_folder", "mailbox://nobody@Local%20Folders/Drafts");

So it’s even set to the local folder by default.

[1] http://kb.mozillazine.org/Mail_and_news_settings

> But apart of that, IMO it’s acceptable to drop this setting:
>
> * A user who does not use OpenPGP will see their drafts stored in cleartext on the IMAP server. This only leaks info that will not be in the final email they’ll send via their email provider (and probably store in the Sent folder there). I don’t know how common a problem that is but I think it’s an OK trade-off. The problem of “when am I really sending content to a remote server” is more widespread, BTW: for example, when typing text in a text area in the Browser, technically the remote server can get all intermediary states of the text, while the user may be under the impression that it’ll get sent only when they explicitly indicate their desire to do so, e.g. by pressing “Submit”.
> * For a user who does use OpenPGP, relying on Enigmail’s autoEncryptDrafts seems good enough to me.

Good. Then I will not spend more time on trying to set that option.

> > Regarding login_at_startup, download_on_biff, and do_biff:
>
> > IIUC, the choice to disable those by default was made on https://trac.torproject.org/projects/tor/ticket/6337.
>
> > The reasons don’t seem critical to me. Actually, I think the UX impact of not being notified of incoming email (which is what I expect an email client to do) is worse than the “unnecessary” load to Tor and the email server being able to guess how long the Tor session lasted.
>
> Agreed on these points.
>
> > And regarding arma’s argument that “We really want to avoid Tor packages that use Tor the whole time whether the user is around or not — it means the directory fetching can never go idle.” -
>
> Do you know what are the consequences of “the directory fetching can never go idle”? (I don’t.)
> Asking Roger on IRC might be the fastest way to clarify this.

I asked him and got this reply:

if you run a tor binary, and you leave it alone, it stops using your network after a day or so
but if you poke it with a socks connection once a day, it will always think it's active, so it will always use your network

that said, tor browser does the daily socks connection, to check if there is a new browser update
so many tors have this unfortunate behavior

there are several phases of going inactive. in the first phase, if there have been no socks requests within an hour, tor stops maintaining open circuits
in the second phase, it keeps downloading a new consensus... and it used to stop fetching descriptors, but now we use microdescriptors, so i'm not actually sure whether it stops fetching those.
and in the third phase, it writes down "i'm inactive" in its state file, and it doesn't fetch anything from the network until it gets a new request.

So if the user has Tor Browser (or any other application which produces regular network traffic, like Pidgin for example, and probably also Electrum (but I didn’t check that)) open, tor will never go completely inactive anyway.

> > I think that even without Thunderbird running, Tails uses Tor when the user is not around.
>
> As I understand it, when Roger says “that use Tor”, it refers to clients asking Tor to do stuff; and not, for example, to the network activity that the tor daemon itself does, e.g. keeping a bunch of clean new circuits available.
> I’d love if you could share what sort of background Tor usage you have in mind :)

You’re right, I can’t think of any background Tor usage. But we have the same issue with other applications, I don’t see why we should prevent this specifically in Thunderbird.

> Unfortunately, there’s another argument in favour of Torbirdy’s default behaviour: if I have several email accounts configured and hosted on the same server, then the admins of that server can see that these accounts are very often checked at the same time (and most likely using the same Tor cuircuit). This could allow them to correlate multiple contextual identities.

But isn’t the same true if you repeatedly check your email accounts by clicking “Get Messages”?

> Granted, we explicitly say that Tails does not magically isolate multiple contextual identities, but it could be that users in the real world have expectations that don’t match what we think is “supported” or not: if we really wanted users not to do that because we feel we’re unable to protect them if they do, then we should make it impossible to set up more than 1 account in Thunderbird (no, I’m not saying we should do this!). I’m not sure what conclusion to draw from this.

I still think that the UX impact is worse than what we gain from disabling the automatic check, i.e. reducing the Tor traffic in cases where the user leaves Tails idle with Thunderbird running, but not Tor Browser or Pidgin.

> > I tried to change the default by setting these preferences in the same files as for the draft_folder setting above:
> > […]
> > But that also didn’t work. When I set up a new account, it still has the settings enabled by default.
>
> Hmmm, since it also did not work for the default drafts folder, to me it sounds like either we’re not setting these in the right place, or this entire “default per-account settings” part of Thunderbird is buggy. I hope that trying to reproduce on a pristine Thunderbird outside of Tails can shed some light on this.

I also grepped for these settings in the thunderbird repo. For download_on_biff and login_at_startup, they are also already set to false in comm/mailnews/mailnews.js. A setting do_biff doesn’t seem to exist. Since for new accounts, tje login_at_startup and download_on_biff settings are enabled, I’m pretty sure that the .default. settings won’t help us.

#9 Updated by anonym 2019-11-28 11:39:18

segfault wrote:
> intrigeri wrote:
> > > Regarding mail.identity.id#.draft_folder:
> […]
> I’m not sure it’s a bug. I only learned about this option from [1], and there it doesn’t even have a description (and it says that it’s of type Boolean, which I’m pretty sure that it’s not). I just git grep’d the thunderbird git repo and the only occurrence of that preference is:

I did these greps and found some other possible uses:

• git grep "mail\.identity\.default\.[^[:alnum:]]"
• git grep "mail\.identity\.%[[:alnum:]]*%\.draft_folder"

In general there are programmatic ways that “mail.identity.default” can be targeted, so your approach (and mine) isn’t exhaustive.

Any way, I think we definitely can call this a bug since the intention clearly is what we expect for the other prefs, just not for draft_folder. What else could they means with “default” in this context?

> > But apart of that, IMO it’s acceptable to drop this setting:
> >
> > * A user who does not use OpenPGP will see their drafts stored in cleartext on the IMAP server. This only leaks info that will not be in the final email they’ll send via their email provider (and probably store in the Sent folder there). I don’t know how common a problem that is but I think it’s an OK trade-off. The problem of “when am I really sending content to a remote server” is more widespread, BTW: for example, when typing text in a text area in the Browser, technically the remote server can get all intermediary states of the text, while the user may be under the impression that it’ll get sent only when they explicitly indicate their desire to do so, e.g. by pressing “Submit”.
> > * For a user who does use OpenPGP, relying on Enigmail’s autoEncryptDrafts seems good enough to me.
>
> Good. Then I will not spend more time on trying to set that option.

I got to be honest with that I don’t really trust Enigmail’s autoEncryptDrafts feature. I cannot recall all details but it has been broken at least twice (Enigmail 1.8.1 from 2015-03-23 says “This release addresses some critical defects around saving drafts”; I cannot find the other instance, which I think would be around 2010-2011). And with “broken” I mean that it saves the plaintext message into the remote drafts folder. Combined with that Claws Mail broke in the same way, I’m skeptical. So I’d like us to try to be better!

Short-term:

• Report to upstream the bug for mail.identity.default.draft_folder (and maybe for login_at_startup and download_on_biff while we’re at it)
• Find another workaround:
  • Let’s test if we can seed our prefs with mail.identity.idN.draft_folder for N = 1..20 or something; unless they are overwritten during account creation, this could work.
  • We could try doing the above using the AutoConfig feaure, with lockPref().
  • We could also try the old autoconfig.js approach (if it still works? Alternatives: 1, 2 for running arbitrary code. My hope is that we can more or less copy-paste the same code that TorBirdy runs to hook into the account creation process for the fix.
  • If all above fails and we cannot find another workaround, then what about completely disabling the draft feature (disabling auto-saving + hide the GUI buttons and menu entries)? How bad UX is this?

Long-term:

• Once mail.identity.default.draft_folder is fixed, we use it.

> > > Regarding login_at_startup, download_on_biff, and do_biff:
> […]
> > Unfortunately, there’s another argument in favour of Torbirdy’s default behaviour: if I have several email accounts configured and hosted on the same server, then the admins of that server can see that these accounts are very often checked at the same time (and most likely using the same Tor cuircuit). This could allow them to correlate multiple contextual identities.
>
> But isn’t the same true if you repeatedly check your email accounts by clicking “Get Messages”?

Indeed, clicking on “Get Messages” fetches all accounts, so users that want to keep accounts separate would have to be careful to click the “expander” (the down arrow) and then only refresh the specific inbox. So it’s possible, but very error-prone.

> > Granted, we explicitly say that Tails does not magically isolate multiple contextual identities, but it could be that users in the real world have expectations that don’t match what we think is “supported” or not: if we really wanted users not to do that because we feel we’re unable to protect them if they do, then we should make it impossible to set up more than 1 account in Thunderbird (no, I’m not saying we should do this!). I’m not sure what conclusion to draw from this.
>
> I still think that the UX impact is worse than what we gain from disabling the automatic check, i.e. reducing the Tor traffic in cases where the user leaves Tails idle with Thunderbird running, but not Tor Browser or Pidgin.

This I agree with 100%, but above intrigeri is talking about the isolation problem, where I find it harder to find a clear answer for. However, given our warning on this topic, and that we cannot solve it in general (like for any arbitrary services accesses through Tor Browser), I’m inclined to still agree.

> I also grepped for these settings in the thunderbird repo. For download_on_biff and login_at_startup, they are also already set to false in comm/mailnews/mailnews.js. A setting do_biff doesn’t seem to exist. Since for new accounts, tje login_at_startup and download_on_biff settings are enabled, I’m pretty sure that the .default. settings won’t help us.

If one of the workarounds for draft_folder from above works I expect that it would work for these as well, if we still care.

#10 Updated by anonym 2019-11-28 11:59:25

segfault wrote:
> I think we don’t care about setting the port, socket type, and auth method here, because our patched setup wizard should already enforce secure settings for these. But I’d like anonym to confirm that.

Confirmed!

#11 Updated by segfault 2019-11-28 12:17:39

anonym wrote:
> segfault wrote:
> > intrigeri wrote:
> > > * A user who does not use OpenPGP will see their drafts stored in cleartext on the IMAP server. This only leaks info that will not be in the final email they’ll send via their email provider (and probably store in the Sent folder there). I don’t know how common a problem that is but I think it’s an OK trade-off. The problem of “when am I really sending content to a remote server” is more widespread, BTW: for example, when typing text in a text area in the Browser, technically the remote server can get all intermediary states of the text, while the user may be under the impression that it’ll get sent only when they explicitly indicate their desire to do so, e.g. by pressing “Submit”.
> > > * For a user who does use OpenPGP, relying on Enigmail’s autoEncryptDrafts seems good enough to me.
> >
> > Good. Then I will not spend more time on trying to set that option.
>
> I got to be honest with that I don’t really trust Enigmail’s autoEncryptDrafts feature. I cannot recall all details but it has been broken at least twice (Enigmail 1.8.1 from 2015-03-23 says “This release addresses some critical defects around saving drafts”; I cannot find the other instance, which I think would be around 2010-2011). And with “broken” I mean that it saves the plaintext message into the remote drafts folder. Combined with that Claws Mail broke in the same way, I’m skeptical. So I’d like us to try to be better!
>
> Short-term:
> * Report to upstream the bug for mail.identity.default.draft_folder (and maybe for login_at_startup and download_on_biff while we’re at it)
> * Find another workaround:
> Let’s test if we can seed our prefs with mail.identity.idN.draft_folder for N = 1..20 or something; unless they are overwritten during account creation, this could work.

I tried that, the pref got overwritten during account creation.

> We could try doing the above using the AutoConfig feaure, with lockPref().

That worked! I will prepare a commit.

#15 Updated by intrigeri 2019-11-29 06:16:11

> I pushed a commit which uses AutoConfig to enforces a local drafts folder for the first 20 accounts. I’m using the “lockPref()” function, which means that the user won’t be able to change that setting. I found no other way to prevent this pref from being overwritten during account creation.

Code LGTM. I’ll now build & test.

> I assume that we could do the same for the login_at_startup and download_on_biff, if we decide that we want to keep those disabled.

I feel this topic is too complex to decide in a rush to change these settings, so I propose we do this:

• For 4.1, we stick to the behavior we had in previous versions of Tails.
• We file a dedicated ticket where we discuss your proposal, i.e. enabling these settings, post-4.1.