824533 - [Gaia][Email] Socket Type in Manual configuration offers only one option (SSL)

Status: RESOLVED WORKSFORME

(Firefox OS Graveyard :: Gaia::E-Mail, defect)

Description

[Ralph Daub [:rdaub]]

ENVIRONMENT:
Unagi phone, build 12/23


STEPS to REPRO:
1. Go to Manual setup for adding a new email account
2. Tap on the Socket type combo box


EXPECTED:
Muitlple options displayed for Socket type


ACTUAL:
Only one option (SSL) is available

Comment 1

[Joe Cheng [:jcheng] (please needinfo)]

Triage: BB-, Commercial email services should all have SSL. Should not have real user impact unless on some very special servers

Comment 2

[Andrew Sutherland [:asuth] (he/him)]

As additional context, the combo-box exists so that when mozTCPSocket starts supporting StartTLS we can expose it.  (We will not be exposing a plaintext option to the UI, which is the other thing that could make sense.)

Comment 3

[Beatriz Rodríguez [:brg]]

This issue had been reported during certification process and real users are affected. They are asking for an option to allow to configure mail accounts without SSL.
Adding backlog tag to properly prioritize.

Comment 4

[Andrew Sutherland [:asuth] (he/him)]

(In reply to Beatriz Rodríguez [:brg] from comment #3)
> This issue had been reported during certification process and real users are
> affected. They are asking for an option to allow to configure mail accounts
> without SSL.
> Adding backlog tag to properly prioritize.

Are you asking for cleartext support (no encryption, port 143/110/25/587, anyone can sniff the traffic, etc.), or StartTLS support (upgrade to SSL/TLS from initial cleartext connection)?  Because we have StartTLS support.  This bug is arguably RESOLVED WORKSFORME already since it seems like the original concern was simply that there was a combobox with only one option and that's admittedly silly.


Assuming you're asking for cleartext, can you provide specific domains and what/how many users we are talking about?

During discussion of bug 874346 about invalid SSL certificates it was revealed that Telefonica uses a certification test lab, AT4 wireless, and that AT4 wireless uses invalid certificates (or an insufficiently specified certificate chain?) on their server at webmail.at4wireless.com (which seems to only be exposing ActiveSync and POP3 right now).

I'm wondering if this request is motivated as a workaround to the invalid certificate issue.  Because it's really not a valid workaround.  Ignoring the aspects of systemwide risk from insufficiently scoped certificate exceptions, not using any encryption introduces even more privacy leakage and new avenues of attack for people anywhere along the network path.  It's another instance where I think the right course of action is evangelism to server operators by talking with them and evangelism to users by helping them get a new account with a competent provider is a better course of action.  For example, gmail provides free accounts and takes user privacy and security seriously, whereas any mail server operator that does not provide SSL/TLS support with valid certificates arguably has no business running a mail server.

And gmail and many other providers would let the user migrate by automatically pulling the email from the user's server.  And arguably the server-to-server paths are "less" vulnerable than the last-hop network connection of the cellular network or wi-fi connection.

Comment 5

[Beatriz Rodríguez [:brg]]

(In reply to Andrew Sutherland [:asuth] from comment #4)
> (In reply to Beatriz Rodríguez [:brg] from comment #3)
> > This issue had been reported during certification process and real users are
> > affected. They are asking for an option to allow to configure mail accounts
> > without SSL.
> > Adding backlog tag to properly prioritize.
> 
> Are you asking for cleartext support (no encryption, port 143/110/25/587,
> anyone can sniff the traffic, etc.), or StartTLS support (upgrade to SSL/TLS
> from initial cleartext connection)?  Because we have StartTLS support.  This
> bug is arguably RESOLVED WORKSFORME already since it seems like the original
> concern was simply that there was a combobox with only one option and that's
> admittedly silly.
> 
We can close this bug as WFM and I can open a new one asking for cleartext support. Please let me know.
> 
> Assuming you're asking for cleartext, can you provide specific domains and
> what/how many users we are talking about?
This was reported during certification process in several countries(CO, GT, MX, NI, PA, PE, SV). Certification testing is done based in two main topics: operator services(calls, data, messaging..) and customer demands.
The only information in the test case is about the testing account they are using: [e-mail]. (The tester blames the lack of option to disable SSL for not being able to configure it)
We do not know how many other providers are using this configuration.
> 
> During discussion of bug 874346 about invalid SSL certificates it was
> revealed that Telefonica uses a certification test lab, AT4 wireless, and
> that AT4 wireless uses invalid certificates (or an insufficiently specified
> certificate chain?) on their server at webmail.at4wireless.com (which seems
> to only be exposing ActiveSync and POP3 right now).
> 
> I'm wondering if this request is motivated as a workaround to the invalid
> certificate issue.  
No. The requirement come from a different place.
> Because it's really not a valid workaround.  Ignoring
> the aspects of systemwide risk from insufficiently scoped certificate
> exceptions, not using any encryption introduces even more privacy leakage
> and new avenues of attack for people anywhere along the network path.  It's
> another instance where I think the right course of action is evangelism to
> server operators by talking with them and evangelism to users by helping
> them get a new account with a competent provider is a better course of
> action.  For example, gmail provides free accounts and takes user privacy
> and security seriously, whereas any mail server operator that does not
> provide SSL/TLS support with valid certificates arguably has no business
> running a mail server.
> 
> And gmail and many other providers would let the user migrate by
> automatically pulling the email from the user's server.  And arguably the
> server-to-server paths are "less" vulnerable than the last-hop network
> connection of the cellular network or wi-fi connection.
Yes, gmail configuration is also covered during certification testing and it is working fine.

There are other mail clients that allow this configuration.

Comment 6

[Andrew Sutherland [:asuth] (he/him)]

(In reply to Beatriz Rodríguez [:brg] from comment #5)
> We can close this bug as WFM and I can open a new one asking for cleartext
> support. Please let me know.

I'll resolve this WFM then.  Please file a new bug.

> This was reported during certification process in several countries(CO, GT,
> MX, NI, PA, PE, SV). Certification testing is done based in two main topics:
> operator services(calls, data, messaging..) and customer demands.
> The only information in the test case is about the testing account they are
> using: [e-mail]. (The tester blames the lack of option to disable SSL
> for not being able to configure it)

Ugh, so the vtr.net case really does appear to not support SSL/TLS on mail.vtr.net.  Even webmail.vtr.net doesn't support https.

Are all of those certification processes using the same [e-mail] account or others?  If it's possible to get info on any other specific domains in use (and ideally estimated user counts), that can help us gauge the scale of the problem.

> We do not know how many other providers are using this configuration.

I do understand this, but especially if it's felt in specific cases that this is a cert-blocker or anything equally significant, we will definitely need to know the domains that are the problems.

> There are other mail clients that allow this configuration.

Yes, that is true.  However it's very likely that the users using those clients don't realize that the security/privacy of their email accounts can be trivially compromised by an attacker when using a mobile device in such a fashion.  And compromising a user's email account can in turn lead to compromise of all of the accounts the user has that support password-resets via email or where email access can be parlayed into other forms of access, such as social engineering through control of the user's email account.

As an example, it appears the iOS mail client, at least for a time, would ask the user if they were okay without using SSL without explaining what SSL is or the risks posed to the user by not using SSL, etc: http://support.apple.com/kb/HT2155.  Given Mozilla's stance on user privacy and the like, any solution we would implement would need to be more extensive than simply letting the user choose such a ridiculously dangerous option without some level of education.

Comment 7

[Beatriz Rodríguez [:brg]]

New bug 1046799 open to track the request of cleartext support.