Bug #11536

Icedove autoconfiguration is broken for ISPs serving a OAuth config

Added by anonym about 1 year ago. Updated 11 months ago.

Status:ResolvedStart date:06/17/2016
Priority:ElevatedDue date:
Assignee:-% Done:

100%

Category:-
Target version:Tails_2.6
QA Check:Pass Blueprint:
Feature Branch:feature/11714-icedove-45.2.0-1 Easy:
Type of work:Code Affected tool:Email Client

Description

So Thunderbird support the OAuth instead of e.g. the usual "Normal password" authentication method, and it may be selected when fetching a config from the ISP or Mozilla database. In this case, Icedove will open its "bundled" browser in a new window with the OAuth login page. The requires enabling both cookies and JavaScript for the browser component in Icedove, which I believe we disable for very good reasons.

So when a config where OAuth is used is selected, autoconfig is broken in Tails' Icedove, and it will be very messy UX-wise for users.

Crappy workaround: when the option is presented, click "Manual config" and then change the auth method for IMAP/POP and SMTP to "Normal password". The problem is that users essentially will have to know if OAuth is gonna be selected before hand.

I crawled autoconfig.thunderbird.net to see how many mail providers have OAuth, and luckily it's not many:

mail.ru
list.ru
jazztel.es
inbox.ru
googlemail.com
google.com
gmail.com
corp.mail.ru
bk.ru
jazztel.es
googlemail.com
google.com
gmail.com

However, some of these are very popular, e.g. the google ones and mail.ru.

Possible short-term fix: bundle valid configurations (on "disk") for those the most popular ones at least.

Possible long-term fix: introduce a new pref (e.g. mailnews.auto_config.oauth.enabled) so OAuth configurations can be rejected. Often OAuth is the only config presented (e.g. for gmail no "Normal Password" alternative is presented) which means that autoconfiguration will have to fallback to guessing, but that's fine. This requires more upstream Icedove work...


Related issues

Related to Tails - Feature #11798: Document usage of unfriendly email providers using Icedove in Tails Resolved 09/15/2016
Blocks Tails - Feature #6156: Upstream secure Icedove autoconfig wizard In Progress 05/19/2016

Associated revisions

Revision 8cea27e0
Added by anonym 12 months ago

Merge remote-tracking branch 'origin/feature/11714-icedove-45.2.0-1' into devel

Fix-committed: #11714, #11613, #11536

History

#1 Updated by intrigeri about 1 year ago

  • Priority changed from Normal to Elevated

My understanding is that it's a regression brought by Tails 2.4, that affects users of major ISPs like Gmail => bumping priority.

#2 Updated by intrigeri about 1 year ago

  • Target version changed from Tails_2.5 to Tails_2.6

#3 Updated by u about 1 year ago

  • Blocks Feature #6156: Upstream secure Icedove autoconfig wizard added

#4 Updated by anonym 12 months ago

  • Status changed from Confirmed to In Progress
  • Assignee changed from anonym to u
  • % Done changed from 0 to 50
  • QA Check set to Ready for QA
  • Feature Branch set to feature/11714-icedove-45.2.0-1

Can you please test with a GMail account, u? Otherwise, please reassign it to me.

#5 Updated by anonym 12 months ago

  • Status changed from In Progress to Fix committed
  • % Done changed from 50 to 100

#6 Updated by anonym 12 months ago

It's committed, but if you get the change, I'd appreciate if you could test this in Tails 2.6~rc1 (will be made available in a few hours).

#7 Updated by u 12 months ago

  • Assignee changed from u to anonym
  • QA Check changed from Ready for QA to Dev Needed

Hi anonym!

I tested you latests fix in Tails 2.6~rc1 and got the same result as you did. I used a GMail account for testing.

  • we can successfully retrieve the configuration using our secure protocols
  • but the password is never accepted and there is no specific error message except that it's probably the wrong password.

I've enabled POP and IMAP in the Gmail account though.

I'll try a bit more to see if I find any other error message or such a thing.

#8 Updated by u 12 months ago

  • Status changed from Fix committed to In Progress
  • % Done changed from 100 to 90

#9 Updated by u 12 months ago

Hm, tried some more things, but the problem persists:

  • tried to send email, but the password was equally rejected even after, in GMail, I activated "allow less secure apps" on the bottom of https://myaccount.google.com/security
  • GMail detected one connection attempt by me but blocked it (visible on the same page). I confirmed "it was me" - but well, Tor exit nodes change...
  • Later, no other connection attempt was recorder in GMail, so I suppose it happened only during the account setup, not later when I tried to reconnect.

Hope it helps.

#10 Updated by anonym 11 months ago

  • Assignee changed from anonym to u
  • QA Check changed from Dev Needed to Info Needed

I managed to get the account logged in inside Tails by disabling our Tor enforcement:

echo "nameserver 8.8.8.8" | sudo tee /etc/resolv.conf" 
sudo /usr/local/lib/do_not_ever_run_me

and then configuring TorBirdy to do "Transparent Torification" (=> direct connection) in Icedove. Furthermore I also had to enable less secure apps because Google explicitly deems Thunderbird as insecure. Wow.

Then I rebooted Tails and tried again with Tor, and then I could create and login to the account as well. I wonder if this was because the Exit node I happened to use this time was not considered bad by google, or if the initial successful setup of the account opened this possibility up, even over Tor. If the latter (which I suspect is the case), I do not want to advice that to users. :S But I don't have the energy to do enough tests to verify whether this is probably the case.

Any way, it seems like a Tor-issue, right? If so, we've done what we can on the technical side (so the patch upstreaming can continue) and what remains for Tails is to perhaps document that "some unfriendly E-mail providers, like GMail, don't work well in Icedove in Tails", or similar.

What do you think?

#11 Updated by u 11 months ago

anonym wrote:

I managed to get the account logged in inside Tails by disabling our Tor enforcement:
[...]

<33 that's good news!

and then configuring TorBirdy to do "Transparent Torification" (=> direct connection) in Icedove. Furthermore I also had to enable less secure apps because Google explicitly deems Thunderbird as insecure. Wow.

yep, we should probably document that along with your proposal about "unfriendly email providers.."..

Then I rebooted Tails and tried again with Tor, and then I could create and login to the account as well. I wonder if this was because the Exit node I happened to use this time was not considered bad by google, or if the initial successful setup of the account opened this possibility up, even over Tor. If the latter (which I suspect is the case), I do not want to advice that to users. :S But I don't have the energy to do enough tests to verify whether this is probably the case.

I can do a second test to confirm it.

Any way, it seems like a Tor-issue, right? If so, we've done what we can on the technical side (so the patch upstreaming can continue) and what remains for Tails is to perhaps document that "some unfriendly E-mail providers, like GMail, don't work well in Icedove in Tails", or similar.

What do you think?

I do agree. And I'll create a ticket to track this.

#12 Updated by u 11 months ago

  • Related to Feature #11798: Document usage of unfriendly email providers using Icedove in Tails added

#13 Updated by u 11 months ago

So what remains to be done on this ticket is merely a second test of the reported findings.

#14 Updated by anonym 11 months ago

  • Status changed from In Progress to Fix committed
  • Assignee deleted (u)
  • % Done changed from 90 to 100
  • QA Check changed from Info Needed to Pass

u wrote:

So what remains to be done on this ticket is merely a second test of the reported findings.

I think we can close this ticket -- it's completely clear that our Icedove now rejects OAuth2 configurations and picks something that will work for us, which this ticket was about. Doing my test again might be helpful to properly understand the failure mode when documenting #11798, though.

One less Icezombie ticket! \o/

#15 Updated by anonym 11 months ago

  • Status changed from Fix committed to Resolved

Also available in: Atom PDF