Project

General

Profile

Feature #7064

Feature #5663: Return to Icedove

Feature #6148: Torbirdy in Debian

Feature #6154: Secure the Icedove autoconfig wizard

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

Added by intrigeri over 5 years ago. Updated over 3 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
Due date:
% Done:

100%

Feature Branch:
Type of work:
Research
Starter:
No
Affected tool:
Email Client

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 documentationResolved


Related issues

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

History

#1 Updated by anonym over 5 years ago

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

#2 Updated by BitingBird over 5 years ago

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 about 5 years ago

  • Priority changed from High to Normal

#4 Updated by intrigeri about 5 years ago

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

#5 Updated by intrigeri about 5 years ago

  • Category set to 212

#6 Updated by BitingBird over 4 years ago

  • Due date deleted (05/31/2014)

#7 Updated by BitingBird over 4 years ago

  • Description updated (diff)

#8 Updated by intrigeri over 4 years ago

  • Description updated (diff)
  • Assignee changed from anonym to u
  • Target version set to 246

#10 Updated by sajolida almost 4 years ago

  • Target version changed from 246 to Tails_2.0

#11 Updated by u almost 4 years ago

  • Description updated (diff)

#12 Updated by u over 3 years ago

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

#13 Updated by u over 3 years ago

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 u over 3 years ago

  • Description updated (diff)

#15 Updated by u over 3 years ago

  • Description updated (diff)

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 u over 3 years ago

  • Description updated (diff)

#17 Updated by u over 3 years ago

  • Description updated (diff)

#18 Updated by u over 3 years ago

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

#19 Updated by u over 3 years ago

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

#20 Updated by u over 3 years ago

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

#21 Updated by u over 3 years ago

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 over 3 years ago

  • Assignee changed from u to intrigeri
  • QA Check set to Ready for QA

I'll review the proposed communication with Mozilla.

#23 Updated by intrigeri over 3 years ago

  • Status changed from Confirmed to In Progress
  • Assignee changed from intrigeri to u
  • 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 #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 u over 3 years ago

  • Status changed from In Progress to Resolved

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

#25 Updated by intrigeri over 3 years ago

  • Assignee deleted (u)

Also available in: Atom PDF