Feature #7064

Update our plans for securing Icedove's autoconfig wizard wrt. recent developments

Added by intrigeri 2014-04-11 12:36:24 . Updated 2016-05-10 04:28:37 .

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Target version:
Tails_2.0
Start date:
Due date:
% Done:

100%

Feature Branch:
Type of work:
Research
Blueprint:

https://tails.boum.org/blueprint/Return_of_Icedove__63__

Starter:
0
Affected tool:
Email Client
Deliverable for:
268

Description

People from the Tor project have been (more or less independently) working on this topic too, and we should see what are their current take on it and results. In particular, they seem to have made good progress in communicating their needs to upstream, which we have until now totally failed at on this topic:

It might even be that some of our patches are now obsolete, who knows :)

This ticket covers:

  • Understand what threat model our own patches address, and how successful they are in this respect
  • Understand what threat model the Tor people’s patches address, and how successful they are in this respect
  • Understand if these patchsets overlap and how
  • Decide what patchset is higher priority, taking into account which one has the greatest chances to land upstream

Subtasks

Feature #6149: Wait for Torbirdy patches design documentation Resolved

100

Related issues

Related to Tails - Feature #6156: Upstream secure Thunderbird autoconfig wizard In Progress 2016-05-19
Blocks Tails - Feature #7746: Rebase our patches on top of Icedove 38 Resolved 2014-08-05

History

#1 Updated by anonym 2014-04-16 15:43:24

  • Due date set to 2014-05-31
  • Assignee set to anonym

#2 Updated by BitingBird 2014-06-20 13:13:11

https://bugzilla.mozilla.org/show_bug.cgi?id=669282 is marked as resolved fixed.

The due date is past, should it be removed?

#3 Updated by sajolida 2014-07-10 20:23:59

  • Priority changed from High to Normal

#4 Updated by intrigeri 2014-08-11 12:50:16

  • blocks Feature #7746: Rebase our patches on top of Icedove 38 added

#5 Updated by intrigeri 2014-08-12 13:43:59

  • Category set to 212

#6 Updated by BitingBird 2015-01-08 05:16:50

  • Due date deleted (2014-05-31)

#7 Updated by BitingBird 2015-04-10 20:54:30

  • Description updated

#8 Updated by intrigeri 2015-05-29 12:26:18

  • Description updated
  • Assignee deleted (anonym)
  • Target version set to 246

#9 Updated by intrigeri 2015-05-29 12:26:32

  • blocks #8668 added

#10 Updated by sajolida 2015-11-27 04:44:56

  • Target version changed from 246 to Tails_2.0

#11 Updated by Anonymous 2015-12-14 08:05:27

  • Description updated

#12 Updated by Anonymous 2015-12-22 06:59:17

  • Blueprint set to https://tails.boum.org/blueprint/Return_of_Icedove__63__

#13 Updated by Anonymous 2016-01-04 14:42:15

As tested and discussed with anonym, bug numer 609238 has some bad news for Icedove in Tails.
https://bugzilla.mozilla.org/show_bug.cgi?id=669238

Guessing the mail provider configuration doesn't respect proxy settings, as noted in the above bug. Hence guesses won't work in Tails because non-Tor traffic is dropped. 
The good news is that all other methods (i.e. all three types of database lookups) still work, and they cover a vast amount of popular mail providers.

#14 Updated by Anonymous 2016-01-04 14:46:10

  • Description updated

#15 Updated by Anonymous 2016-01-04 15:09:40

  • Description updated

There seem to be several proposals for resolving https://bugzilla.mozilla.org/show_bug.cgi?id=971347

tagnaq’s:

0) file lookup
1) fetch from ISP ((try)HTTPS)
2) fetch from Mozilla's ISPDB (HTTPS)
3) fetch from ISP (HTTP)

Ben’s (which is awaiting tagnaq’s comment):

Rules:

0: local file
1. If ISP HTTPS call has a result, use that
2. If Mozilla ISPDB call has a result, use that
3. If Mozilla ISPDB call comes back with a connection problem,
   will ignore the result of the HTTP calls.
4. If MX call has a result, and ISP HTTPS call has a result for MX domain, use that
5. If MX call has a result, and Mozilla ISPDB call has a result for MX domain, use that
6. If ISP HTTP non-SSL autoconfig call has a result, use that
7. If ISP HTTP non-SSL webserver call has a result, use that

Alice Wonder’s:

0) fetch from (HTTPS) autoconfig.domain.tld
1) fetch from (HTTPS) Mozilla's ISPDB
2) fetch from (HTTPS) url pointed to in SRV record, if exists
3) fetch from local file, if exists

with comment:
Local file should be last. That prevents stale or trojan config data being used if the current verifiable (HTTPS x509) data can be retrieved.

I’ve pinged tagnaq to eventually reply on the original bug, to see if the proposed solution would fit.

What our patch does instead is to provide an option to rely ONLY on secure protocols

  • for the lookup AND
  • for using a mail server configuration itself.

As a conclusion of this research, regardless of the adopted solution Mozilla bug #971347, my proposal is to open a new ticket on the mozilla bugtracker with a our patches as a batch. I would propose to allow people to opt-in to accept only secure protocols. I’ propose to submit the same patch to Debian and to create an option in Torbirdy which would set this to true by default when one uses torbirdy. => basically this is https://labs.riseup.net/code/issues/6156

There seems also to be another bug which has a similar patch, but uses a hidden preference: https://bugzilla.mozilla.org/show_bug.cgi?id=664633 -> UPDATE: this is only to prevent the email address to be submitted in cleartext, and has been fixed.

#16 Updated by Anonymous 2016-01-04 15:20:44

  • Description updated

#17 Updated by Anonymous 2016-01-04 16:18:23

  • Description updated

#18 Updated by Anonymous 2016-01-05 15:06:28

Basically what I am proposing here is https://labs.riseup.net/code/issues/6156

#19 Updated by Anonymous 2016-01-05 15:06:50

  • related to Feature #6156: Upstream secure Thunderbird autoconfig wizard added

#20 Updated by Anonymous 2016-01-05 15:35:12

-> anonym proposes a patch for this one which could be upstreamed. I still have to review it.

#21 Updated by Anonymous 2016-01-07 16:06:47

Preparing the patches for Thunderbird. Waiting for a last review by intrigeri.
If they get accepted, we might want to submit patches to Torbirdy too, which enforce the use of our variables.

#22 Updated by intrigeri 2016-01-08 11:34:13

  • Assignee set to intrigeri
  • QA Check set to Ready for QA

I’ll review the proposed communication with Mozilla.

#23 Updated by intrigeri 2016-01-09 13:45:43

  • Status changed from Confirmed to In Progress
  • Assignee deleted (intrigeri)
  • QA Check changed from Ready for QA to Pass

Reviewed the email, it’s great!

What else do we need to close this ticket and continue on Feature #6156 (that I think we’ve already started)?

I’ll stop asking for threat modeling here: it was part of what this ticket was about, but in the end it looks like we were able to update our plans without doing threat modeling. So, I’ll postpone this expectation of mine to the time when the design doc is written: it would be great if the design doc made it clear what actual problem our patches are trying to solve: no auditor can check if we achieve our goals, before we have actually stated these goals :) I’ll let you do the paperwork to transfer this expectation to the relevant ticket.

Cheers!

#24 Updated by Anonymous 2016-01-09 18:18:39

  • Status changed from In Progress to Resolved

Thanks! I’ve added the relevant bits to Feature #10737. Now I’ll continue with Feature #6156.

#25 Updated by intrigeri 2016-05-10 04:28:37

  • Assignee deleted ()