Open Bug 664633 Opened 13 years ago Updated 1 month ago

Improve privacy & security of Thunderbird account autoconfiguration

Categories

(Thunderbird :: Account Manager, defect)

Product:
Thunderbird
Component:
Account Manager
Type:
defect

Tracking

(Not tracked)

Status:
REOPENED

People

(Reporter: briansmith, Unassigned)

References

Details

(Keywords: privacy-review-needed, sec-moderate, Whiteboard: [sg:moderate]) 

Currently, Thunderbird asks the user for his email address, e.g. fred@example.com and password. 

Then, sends an http request to http://autoconfig.example.com/mail/config-v1.1.xml?emailaddress=fred@example.com. This is problematic because:

(1) The user's email address in sent in the clear, so it is vulnerable to passive attacks like Firesheep, and the response is unauthenticated, so it is vulnerable to active attacks that would allow an attacker to provide bogus configuration information that would allow the attacker to steal the user's credentials during the first attempted login. We should do this request over an authenticated channel.
(2) If the email service provider provides this per-user configuration information, then it may leak users' authentication usernames to attackers. (Attackers can do dictionary attacks for usernames). We should not encourage email providers to leak this information. 
(3). If the email service provider provides this per-user configuration information, then it will be leaking the validity of email addresses at that domain. (Attackers can do dictionary attacks for email addresses, to determine which ones are valid). We should not be encouraging email providers to leak this information.

Then, Thunderbird sends a request to http://autoconfig.example.com/mail/config-v1.1.xml. This has the same problem with unauthenticated data as the previous case.

Then, Thunderbird sends a request to https://live.mozillamessaging.com/autoconfig/v1.1/example.com. This is done so that the mozillamessaging.com server can look up the MX record for the domain and/or return configuration info from its configuration database. This leaks the user's domain name to the live.mozillamessaging.com server, and means that Thunderbird must trust the love.mozillamessaging.com server to provide accurate results. We should try the MX record lookup client-side first, and we should try to look up the configuration from a local copy of the configuration database. We should only fall back to sending the domain name to the mozillamessaging.com server when this local lookup fails. (Also, we don't yet have a way of validating the MX record's authenticity since we don't support DNSSEC and many email providers do not have DNSSEC signed records.) Since a local copy of the configuration database will have the correct information for the vast majority (Sid0 said ~95%) of cases, this would avoid leaking any info for the vast majority of users. IMO it makes sense to only do the request to mozillamessaging.com upon receiving permission from the user. (But, maybe this would be overkill.) Note that it is important to get as many users as possible to send their domain name to the mozillamessaging.com service when the auto-configuration fails, so that we can improve the auto-configuration.

Also, the auto-configuration database doesn't include any information about whether to expect a valid TLS certificate for the server. This would be very useful information to have because it would prevent MitM attacks that use invalid certificates. Basically, the auto-configuration database should include some kind of HSTS designation for the server.
Sorry, the 95% was a misunderstanding...
Bug 563958 is about doing the MX lookup from the client instead of trusting our server to do it.
Depends on: 563958
Sorry, but this is already FIXED. We already had a security review - several in fact. This was discussed long and in public, over years. See the archives of mozilla.dev.apps.thunderbird and
<https://wiki.mozilla.org/Security/Reviews/> ->
<https://wiki.mozilla.org/Firefox3.6/Security> ->
<https://wiki.mozilla.org/Thunderbird:Autoconfiguration:Security_review_FetchConfigFromISP>
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
The current implementation doesn't match the design that was reviewed, AFAICT.

See https://wiki.mozilla.org/Thunderbird:Autoconfiguration:Security_review_FetchConfigFromISP

In particular, "To retrieve configuration parameters, Thunderbird will use HTTP on a transport of SSL or on a transport of TLS. Thunderbird will abort the retrieval if the server presents an improper certificate. We chose this protocol over DNS, our choice being more secure than DNS is."

Also, the information leakage of the username and validity of an email address was not covered in the security review, AFAICT. And, AFAICT, I don't see any notes describing the privacy implications of leaking the uesr's domain name unnecessarily to the mozillamessaging.com server.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Did you also read "Mitigating factors"? Please consider these.

Also, please read the documents linked from the page, because I don't want to repeat it all.

Sorry to be annoyed, but you are not the first to "discover" this. As I said, we discussed this for *years*. Including almost all you said. There has to be an end of discussion some time.

I'll respond to some of the questions you raised, just for clarification.

> (1) The user's email address in sent in the clear

It was the full intent to use SSL, but it turned out to be simply *impossible* in practice. Domain hosters, which were one of important use cases for this mechanism, would need one SSL certificate per customer domain, and that is simply prohibitive, because 1) SSL certs cost money 2) have a process that needs to be followed to each customer domain and last but not least 3) need one IP address per domain, which runs totally against the virtual hosting that is industry practice. So, domain hosters told us that it's completely impossible to serve all their domains with config info, if we require SSL, for these reasons, and they are sound.
Basically, SSL is broken by design.

This was discussed in bugzilla, I can't find it anymore, though.

> it may leak users' authentication usernames to attackers

The service has to be able to return usernames, because there are a few big ISPs that need an IMAP username which is entirely unrelated to the email address. To support such accounts, the ISP must be able to return the username. There is no other way to set up the account, short of the user knowing the username, which is the whole problem we want to solve.
We do allow ISP provided configs to have placeholders and we fill in email address or its local part, and that is preferred.

> We should try the MX record lookup client-side first

I fully agree, and I think you can see that from the bugs (and the fact that I filed bug 563958, thanks for linking it). If you can help with its blocker bug 545866, that would be *highly* appreciated.

> (Also, we don't yet have a way of validating the MX record's
> authenticity since we don't support DNSSEC and many email providers
> do not have DNSSEC signed records.

Yes, we were aware of that also, and that's in fact arguing *for* a web-service. We can more easily spot an attack on the central web service than a specifically targetted user can spot an attack on him.

> we should try to look up the configuration from a local copy of the
> configuration database

This is a nice idea, I like the idea, but it has a problem: The configs can change. For example, mail.ru recently added SSL-capable servers. If you use the local config without checking against the server, you'd configure the non-SSL config and send plaintext passwords (!), because that was the only config we had before.

If you weight that (these users configuring plaintext passwords for many more months, sometimes years in the case of Debian release policy and companies' policies and many lazy non-updating users) against the concerns issued here, I hope you will conclude in favor of autoconfig as implemented.

---

All in all, I fully agree with your goals and notion, and that was the original intent, as you can see from the discussion. If there are security or privacy problems, then because we had no other realistic choice.
(In reply to comment #5)
> > (1) The user's email address in sent in the clear
> 
> It was the full intent to use SSL, but it turned out to be simply
> *impossible* in practice. Domain hosters, which were one of important use
> cases for this mechanism, would need one SSL certificate per customer
> domain

Not if they configure the same MX host for every server and we perform an autoconfig lookup at the host. It is also theoretically possible to 
 
> 3) need one IP address per domain

Not with SNI, which NSS supports.

> 
> This is a nice idea, I like the idea, but it has a problem: The configs can
> change. For example, mail.ru recently added SSL-capable servers. If you use
> the local config without checking against the server, you'd configure the
> non-SSL config and send plaintext passwords (!), because that was the only
> config we had before.

Periodic incremental updates + bug 664636 should ameliorate this.
s/It is also theoretically possible to //
> Not if they configure the same MX host for every server

Yes, but that isn't the case. They often use the customer domain name

> Not with SNI

Fine, but the other 2 problems still persist, and each of them is prohibitive.
(In reply to Ben Bucksch (:BenB) from comment #5)
> Did you also read "Mitigating factors"? Please consider these.

The mitigating factors seem somewhat out of date now. Secure email protocols are significantly more common now than they were in 2009. In this context, weak autoconf is no longer just another unencrypted piece in an unencrypted chain, but presents a weakness in an otherwise potentially secure system. Might it be worth reconsidering the security tradeoff in light of this development?
Do we need to keep this open ?
(In reply to Ludovic Hirlimann [:Usul] from comment #11)
> Do we need to keep this open ?

Is the issue resolved?
Yes.
Status: REOPENED → RESOLVED
Closed: 13 years ago → 13 years ago
Resolution: --- → WONTFIX
somebody else than me please close this.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Status: REOPENED → RESOLVED
Closed: 13 years ago → 12 years ago
Resolution: --- → FIXED
I cannot find the notes from the new security review that was done when Curtis marked the security review complete on 2011-10-12. Where are the notes?
I don't believe a full review was done on this bug, and my process for dealing with bugs was pretty new at the time so sorry for the lack of notes.

This may have been discussed during the account provisioning discussion (https://wiki.mozilla.org/Security/Reviews/Firefox7/ReviewNotes/AcctProvis) but there are no notes about this bug.

I don't recall this bug particularly, and the dates are during the email/calendar loss. I think we may have marked this complete during a triage meeting and decided no further look at this was warranted and thus marked it complete. And the minutes from that meeting are also lost to the email black hole.
I think we should leave this open until it's confirmed that we have fixed it, or accepted the current status, and Brian and I both know what's up with it. Does that seem reasonable?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Based on comments 15 - 17, re-requesting security review so we can lead this to a resolution one way or another.
Keywords: sec-review-complete → sec-review-needed
Whiteboard: [sg:high] → [sg:moderate]
Talked this over with Sid and he feels the best way to resolve any lingering items is to have a public discussion on dev-planning and/or other appropriate lists. This is more a privacy item than a security item in our opinion. The previous privacy review for this can be found at:

https://wiki.mozilla.org/Privacy/Reviews/AccountProvisioner
:benb yes, however comment 18 a re-review was requested due to other comments. We don't feel a re-review is warranted and that further public discussion can resolve the outstanding issues. If the community does not fell strongly that there is an issue with what has been raised I think we can move on.
Personally, I'd much rather have a formal meeting than an open-ended newsgroup discussion. The meeting costs me 1h, while a newsgroup discussion typically eats 4-8h (reading, responding etc, over a week).
FWIW, from my POV, the biggest problems, and their causes are:
* Fact: Domain hosters, and large ISPs hosting other smaller ISPs, don't / can't affort one SSL cert per customers. Thus, hostname mismatches are commonplace, mail.davidbienvenu.org has mail.dreamhost.com as hostname in the SSL cert. If we have to guess the config, we can only guess mail.davidbienvenu.org, not mail.dreamhost.com.
* Decision: Thus, we must allow the user to override a hostname mismatch. (See bug 721369 for some discussion.)
* Decision: Thus, we cannot enforce SSL when fetching a config from a domain hoster as we intended. https://davidbienvenu.org/.../config.xml is not possible, because dreamhost won't have an SSL cert for davidbienvenu.org.
* Fact: We can't know the hoster of a customer domain like davidbienvenu.org. The only for us to guess it is to look at DNS MX for the domain, and take the domain of the MX server. However, DNS is (currently, without DNSSEC) unprotected, so *everything* that follows based on that hoster is insecure.
* Decision: In order to support many important hosters, we do the MX lookup and then try to find the config for the hoster. E.g. if 
https://live.mozillamessaging.com/autoconfig/v1.1/davidbienvenu.org
doesn't exist, we look up
davidbienvenu.org.      14400   IN      MX      0 mx1.sub4.homie.mail.dreamhost.com.
and take the SLD of that, and look up
https://live.mozillamessaging.com/autoconfig/v1.1/dreamhost.com
which then often does exist (not in this case, but in others, e.g. gmail)
It's worth noting that we're planning to use the Thunderbird autoconfig mechanism in the B2G e-mail client, so having another discussion could be fruitful, especially in that potentially enlarged context.

I think the key changes between the last discussion and now, at least as it relates to B2G are:

- The last time we had the discussion, I don't think there were free SSL certs.  StartCom now appears to provide free (simple, one-host) certs:
http://www.startssl.com/?app=1

- In principal, we can issue TXT and SRV queries over DNS-over-TCP by using the node-dns library shimmed to use our new WebTCP API (or privileged chrome TCP api wrapper like instantbird's socket.jsm) to do client-side resolutions.  (There is also ongoing work to make the platform provide this, but it's not here yet.)
I've been attaching a patch that allows to disable the non-SSL HTTP calls per hidden pref.
... to bug 669282.
Depends on: 669282, 971347
Severity: normal → S3
Summary: Improve privacy & security of Thunderbird account auto-configuration → Improve privacy & security of Thunderbird account autoconfiguration
You need to log in before you can comment on or make changes to this bug.