669282 - [autoconfig] cleartext email address transmission

Status: RESOLVED FIXED

(Thunderbird :: Account Manager, defect)

Description

[tagnaq]

When configuring a new email account in the Account Manager, Thunderbird transmits the email address in the GET parameter "emailaddress" to autoconfig.example.com and example.com in cleartext, hence the user discloses
its email address to the LAN and everyone on the way to the destination.

http://autoconfig.example.com/mail/config-v1.1.xml?emailaddress=user%40example.com

http://example.com/.well-known/autoconfig/mail/config-v1.1.xml?emailaddress=user%40example.com

Not every user is fine with this disclosure, especially if users would like to preserve their privacy in hostile networks.
Please provide a way to opt-out. 

workaround:
provide random email address and configure manually afterwards

Steps to reproduce:
1. Add a new mail account
2. provide name and email
3. watch for http requests on the network (wireshark)


https://developer.mozilla.org/en/Thunderbird/Autoconfiguration

Comment 2

[Ben Bucksch (:BenB)]

Not a dup. This bug specifically asks for an opt-out setting (presumably via about:config), which is a reasonable request. I support this RFE.

Comment 3

[Ben Bucksch (:BenB)]

This needed by TorBirdy.

Comment 4

[Ben Bucksch (:BenB)]

Attachment: autoconfig-fetchisp-disable-669282-1.diff

Comment 5

[Ben Bucksch (:BenB)]

Attachment: Prefs to disable ISP fetch, email address transmission, and guess config

This additional pref allows to keep ISP configs enabled, but disable the transmission of the email address, which many ISPs don't need. Those that do can fail (HTTP 400) and we can continue.

The third pref allows to disable the guess config.

Comment 6

[Ben Bucksch (:BenB)]

Policy:
tagnaq, is only the email address a problem or the mere request via HTTP?
Please note that the identity of the ISP leaks in any case: When you look up imap.yourisp.com, everybody on your network knows you use yourisp. So, from a privacy perspective, the ISP lookup without email address should be OK.
That said, it should be possible to disable that request entirely, because it comes in via HTTP, which is a problem for authenticity (not just privacy), while the ISPDB lookups happen via HTTPS.

Comment 7

[Ben Bucksch (:BenB)]

https://trac.torproject.org/projects/tor/ticket/10836

Comment 8

[Magnus Melin [:mkmelin]]

Comment on attachment 8372645 [details] [diff] [review]
Prefs to disable ISP fetch, email address transmission, and guess config

Review of attachment 8372645 [details] [diff] [review]:
-----------------------------------------------------------------

::: mailnews/base/prefs/content/accountcreation/fetchConfig.js
@@ +73,5 @@
> +  var urlArgs = { emailaddress: emailAddress };
> +  if (!Services.prefs.getBoolPref(
> +      "mailnews.auto_config.fetchFromISP.emailAddressEnabled")) {
> +    delete urlArgs.emailaddress;
> +  }  

traling space. 
The pref name is inconsistent with the others (which are .enabled)

Comment 9

[Ben Bucksch (:BenB)]

> The pref name is inconsistent with the others (which are .enabled)

fetchFromISP is a component. enabled and emailAddressEnabled are prefs to control it. emailAddress is not a logical entity for prefs hierarchy.

(If you want to be nit-picking, I'm more bothered about the _ in "mailnews.auto_config_url". It should be "mailnews.autoConfig.url")

Comment 10

[tagnaq]

Hi ben,

thanks for your help!

(In reply to Ben Bucksch (:BenB) from comment #6)
> Policy:
> tagnaq, is only the email address a problem or the mere request via HTTP?

The mere request (actually its response) is a "problem" (or just not useful if you don't trust configs fetched via plain HTTP).

So a 'forceHTTPS' pref would be of use in the TorBirdy context. In that case we don't mind submitting the email address.

If there will be no such thing as 'forceHTTPS' for the ISP fetch, then we are still happy to use 'fetchFromISP.enabled = false' to skip the insecure HTTP fetch - while still using Mozilla's ISPDB.

btw: I also commented on your trac entry, but I guess we should continue here until something got merged.

Comment 11

[Ben Bucksch (:BenB)]

bwinton, can I have a review, please? I need this commited before I can work on bug 917347, because they'll conflict on a code level.

Comment 12

[Blake Winton (:bwinton) (:☕️)]

Comment on attachment 8372645 [details] [diff] [review]
Prefs to disable ISP fetch, email address transmission, and guess config

Review of attachment 8372645 [details] [diff] [review]:
-----------------------------------------------------------------

The code seems fine to me.  I am (as ever) disappointed with the lack of tests.
As long as this passes all our existing tests, and you fix the nits Magnus mentioned, r=me.

Comment 13

[Ben Bucksch (:BenB)]

Pushed to try:
https://tbpl.mozilla.org/?tree=Thunderbird-Try&rev=801651fb2705
https://ftp-ssl.mozilla.org/pub/mozilla.org/thunderbird/try-builds/[e-mail]-801651fb2705

Comment 14

[Ben Bucksch (:BenB)]

Test result:
https://tbpl.mozilla.org/php/getParsedLog.php?id=34578575&tree=Thunderbird-Try#error0
The errors are spurious, because https://tbpl.mozilla.org/?tree=Thunderbird-Try&rev=2b346bf250f2 got the same errors
So, that's test PASS I guess.

Comment 15

[Ben Bucksch (:BenB)]

Commited as https://hg.mozilla.org/comm-central/rev/12401af31c63

FIXED

Comment 16

[Ben Bucksch (:BenB)]

(FWIW, I found the perfect color of the bikeshed: sendEmailAddress instead of emailAddressEnabled. Satisfies both mine and mkmelin's logic.)

The new prefs are:

// Allow to contact ISP (email address domain)
// This happens via insecure means (HTTP), so the config cannot be trusted,
// and also contains the email address
pref("mailnews.auto_config.fetchFromISP.enabled", true);
// Allow the fetch from ISP via HTTP, but not the email address
pref("mailnews.auto_config.fetchFromISP.sendEmailAddress", true);
pref("mailnews.auto_config.guess.enabled", true);

Comment 17

[:aceman]

(In reply to Ben Bucksch (:BenB) from comment #11)
> bwinton, can I have a review, please? I need this commited before I can work
> on bug 917347, because they'll conflict on a code level.

Is the bug number right? That bug does not seem related in any way.

Comment 18

[Ben Bucksch (:BenB)]

aceman, that was a typo. Correct is: bug 971347.