1594372 - account setup should not send email address as parameter when over plain http

Status: NEW

(Thunderbird :: Account Manager, defect)

Description

[Magnus Melin [:mkmelin]]

Account setup is sending the email as parameter over plain http too. I think we should not. If the configuration needs the email address people can have an https setup for that server.

https://searchfox.org/comm-central/rev/41db3d110be306f546940455eb03d5982b0fa163/mail/components/accountcreation/content/fetchConfig.js#92-103

Possibly there should be a preference that organizations could turn on to still send it.

Comment 1

[alta88]

Attachment: sslOnly.patch

There are prefs already, they just must not default to use insecure http.

Comment 2

[Ben Bucksch (:BenB)]

Comment on attachment 9107199 [details] [diff] [review]
sslOnly.patch

This cannot land. This will break the entire mechanism. This argument is not new and has been discussed to *death*.
You have the justification right there in the code you modify, but you chose to ignore it.
Changing "Most" to "Maybe" in the comment doesn't change reality of what is deployed. Changing code comment doesn't change Internet protocols.

Comment 3

[Magnus Melin [:mkmelin]]

Let's focus on the bug as reported. I think it's reasonable not to send the actual email when over plain http. Probably that's not so much used anyway. For the cases where someone would use it, that organization should be large enough to stand up https.

Comment 4

[alta88]

This code is so poor it will send to http even if https is found. If one were designing a way to harvest emails, this is how it would be done.

I'll leave it to you magnus to make sure this is fixed. But if it isn't fixed, and soon, I will publicize it elsewhere; maybe a security firm will be interested in an audit and can explain best practices.

Comment 5

[Ben Bucksch (:BenB)]

If one were designing a way to harvest emails, this is how it would be done.

First off, please distinguish between "emails" (contents) and "email addresses" (what you tell others to contact you). These are completely different things.

a) Given that we're contacting your email provider, and it surely has not only your email address, but your mail contents, you must be mis-trusting your ISP? Even with your email address? If you have this little trust in your ISP, why don't you use a VPN? You understand that email addresses are typically public information, and your ISP has much more private information on you (including which websites you visit, even if not the contents), right? And here, the ISP sees only the email address, not the contents. And this is a one-time action, when you set up the account. I don't see the "security" problem.

b) If we do not send the email address by HTTP, then this is solved.

What Magnus proposed in comment 3, I think that's a possible approach. However, this might break existing setups. We need some more data on that. But it could be feasible.

alta88, I would appreciate you stopping personal attacks ("code is so poor", although this has good reasons to be done like that), and threats ("if it isn't fixed, and soon, I will..."). They are not helpful for a decision based on reason.