Closed Bug 986967 Opened 10 years ago Closed 7 months ago

autoconfig mechanism should use HTTPS URLs

Categories

(Thunderbird :: Security, defect)

Product:
Thunderbird
Component:
Security
Version:
6 Branch
Type:
defect

Tracking

(thunderbird61? affected)

Status:
RESOLVED INVALID
Tracking Flags:
Tracking Status
thunderbird61 ? affected

People

(Reporter: Ralf-mozilla.org, Unassigned)

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:28.0) Gecko/20100101 Firefox/28.0 (Beta/Release)
Build ID: 20140314220517

Steps to reproduce:

Created an account in TB, referring to an existing account on an IMAP server.


Actual results:

Noticed that Thunderbird used HTTP to retrieve the autoconfig XML file.


Expected results:

Thunderbird should have used HTTPS to retrieve the autoconfig XML file for security reasons, otherwise attackers could modify the XML file in an MITM attack and trick users to sending their credentials to a host under control of the attacker.
This bug affects all operating systems and versions.

I checked with users who are not system administrators and software developers whether they verify the configuration discovered via autoconfig. Nobody could remember that they did. However, all users were happy that setting up an email account was as easy as typing the email address and password and that they don't need help from other people to configure their MUA.

Since Thunderbird allowed HTTP and would have to fall back to HTTP. So if Thunderbird would introduce a version 2 of the autoconfig mechanism, it would have to support version 1.1 for some time. An attacker could terminate the version request 2 that is made over HTTPS and Thunderbird would have to fall back to version 1.1 to be backwards compatible. Version 1.1 hosts do not have to support HTTPS, so fetching https://autoconfig.example.com/mail/config-v2.0.xml?emailaddress=fred@example.com or http://example.com/.well-known/autoconfig/mail/config-v2.0.xml and only falling back if the request returns a 404 error is not possible.

As far as I see it the only backwards compatible way to implement autoconfig over HTTPS is to rely on DNSSEC. So either you introduce a new well-known subdomain, such as autoconfig2.example.com or secure-autoconfig.example.com, or an additional TXT record that indicates that HTTPS is supported.

Of course Mozilla's ISPDB is not affected by this because it is hard-coded that it is delivered via HTTPS.
I would be happy to provide a trivial patch to fix the issue and dissable http for autoconfig. Perhaps somebody at Mozilla can make a decision on the possible alternatives that I outlined.
(In reply to Matthias-Christian Ott from comment #2)
> I would be happy to provide a trivial patch to fix the issue and dissable
> http for autoconfig. Perhaps somebody at Mozilla can make a decision on the
> possible alternatives that I outlined.

So you are proposing to take the existing auto config, and just switch it over to require https? That does not seem like a very good solution to me if it breaks all existing autoconfigs.

Could I have a little more overview here of the current status? Does the current autoconfig allow https? Have there been previous discussions of requiring https?

I can certainly see the argument of why autoconfig should require https.
We migrated to https-only (closed port 80 https://twitter.com/lgarron/status/804820053321334785). There is no fallback. IMAP/SMTP host/ports are incorrect. There is a need for this. Please do a fallback to https:// at least.
Flags: needinfo?(acelists)
Can the attacker fake the answer (with a fake file) via http even when your server does not respond on port 80 ?
Flags: needinfo?(acelists)
So what would be gained by checking http first, then fallback to https?
Thunderbird should have a secure autoconfig mechanism like Outlook.

https://dxr.mozilla.org/comm-central/rev/0dcc75169b104cd5c05c36befbfb16c159646f8c/mail/components/accountcreation/content/fetchConfig.js#66-69
Both http:// should be replaced with https://. That would be the desired fix, I think. An https-only XMLHttpRequest.
Status: UNCONFIRMED → NEW
status-thunderbird61: --- → affected
tracking-thunderbird61: --- → ?
Ever confirmed: true
OS: Mac OS X → All
Hardware: x86 → All
This has been discussed to death in other bugs. Other ISPs need http, because they can't put up certificates for every single domain customer, and only for autoconfig.

Even if we used only https, an attacker would still be able to block https connections, and we'd fall back to guessing (which we absolutely need, because half of the TB user accounts are on small domains without autoconfig), and guessing is vulnerable to the same problem. And many corporate mail servers are not on SSL, because they are on internal networks.

Compare bug 342242 comment 59 for a user asking of the exact opposite. The mitigations he lists are not coincidental, but were put in place very deliberately, exactly to avoid a security problem.
(In reply to Ben Bucksch (:BenB) from comment #10)
> Other ISPs need http, because they can't put up certificates for every single domain customer, and only for autoconfig.

Customer domains are https:// thanks to Let's Encrypt anyway.

> Even if we used only https, an attacker would still be able to block https connections, and we'd fall back to guessing (which we absolutely need,

No fallback. Art. 25 EU GDPR (Data protection by design and by default: https://gdpr-info.eu/art-25-gdpr/)

> because half of the TB user accounts are on small domains without autoconfig),

Then no fallback is needed.

> and guessing is vulnerable to the same problem.

If guessing would leak the username (email address) then it should be offered as button and not automatically run.

> And many corporate mail servers are not on SSL, because they are on internal networks.

There is a wisdom called "don't trust networks". They would have a corporate CA in this case anyway. Otherwise they could could use a local config file as one could do for Outlook.

> Compare bug 342242 comment 59 for a user asking of the exact opposite.

The user would like to have a solution via DNS.
* For a corporate network, it would be up to the sysadmin to configure a dnssec-capable resolver. If they really trust the path between dns server, dns resolver and client, then it may be fine without dnssec.
* For a consumer, it would be up to the ISP to have a dnssec-captable resolver if Thunderbird couldn't verify by itself.
* Yes, there are trust problems, that's why https (Mozilla's trust store, OCSP, Certificate Transparency) would be better for the moment. Currently, the http:// XMLHttpRequest is upgraded to https thanks to https://hstspreload.org, but that take months for a new registered domain and wouldn't protect an intial Thunderbird configuration.
(Sorry: I assumed you mean fallback to http and then to guessing.)
As long guessing really only tests imap.<domain>, smtp.<domain>, mail.<domain> with STARTTLS and SSL/TLS and not via plaintext, it would be fine. Self-signed certs would cause a warning, I assume.
> > many corporate mail servers are not on SSL, because they are on internal networks.
> There is a wisdom called "don't trust networks". They would have a corporate CA in this case anyway.

We're not dealing with a world as it should be, but as it is. Fact is that most of our users use are not 100% SSL.
We can't just unsupport them all, just because you think that's safer.

If we do what you propose, we'd essentially kill the config of half of our userbase. Not going to happen.

You're not telling anything new. As mentioned before, there are many other mitigating factors that prevent an attacker from silently exploiting this. We deliberately put these safeguards in.

This isn't a problem that people have in the real world. The real world problems are phishing mails and malware attachments. If you want to improve information security, maybe you can suggest ideas about that.

WONTFIX
(In reply to Ben Bucksch (:BenB) from comment #14)
> > > many corporate mail servers are not on SSL, because they are on internal networks.
> > There is a wisdom called "don't trust networks". They would have a corporate CA in this case anyway.
> 
> We're not dealing with a world as it should be, but as it is. Fact is that most of our users use are not 100% SSL.

Yeah, understandable.
The other perspective: A regular user shouldn't suffer from (in)security requirements of corporations that have other precautions. A checkbox "Allow insecure autoconfiguration" and/or a pref might be a comfortable solution that is secure by default.

> You're not telling anything new. As mentioned before, there are many other mitigating factors that prevent an attacker from silently exploiting this.

It takes about three months to be HSTS Preloaded (https://hstspreload.org) in a stable browser release. Thunderbird takes further months.
An http:// autoconfiguration process of a freshly registered domain can be intercepted and a non-TLS configuration can be suggested to the unaware user.

https://developer.mozilla.org/en-US/docs/Mozilla/Thunderbird/Autoconfiguration/FileFormat/HowTo#Configuration_file_format
> <socketType>plain</socketType>

https://developer.mozilla.org/en-US/docs/Mozilla/Thunderbird/Autoconfiguration/FileFormat/HowTo#Use_SSL
>  In fact, even most freemail (!) providers these days support SSL, so if users pay you money for ISP service, that's all the more reason to give them proper service.

https://www.hardenize.com/report/perfektesgewicht.de
Our german club members aren't even able to use autoconfiguration as long their domain is not HSTS Preloaded and shipped with a Thunderbird update. Article 25 EU GDPR "Data protection by design and by default" (https://gdpr-info.eu/art-25-gdpr/) implies that doing an autoconfiguration by default via http:// without other (effective) precautions is forbidden.

> problems are phishing mails and malware attachments.
Phishing: DKIM Verifier. Some mailing lists or newsletter provider have problems with it, so we can't just deny such mails.
But a mail client can display at least a positive "Verified Sender" badge (and via pref also neutral and negative states). Webmail interfaces are often doing something like that.

Malware: It's up to the mailserver to deny several mime types, but up to the client to show the real mime type. Thunderbird could try to detect if Windows is hiding file extensions and offer to change the configuration to show them. If a user wants to execute an exe inside a zip it's as if a car driver steers to the right and, as expected, races into a tree.

> If you want to improve information security, maybe you can suggest ideas about that.
Webextensions like uMatrix do not work for RSS Feeds, it's impossible to block 3rd party hosts. The (legacy) uBlock Origin did work in the past. That might be interesting when allowing third party images in an email as well.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
> we'd essentially kill the config of half of our userbase.

See comment 10 for rationale for WONTFIX.
Status: RESOLVED → UNCONFIRMED
Ever confirmed: false
Resolution: WONTFIX → ---
Status: UNCONFIRMED → NEW
Ever confirmed: true
We have just discovered this security vulnerability by checking the functioning of the autoconfiguration mechanism (as part of the YunoHost project).

We understand that it may be difficult to switch to HTTPS only since many email providers have now implemented this mechanism with HTTP. We also understand the complexity of implementing a certificate request only for email autoconfiguration.

If there is no real patch, wouldn't it be possible to change the message displayed to the user if the config.xml file is retrieved unsecured? For example, it would be possible to ask the user to check the information retrieved.

What do you think of that?
> it would be possible to ask the user to check the information retrieved.

We already ask the user to confirm the configuration.
See also comment 10.
I fear most users just accept anything as long it's not too suspicious and no error is shown.

As far as I understand Thunderbird's behaviour right, the account wizard always checks

For several reasons discussed in this thread it's required to check for the autoconfig file over a http connection.

But what about to order the requests? First connect only over https and stop if Thunderbird gets an complete answer with all autoconfig information. In this case it's not required to test over http anymore and no email address will be leaked over an unencrypted connection.

Severity: normal → S3

We're using HTTPS now, where possible.

Status: NEW → RESOLVED
Closed: 6 years ago → 7 months ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.