Bug #11536
Icedove autoconfiguration is broken for ISPs serving a OAuth config
100%
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…
Subtasks
Related issues
|
Related to Tails - |
Resolved | 2016-09-15 | |
| Blocks Tails - Feature #6156: Upstream secure Thunderbird autoconfig wizard | In Progress | 2016-05-19 |
History
#1 Updated by intrigeri 2016-07-13 12:34:17
- Priority changed from Normal to Elevated
- Deliverable for set to SponsorS_Internal
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 2016-07-21 06:04:51
- Target version changed from Tails_2.5 to Tails_2.6
#3 Updated by Anonymous 2016-08-18 12:19:17
- blocks Feature #6156: Upstream secure Thunderbird autoconfig wizard added
#4 Updated by anonym 2016-08-27 02:38:26
- Status changed from Confirmed to In Progress
- Assignee deleted (
anonym) - % 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 2016-09-01 17:00:39
- Status changed from In Progress to Fix committed
- % Done changed from 50 to 100
Applied in changeset commit:8cea27e0b5048587c2165f14afc16b811bfceb3a.
#6 Updated by anonym 2016-09-02 07:15:16
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 Anonymous 2016-09-06 03:28:11
- Assignee set 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 Anonymous 2016-09-06 03:28:25
- Status changed from Fix committed to In Progress
- % Done changed from 100 to 90
#9 Updated by Anonymous 2016-09-06 03:47:44
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 2016-09-13 07:50:02
- Assignee deleted (
anonym) - 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 Anonymous 2016-09-15 01:58:21
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 Anonymous 2016-09-15 02:01:31
- related to
Feature #11798: Document usage of unfriendly email providers using Icedove in Tails added
#13 Updated by Anonymous 2016-09-15 02:02:22
So what remains to be done on this ticket is merely a second test of the reported findings.
#14 Updated by anonym 2016-09-15 05:17:29
- Status changed from In Progress to Fix committed
- Assignee deleted (
) - % 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 Feature #11798, though.
One less Icezombie ticket! \o/
#15 Updated by anonym 2016-09-20 16:47:36
- Status changed from Fix committed to Resolved