sync-1 Reporter
	Description • 11 years ago

AU_LINUX_GECKO_ICS_STRAWBERRY_V1.01.00.01.019.111
 Firefox os  v1.0.1
 Mozilla build ID:20130518070208
 
 
 +++ This bug was initially created as a clone of Bug #456536 +++
 
 Description: Email client refuses to connect to an exchange server that it deems is invalid.
 
 Email client refuses to connect to an exchange server that it deems is invalid.It displays a message and refuses to go any further. This is a major limitation for Microsoft Exchaneg protocol since many exchange servers have a self signed certificate or a certificate for a slightly different domain name.
 
 Customer Impact Statement: This will prevent many users from accessing their work email via thios phone.
 
 Expected Behaviour: If used with a server that has what it deems to be an invalid server certifcate the handset should warn the user and allow them to continue like on all other devices.
 
 
  DEFECT DESCRIPTION:
 
  REPRODUCING PROCEDURES:
 
  EXPECTED BEHAVIOUR:
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:
 
  For FT PR, Please list reference mobile's behavior:
 
 ++++++++++ end of initial bug #456536 description ++++++++++
 
 
 
 CONTACT INFO (Name,Phone number):
 
  DEFECT DESCRIPTION:
 
  REPRODUCING PROCEDURES:
 
  EXPECTED BEHAVIOUR:
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:
 
  For FT PR, Please list reference mobile's behavior:

	Kai-Chih Hu [:khu]
	Comment 1 • 11 years ago

So, it looks like it does not provide a good warning, and you're suggesting that it should be able to handle this kind of situation, right?

	Andrew Sutherland [:asuth] (he/him)
	Comment 2 • 11 years ago

This bug keeps getting filed in various guises. See bug 850535 and bug 847282.  Bug 855569 started out similarly but we changed it to improving our error message instead.  Now instead of saying we can't connect to the server, we say there's a security problem with the server.  We have more detailed error codes than that, so we could provide a better string.  In bug 855569 I was trying to avoid introducing too many new strings, which is why there's just the one.

See https://wiki.mozilla.org/Gaia/Email/Features#Security for our current policy for supporting self-signed certificates.

In the case of the domain name slightly differing from the certificate, the user should be able to address that problem by using the manual setup process, and/or we can add an entry in the (Thunderbird) ISP database with the correct settings for the server.

	Daniel Coloma:dcoloma
	Comment 3 • 11 years ago

I think there are two different parts here:

1/ Do we allow user to connect to servers that have invalid certificates? I think here the position has been not to allow it so I have doubts on whether this is something to be fixed or not.
2/ CAn we provide more detailed information about the exact security issue? This could be maybe a leo improvement.

	sync-1 Reporter
	Comment 4 • 11 years ago

________________________________________
 Andreas Utrap <wenzeland>, 21.05.2013:  The comments in the wiki.mozilla.org
 link state that importing self-signed certificates is now supported by Firefox
 OS, however it needs to be done through the web browsesr or through settings.
 This leaves us with two questions:
 a) Is importing self-signed certificates through the web-browser or through the
 settings app supported in Firefox OS 1.0.1 and thus in svn010-02?
 b) If the anser to a) is "yes", can you provide a procedure describing how to
 import a self-signed certificate for ActiveSync and for HTTPS web sites?

	Alex Keybl [:akeybl]
	Comment 5 • 11 years ago

Out of scope for v1.0.1 at this point.

mluna - are you the right person to get a support article up about this?

	Andrew Sutherland [:asuth] (he/him)
	Comment 6 • 11 years ago

(In reply to sync-1 from comment #4)
> ________________________________________
>  Andreas Utrap <wenzeland>, 21.05.2013:  The comments in the wiki.mozilla.org
>  link state that importing self-signed certificates is now supported by
> Firefox
>  OS, however it needs to be done through the web browsesr or through
> settings.
>  This leaves us with two questions:
>  a) Is importing self-signed certificates through the web-browser or through
> the
>  settings app supported in Firefox OS 1.0.1 and thus in svn010-02?
>  b) If the anser to a) is "yes", can you provide a procedure describing how
> to
>  import a self-signed certificate for ActiveSync and for HTTPS web sites?

Bug 846734 implemented the certificate exception.  It is currently marked wontfix for v1.0.1, fixed for v1-train and master.

The procedure, as I understand it, is to go to a website with a bad certificate and add an exception.

	clwu
	Comment 7 • 11 years ago

we need fix it on V1.1.
Thanks.

	Andrew Sutherland [:asuth] (he/him)
	Comment 8 • 11 years ago

(In reply to clwu from comment #7)
> we need fix it on V1.1.
> Thanks.

Can you elaborate on why this needs to be fixed?

If you've identified specific Exchange servers using self-signed certificates, the best course of action would be to contact the operators of those servers and encourage them to acquire proper certificates.  Prices start at free for acquiring such a certificate.

If you've identified servers using valid certificates but for which the domain names aren't lining up right, the workaround is to use manual setup, but there are also a large number of options for adding autoconfiguration entries to allow the non-manual setup to work.

	Cheng-An, XIONG
	Comment 9 • 11 years ago

(In reply to Andrew Sutherland (:asuth) from comment #8)
> (In reply to clwu from comment #7)
> > we need fix it on V1.1.
> > Thanks.
> 
> Can you elaborate on why this needs to be fixed?
> 
> If you've identified specific Exchange servers using self-signed
> certificates, the best course of action would be to contact the operators of
> those servers and encourage them to acquire proper certificates.  Prices
> start at free for acquiring such a certificate.
> 
> If you've identified servers using valid certificates but for which the
> domain names aren't lining up right, the workaround is to use manual setup,
> but there are also a large number of options for adding autoconfiguration
> entries to allow the non-manual setup to work.

It's clearly described in the bug description with DT's expectation:

a refuses to go any further prevent users from accessing their work email via FFOS phone.

Expectation: If server has an invalid server certificate the handset should warn the user and allow them to continue like on all other devices.

	Andrew Overholt [:overholt]
	Comment 10 • 11 years ago

This seems like a new feature and 1.1 is past feature freeze.

	Andrew Sutherland [:asuth] (he/him)
	Comment 11 • 11 years ago

(In reply to Cheng-An, XIONG from comment #9)
> It's clearly described in the bug description with DT's expectation:

Two distinctly different problems are described:

1) Self-signed certificates are in use which NSS will never validate without adding a certificate exception.

2) The server possesses a valid certificate for one of the domains the server is reachable by, but the autoconfiguration logic ends up using a different domain name.

These are very different problems.  We can address case 2 by potentially improving the autoconfiguration logic, adding locale autoconfig entries to the e-mail app, or adding autoconfig entries to the ISP Database.  These are comparatively simple operations and do not really impact the device's attack tree.


Case 1 can be addressed in a number of ways, roughly in order of decreasing desirability:

- Evangelize to the operators of the servers using self-signed certificates about the benefits of using valid certificates which can be obtained for FREE or cheap.

- Given a set of known servers that use self-signed certificates, pre-populate the exception database for the domains, effectively pinning the certificate.

- Augment the ISP database to (either statically or dynamically) return entries that indicate the given server is known to use a self-signed certificate and have it provide the value of that key.  If such an entry is returned, provide a UX mechanism from the e-mail app to trigger the system app to add an exception.

- Always provide a way to trigger the system app to add an exception when creating the account.  But not after the account is created.  In the event a self-signed certificate is used and rotated out, deleting the account and re-creating it would be required.

- Always provide a way to trigger the system app to add an exception, even if the certificate changes under the user.
 

> a refuses to go any further prevent users from accessing their work email
> via FFOS phone.

I think some words got left out here, but I think I get the general idea.  I'm parsing this as "We want all users to be able to get to their e-mail."  And that's something I think we all agree on.

My concern, which is hopefully shared by others, continues to be that a server operator that does not have a valid SSL certificate is effectively indistinguishable from an attacker to our device.  And we expect our devices to be used in situations where attackers are both likely and possible: hostile wi-fi networks run by attackers, poorly configured/secured wi-fi networks that have become hostile networks after being attacked, fake cell towers (as mentioned at a presentation at DT), etc.

So when we allow invalid certificates to be used, we are opening up a new point of potential attack against all users on the device, especially those that correctly conform to the (currently free!) security mechanism in place for the internet for the past ~16 years.

Primary implementation concerns are:

- Users tend to click through things, including security warnings, without fully or partially stopping to understand the ramifications of what they are doing.

- It is my understanding that on Gecko devices right now, certificate exceptions are stored on a global basis.  That is why the workaround of having the web browser browse to a site to cause a certificate exception to be added works in the e-mail app.  The flip side of this means that an attacker could potentially use the e-mail app to facilitate adding a certificate exception that would allow them to effectively man-in-the-middle attack the user's browser for a secure site.  This is a real and serious concern because our autoconfig mechanism intentionally allows us to end up using different domain names than the domain name the user entered for their e-mail address.  There are steps in this process that an attacker could easily take control of.  These are known and understood (but not desired) aspects of the threat profile of autoconfig account setup that become potentially much more serious when facilitated certificate exceptions become a thing.


What the right course of action is to meet our goal of enabling all users access to their e-mail depends a lot on the data surrounding how many providers are using self-signed certificates, what domains their servers are hosted at, what sites their certificates are authorized for, what the expiration dates of their certificates are (are they already expired), whether someone has tried to contact the server operators to assist them in improving the security of their users, etc.

It seems like whoever is driving this expectation should have data along these lines.  It would be extremely useful to be able to look at this data so we can (all, together) determine the appropriate decisions to make in terms of implementation effort, UX trade-offs, security risk, etc.

Can you provide us with that data?

	Andrew Sutherland [:asuth] (he/him)
	Comment 13 • 11 years ago

One data-point: on bug 894833 (reported via the same sync-1@bugzilla.tld mechanism) which I just duped to here, the domain name in question involving certificate chains that could not be resolved was "mailsh.tct.tcl.com". (Note: the first thing is T C T, not T C L; my brain has real trouble with that.)

I understand from the public announcement at https://blog.mozilla.org/blog/2013/02/24/mozilla-unlocks-the-power-of-the-web-on-mobile-with-firefox-os/ that TCL is working with Mozilla on Firefox OS devices.  I think this is therefore an example of a case where evangelism with the operator of the site should be particularly possible.

	Jack Liu
	Comment 14 • 11 years ago

Dear Mozilla colleagues, I know browser supports self-signed websites now, why can't email app support self-signed mail server?

	Andrew Sutherland [:asuth] (he/him)
	Comment 15 • 11 years ago

(In reply to Jack Liu from comment #14)
> Dear Mozilla colleagues, I know browser supports self-signed websites now,
> why can't email app support self-signed mail server?

Please see comment 11.

	wes.frazier
	Comment 17 • 11 years ago

I appear to suffering under this bug over IMAP to my dreamhost server. Dreamhost's SSL certificate do not entirely match the propper subdomain of many of it's email clusters. http://wiki.dreamhost.com/Certificate_Domain_Mismatch_Error 

"Some mail programs will still reject the subX domains as the asterisk (*) in the certificate's *.mail.dreamhost.com should only match one level of subdomain."

	Andrew Sutherland [:asuth] (he/him)
	Comment 18 • 11 years ago

(In reply to wes.frazier from comment #17)
> I appear to suffering under this bug over IMAP to my dreamhost server.
> Dreamhost's SSL certificate do not entirely match the propper subdomain of
> many of it's email clusters.
> http://wiki.dreamhost.com/Certificate_Domain_Mismatch_Error 
> 
> "Some mail programs will still reject the subX domains as the asterisk (*)
> in the certificate's *.mail.dreamhost.com should only match one level of
> subdomain."

Dreamhost domains work; there are shorter aliases available.  The easiest way to find them is to do a reverse-lookup for the IP address of the mail-server (including your personal domain) to get the canonical FOO.mail.dreamhost.com domain name.

For example:
> dig mail.asutherland.org
mail.asutherland.org.	14400	IN	A	208.97.132.231

> dig -x 208.97.132.231
231.132.97.208.in-addr.arpa. 13813 IN	PTR	sub4.mail.dreamhost.com.

So for the entries on the wiki page, we get the following mappings:
* homiemail-sub3 => sub3.mail.dreamhost.com
* homiemail-sub4 => sub4.mail.dreamhost.com
* homiemail-sub5 => sub5.mail.dreamhost.com
* homiemail-master => homie.mail.dreamhost.com

For additional context for dreamhost certificates, please see:
https://bugzilla.mozilla.org/show_bug.cgi?id=671961#c8
http://www.dreamhoststatus.com/2013/06/26/secure-certificate-changes-coming-for-smtp-on-all-mail-clusters-on-june-27th-230pm-pst/
http://www.dreamhoststatus.com/2013/05/09/secure-certificate-changes-coming-for-imap-and-pop-on-homiemail-sub4-and-homiemail-sub5-email-clusters-on-may-14th/

	wes.frazier
	Comment 19 • 11 years ago

(In reply to Andrew Sutherland (:asuth) from comment #18)

Thank you very much. Dreamhost's support team could not give me such information, and as you can see their Wiki is of no help. I think I will be changing hosts down the road, but thank you! I can get into my email on the ZTE Open now!

	Kadir Topal [:atopal]
	Comment 21 • 10 years ago

Andrew, have we taken any steps as laid out in #comment 11? Is there a a roadmap for how we want to go about that?

While I understand the underlying issue of accepting self-signed certs, I'm wondering if that is something we want to *and* can fix with Firefox OS, or if it's hurting adoption with no chance of changing the status-quo of self-signed certs in general.

	berwe2501
	Comment 22 • 10 years ago

Just a comment from a relatively new user of FFOS and long-time user of Thunderbird and other IMAP clients:
I understand the comments regarding security and desired configurations of mail service providers stated above. However, all the mail clients I've used so far worked with self-signed certificates and it is a source of great frustration to me, not to be able to do this in FFOS. This is especially so, because in my (and probably everyone else's) view, Thunderbird and FFOS come from the same source and behave so differently.
If there is a way to implement the feature such that the user can make a transparent choice without creating an overall security risk in FFOS, I would very much appreciate, if it were to be done.

	Andrew Sutherland [:asuth] (he/him)
	Comment 23 • 10 years ago

(In reply to Kadir Topal [:atopal] from comment #21)
> Andrew, have we taken any steps as laid out in #comment 11? Is there a a
> roadmap for how we want to go about that?

No work is being done in this area that I'm aware of, but this is primarily a WebAPI/standards and system/platform/security issue, so I'm not totally in the loop.

> While I understand the underlying issue of accepting self-signed certs, I'm
> wondering if that is something we want to *and* can fix with Firefox OS, or
> if it's hurting adoption with no chance of changing the status-quo of
> self-signed certs in general.

I would not expect the Firefox OS e-mail app to be a driving force in getting server operators who have managed to avoid having valid certificates for this long to get them now.  (Which is not to say there has not been progress overall; Dreamhost's conversion from using their own made-up CA to a valid CA-chain is a relatively recent and a huge change.  It also has nothing to do with the Gaia E-mail client.)


Elaborating more on the bottom of comment 11, there is an inherent prioritization of all work on the e-mail app and the Firefox OS system.  If there is data that says there is a significant set of existing Firefox OS device owners or potential Firefox OS device owners who are unable to use the e-mail client because of certificate problems and the mitigations/alternatives described in comment 11 are not viable then this would greatly increase the priority of addressing our inability to add certificate exceptions.  We don't have any data that says that right now, so our focus is going to be on implementing missing core e-mail app functionality and addressing bugs/correctness issues.

If anyone is willing and able to get data like that so we can make better informed prioritization decisions, it would be appreciated.

	Kadir Topal [:atopal]
	Comment 24 • 10 years ago

Thanks for the clarification, Andrew. Just wanted comment on one aspect of this:

(In reply to Andrew Sutherland (:asuth) from comment #23)
> If
> there is data that says there is a significant set of existing Firefox OS
> device owners or potential Firefox OS device owners who are unable to use
> the e-mail client because of certificate problems and the
> mitigations/alternatives described in comment 11 are not viable then this
> would greatly increase the priority of addressing our inability to add
> certificate exceptions.  We don't have any data that says that right now

I think this is a false dichotomy. The question is not whether the proposed mitigations/alternatives are viable, but whether people will employ them or rather pass on Firefox OS. If they pass on Firefox OS, and do it in sizable numbers, it's still something we'd need to act upon, just pointing out that the behavior  is technically correct or pointing to alternatives won't suffice. 

I can't spend the time to figure out how many people are affected by this and how many users it is costing us, but I'd generally assume that every additional hurdle is going to decrease adoption.

If you are seriously interested in the numbers, I'd suggest instrumenting this in the Firefox email client.

	Jack Liu
	Comment 25 • 10 years ago

I agree with Kadir, may be users don't complain but just make their choices.
It's funny that we develop FirefoxOS phone but it can't support our own email server.

	Andrew Sutherland [:asuth] (he/him)
	Comment 27 • 10 years ago

(In reply to Jack Liu from comment #25)
> I agree with Kadir, may be users don't complain but just make their choices.
> It's funny that we develop FirefoxOS phone but it can't support our own
> email server.

I just looked into this briefly by guessing domains.  There is a server at webmail.tcl.com (also available at mail.tcl.com but the cert is only good for webmail.tcl.com).  It uses an untrusted root, "TCL CA".  If you browse to https://webmail.tcl.com/ you will see that none of Firefox, Chrome, Internet Explorer, etc. are okay with this certificate by default.  As a workaround, it seems that one can access http://webmail.tcl.com and login without using any encryption.

This is not an advisable situation for the server unless all of the users of the website manually install the certificate root to every device they use or manually verify the fingerprint of the site's certificate every time they add an exception / new account / etc.  Note that http://webmail.tcl.com/help_en.htm makes no mention of verifying the certificate using information accessed via secure channels.

If you can put me in touch with whomever operates the mail servers, I would be happy to evangelize the benefits of using real certificates, which again, are freely available from https://www.startssl.com/?app=1.  (It is worth noting with the recent Heartbleed issue that StartSSL does charge a ~$25 recovation fee even for free certificates.  However, the server in question appears to use IIS which was not affected by Heartbleed, so that would not have been an issue.)

	Jack Liu
	Comment 28 • 10 years ago

Dear Andrew,

Thanks for your feedback and suggestion. 
But from my point of view, it's hard to ask server managers to replace their certifications.
Not only mail server of TCL group but also server of customer like DT are using certifications with you called untrusted root, but they are working properly with android phone or iphone, so customers and end users think FirefoxOS phones should also work properly with those servers.

I think it's compatibility issue indeed, what do you think?

	Andrew Sutherland [:asuth] (he/him)
	Comment 29 • 10 years ago

It's a security and privacy issue.

The Android and iPhone users are vulnerable to man-in-the-middle attacks which can render their private communication public and allow them to be impersonated not only for the duration of the single session over a compromised network but in the future until their credentials are changed.  Impersonation includes sending authentic-looking e-mails as if they came from the compromised user.

We should absolutely ask server managers to get free, valid certificates.  Can you clarify your point of view to explain why it's hard to ask server managers to do this?

	Kadir Topal [:atopal]
	Comment 30 • 10 years ago

Andrew, I'm not sure if you are serious with that question. In case you are: Have you ever wondered why we allow people to override this and trust self signed certs in Firefox for desktop? Why on earth do we leave people vulnerable there, especially since on desktop it affects hundreds of millions of people?

	Andrew Sutherland [:asuth] (he/him)
	Comment 31 • 10 years ago

:atopal, let's take your question to http://www.mozilla.org/about/forums/#dev-security (I'm subscribed) or similar public discussion list and then drop the link to where the thread is in here so others can find it too.

I would like to keep this bug tightly focused on the issue at hand and your (very legitimate!) questions in response to my question are somewhat more meta in nature.  I've indicated in comment 29 that precedents of other mail clients are not sufficient to sway me on their own, so referring to a general web browser that displays many things other than potentially private mail correspondence and established its precedent many years before certificates became freely available is also not super-likely to sway me on its own.

	Thomas Ho [:tho]
	Comment 32 • 10 years ago

Andrew, in this case, we know what mail servers the bug was reported against, so we could reach out to them and ask them to correct the certificate. The world is not perfect. There definitely are many mail servers worldwide with the same or similar certificate issue, what can we do about them? On the other hand, what will Firefox OS phone users do when they encounter such an issue? I bet most of them won't know it's actually caused by a server issue, especially if their peers using other mobile platform devices have no problem connecting to the server.

I'm not sure if my view is correct, but I believe an invalid certificate on a web server poses greater risk than one on a mail server. But Firefox browser still tolerates the case and lets user proceed (with warning, of course). I believe this is the least that the Firefox OS mail client should do, too. Thank you very much.

	Andrew Sutherland [:asuth] (he/him)
	Comment 33 • 10 years ago

(In reply to Thomas Ho [:tho] from comment #32)
> Andrew, in this case, we know what mail servers the bug was reported
> against, so we could reach out to them and ask them to correct the
> certificate.

Right.  I pinged :gal to try and use our existing contacts within TCL to get in touch with whoever operates the server, ideally via channels which can carry some management weight to help get it prioritized.  He in turn pinged you to try and have a TAM (Technical Account Manager?) to do this.

Have you or someone else done this?  I have not received any feedback on this.


> The world is not perfect. There definitely are many mail
> servers worldwide with the same or similar certificate issue, what can we do
> about them?

We can:
- evangelize those server operators to improve their security
- (better) explain to the user when refusing to use a server why we are not allowing them to connect to the server for their protection
- help the user migrate to an email service that demonstrates some concern about security

For example, gmail and many other IMAP mail providers both:
- Provide free email
- Provide an option to pull mail from other services so the user can continue to use their old email address and/or migrate to the superior provider.

While having gmail pull the messages using invalid certificates is still not an ideal situation, besides allowing the user to migrate to a much more secure email account entirely, the risk profile of message retrieval via inter-data-center backbone-grade connections is much better than the risk profile of the internet connections mobile devices are faced with.

Specifically inter-data-center taps over fixed line connections will generally require government-level intervention, coordinated criminal intervention of trackable subversion of wired infrastructure, trace-able false BGP advertisements, or collusion on the part of employees of the companies along the network path.  In contrast, both cellular networks and wi-fi networks have largely broken encryption allowing undetectable passive eavesdropping in addition to active attacks.  And that's assuming a user doesn't intentionally pick a sketchy free wi-fi.


> I'm not sure if my view is correct, but I believe an invalid certificate on
> a web server poses greater risk than one on a mail server.

Can you explain why you believe this?

	Andrew Sutherland [:asuth] (he/him)
	Comment 34 • 10 years ago

(In reply to Andrew Sutherland (:asuth) from comment #33)
> For example, gmail and many other IMAP mail providers both:

I forgot to mention that gmail is just an example here.  Because of the US Government's extremely hostile stance on user privacy of non-US citizens, it would be preferable to avoid directing non-US-based users to a mail provider subject to US jurisdiction.  It would also be good if those providers were in a jurisdiction that valued user privacy and the provider took securing their own infrastructure seriously.

	Thomas Ho [:tho]
	Comment 35 • 10 years ago

I mentioned before, I'm not sure if my view is correct. But I think browser does a lot more things that a mail client, and for all mail servers that I've encountered with before, they all have user ID/PW protection to access mail, which is not the case for most web sites.

I don't believe asking TAM to reach out to TCL or even DT to correct the mail server certificates will close this bug. Let me have more discussion w/ Adam (Product) on this. It should be either we need to change our mail client behavior, or we stick to our current mail client design and don't tolerate invalid certificates. Whether or not TCL/DT servers change the certificates or not is irrelevant to this bug.

	Andrew Sutherland [:asuth] (he/him)
	Comment 36 • 10 years ago

(In reply to Thomas Ho [:tho] from comment #35)
> I mentioned before, I'm not sure if my view is correct. But I think browser
> does a lot more things that a mail client, and for all mail servers that
> I've encountered with before, they all have user ID/PW protection to access
> mail, which is not the case for most web sites.

I think you're misunderstanding the risk profile here.  I appreciate your explicitly disclaiming confidence in your opinion, but if you're unsure or don't know I think it's better to just say you don't know rather than risk adding confusion within the Mozilla management channels about the very serious risks to all users of Firefox OS devices such a feature poses.


The fact that mail servers authenticate a user via user id and and password provides no protection to the user.  The user authenticates the server through use of the certificate authority trust infrastructure.  If we allow the user to add an exception, we are dependent on them manually verifying the certificate fingerprint both the first time and every time it changes.  (This also assumes that there is only one certificate in use across a cluster of servers.)  For webmail.tcl.com, the SHA1 fingerprint is "6F:BD:11:04:E3:74:F1:12:BF:A2:1E:2D:0E:94:82:A8:18:C2:C9:FE".  In a straight-forward implementation that operates identically to the Firefox exception process, the user needs to already have received a copy of this fingerprint via some other secure channel (say, a piece of paper handed to them by their server admin) and verify that the fingerprint matches *exactly* for all security and privacy guarantees to hold.


Likewise, the user's use of a user id and password only helps the server know the user is who they say they are if only the user possesses the password.  If the user screws up when verifying the certificate and accepts a certificate controlled by an attacker, their credentials have now leaked.  The attacker no longer needs to be able to mount an active man-in-the-middle attack against the user.  With the user's credentials they can log in to the user's account and read their emails, send e-mails as the user, et cetera.  This includes going to any of the websites the user uses, such as the user's bank, and using the password reset mechanism to reset the user's password.  The attacker can then delete the message (and potentially inhibit any push-style notifications if an active attack is still under way) so the user does not realize their password has been reset.

Furthermore, as mentioned in comment 11, the certificate store is global on the device so an attacker that gets the user to accept an attacker-controlled certificate in mail also means that the same certificate will be accepted in the browser for the same domain.  A clever attacker can cascade this with other attacks against the e-mail configuration mechanism to do things like be able to stage a man-in-the-middle attack against the user's https connections to their bank without requiring the user to accept an exception in the browser.  This is significant because while some banks may have strong multi-factor authentication mechanisms where control of the user's email account does not compromise security, an active man-in-the-middle attack where the user logs in means those additional protections are inherently bypassed.


> I don't believe asking TAM to reach out to TCL or even DT to correct the
> mail server certificates will close this bug.

Agreed, it won't close this bug.  My goal in contacting Andreas and thereby you was not to close the bug.  It was to help TCL secure their mail server.  A pleasant side-effect of this is that if TCL secures their mail server, that's one less mail server out there that makes people want us to address this bug by allowing certificate exceptions to be added.


> Let me have more discussion w/
> Adam (Product) on this. It should be either we need to change our mail
> client behavior, or we stick to our current mail client design and don't
> tolerate invalid certificates.

Please read this bug in its entirety if you are going to have any serious discussions about making decisions related to this bug.

	Thomas Ho [:tho]
	Comment 37 • 10 years ago

Andrew, I talked to Adam (Product), and let's park this here first.

1. I will ask my TAM to reach out to TCL to have their mail server certificate corrected.
2. I will reach out to UX team, to do a study on the best way moving forward. That is, provide a path for Firefox OS mail users to proceed reading mail, even w/ an invalid certificate on server, but not just letting user blindly accepting something posted on screen. We care more about security than our competitors, but we also don't want Firefox OS users not able to get mail from some servers.

The goal I'd like to reach is to have a mail client workaround available w/ the least possible security concern. Thank you very much.

	Andrew Sutherland [:asuth] (he/him)
	Comment 38 • 10 years ago

(In reply to Thomas Ho [:tho] from comment #37)
> 1. I will ask my TAM to reach out to TCL to have their mail server
> certificate corrected.

Excellent, thank you!


> 2. I will reach out to UX team, to do a study on the best way moving
> forward. That is, provide a path for Firefox OS mail users to proceed
> reading mail, even w/ an invalid certificate on server, but not just letting
> user blindly accepting something posted on screen. We care more about
> security than our competitors, but we also don't want Firefox OS users not
> able to get mail from some servers.

This sounds like a mis-prioritization of UX resources.  I concede that TCL's server using effectively invalid certificates is an amusing (if embarrassing for all involved) anecdotal datapoint.  But it's not a data set.  I haven't seen any data saying that our existing users or potential users are meaningfully affected.  I also haven't seen any efforts to gather this data so that an informed decision can be made as to whether we want to build-in a big security vulnerability to our UI.  I would suggest we focus our efforts there first.


If you don't think we should do that, then what is your basis for thinking we should implement this feature and advance it to UX consideration over all the many other platform and application deficiencies we have?

My impression based on the little rationale I have received in similar situations is that carriers have a list of required features accumulated through the years and we really want to put an 'x' in the box next to the feature on the list.

	Thomas Ho [:tho]
	Comment 39 • 10 years ago

I'll leave my point 2 above to Adam. It's not urgent, but currently the goal should be to get mail w/ hopefully a better way than just letting users blindly click on any warning button appears.

	Adam Rogers (:arog)
	Comment 40 • 10 years ago

I wouldn't prioritize this above the other features that we have on deck but I have no problem looking into some options. There are two lines of research:

1) Is it possible to establish a middle ground where we can allow a user to provide informed consent, and 
2) Are there a significant number servers (and users) in our target markets that use mail servers that we would not support.

If the answer is "yes" to both of the above, we should explore the options further.

As a general rule, we should be pushing our partners and others to ensure that they are utilizing secure configurations for email.

	Andrew Truong [:feer56] [:andrewtruong] [:atruong]
	Comment 41 • 10 years ago

(In reply to Alex Keybl [:akeybl] from comment #5)
> Out of scope for v1.0.1 at this point.
> 
> mluna - are you the right person to get a support article up about this?

SUMO is still getting questions regarding SSL/STARTTLS. Should a support article be up for this? 
Reference: https://support.mozilla.org/en-US/questions/1001848 

Joni (jsavage) is the current KB content manager.

	Andrew Sutherland [:asuth] (he/him)
	Comment 42 • 10 years ago

Yes, a support article seems appropriate.  If we can also have an easy way to find out how many users / what domains are affected, that would be great.  Either if users can leave comments or a google spreadsheet form or something like that (which I can help set up).  Comments could potentially be better since in many cases (like dreamhost.com) there are things we could do as it relates to autoconfig to make things work since there are valid certificates available, the domain just doesn't line up.

	Warren WU
	Comment 44 • 10 years ago

Dear Andrew:
If we accessed webmail address through browser (ex:https://webmail.tcl.com/),and add certificate exceptions,and then open the email app ,and create a email account of tcl,it can create success. So i think it is necessary to add this in email app like the browser. What do you think?

	Andrew Sutherland [:asuth] (he/him)
	Comment 45 • 10 years ago

(In reply to wuww@tcl.com from comment #44)
> If we accessed webmail address through browser
> (ex:https://webmail.tcl.com/),and add certificate exceptions,and then open
> the email app ,and create a email account of tcl,it can create success. So i
> think it is necessary to add this in email app like the browser. What do you
> think?

Please see the mitigations mentioned in comment 11.  We can mitigate on a per-domain basis but it will require new engineering effort.  I currently estimate this will require at least 6 weeks of engineering effort to do in a safe fashion because because of the large number of edge cases and the security ramifications if it's done incorrectly.

We do not have the engineering resources available at this time for this.  If you can provide engineering resources for this, we can work with them to implement this in a safe fashion after discussing the proposed mitigations with the security team.

Less man-power intensive options for the TCL server include:

1) getting valid certificates.  Our Technical Account Manager (TAM) for TCL was supposed to look into this a month ago, but I haven't heard anything.  I have re-pinged them to see if there has been any progress on this.  Alternately, if you can put me in touch with decisions-makers/operators of the mail server so I can discussing this option, I would be appreciative.  I can also be reached via asuth@mozilla.com.  (I am also going to try and contact them via postmaster@tcl.com as linked from the help page now since using more formal channels has not panned out.)

2) documenting the workaround for the invalid certificates at the help page linked to from webmail.tcl.com.  (It directs me to http://webmail.tcl.com/help_en.htm)

In general, I would suggest option 1 since it provides the best security for all users of the mail server and wemail gateway.

	Andrew Sutherland [:asuth] (he/him)
	Comment 46 • 10 years ago

As a resource for any future evangelism emails sent related to this type of certificate problem, I've sent the following to postmaster@tcl.com.  (Any replies on their part will be treated with expected email privacy so I won't be including them here without their consent)

==== Subject
SSL/TLS certificates issues for mail clients with strict enforcement for IMAP/SMTP/webmail
==== Body
Hello,

I work on the Firefox OS e-mail app which runs on mobile phones/tablets including products released by TCL.  The TCL mail servers appear to use a variant on a self-signed certificate chain. It is not recognized by any of Firefox, Chrome, Internet Explorer, etc.  There is discussion on our bug tracker at https://bugzil.la/874346 to the general issue of invalid certificates.

Is it possible for you to acquire valid certificates?  Free certificates are available from https://www.startssl.com/?app=1.  It does appear your current certificate exposes a number of alternate names which I think the free certificate may not support (although you can acquire multiple free certificates.)  But more featureful certificates that support wild card names are still quite cheap; the same vendor has them available from $59.90 (see https://www.startssl.com/?app=40) and even more expensive vendor's prices are likely worth the security benefits provided.

Security-wise, using self-signed certificates makes users vulnerable to man-in-the-middle attacks whenever they need to add a new exception unless they manually verify the certificate fingerprint(s) source via a secure/trusted mechanism.  While this may seem like it will only occur when a user creates an account, the reality is somewhat worse since the server may need to change the certificate it uses for various reasons.  For example, the current webmail.tcl.com certificate will expire less than a year from now on 3/17/2015.  The server may also need to change to a new certificate if it is compromised/lost/etc.  If the new certificate is not valid, a new exception will need to be created.

With users expecting to add exceptions, they may be vulnerable to attacks since the email app/platform is unable to determine whether a new certificate is actually a new certificate or the work of an attacker and the user is also unlikely to be able to make that determination on their own.  The only way they can know if the certificate is trustworthy/correct is if they verify the fingerprint.  (And again, the fingerprint must come via a secure channel, so placing the fingerprint on the webmail.tcl.com server's help pages would be insufficient.)

Please let me know if there's anything I can do to help,
[me]
====

	Warren WU
	Comment 47 • 10 years ago

(In reply to Andrew Sutherland (:asuth) from comment #46)
> As a resource for any future evangelism emails sent related to this type of
> certificate problem, I've sent the following to postmaster@tcl.com.  (Any
> replies on their part will be treated with expected email privacy so I won't
> be including them here without their consent)
> 
> ==== Subject
> SSL/TLS certificates issues for mail clients with strict enforcement for
> IMAP/SMTP/webmail
> ==== Body
> Hello,
> 
> I work on the Firefox OS e-mail app which runs on mobile phones/tablets
> including products released by TCL.  The TCL mail servers appear to use a
> variant on a self-signed certificate chain. It is not recognized by any of
> Firefox, Chrome, Internet Explorer, etc.  There is discussion on our bug
> tracker at https://bugzil.la/874346 to the general issue of invalid
> certificates.
> 
> Is it possible for you to acquire valid certificates?  Free certificates are
> available from https://www.startssl.com/?app=1.  It does appear your current
> certificate exposes a number of alternate names which I think the free
> certificate may not support (although you can acquire multiple free
> certificates.)  But more featureful certificates that support wild card
> names are still quite cheap; the same vendor has them available from $59.90
> (see https://www.startssl.com/?app=40) and even more expensive vendor's
> prices are likely worth the security benefits provided.
> 
> Security-wise, using self-signed certificates makes users vulnerable to
> man-in-the-middle attacks whenever they need to add a new exception unless
> they manually verify the certificate fingerprint(s) source via a
> secure/trusted mechanism.  While this may seem like it will only occur when
> a user creates an account, the reality is somewhat worse since the server
> may need to change the certificate it uses for various reasons.  For
> example, the current webmail.tcl.com certificate will expire less than a
> year from now on 3/17/2015.  The server may also need to change to a new
> certificate if it is compromised/lost/etc.  If the new certificate is not
> valid, a new exception will need to be created.
> 
> With users expecting to add exceptions, they may be vulnerable to attacks
> since the email app/platform is unable to determine whether a new
> certificate is actually a new certificate or the work of an attacker and the
> user is also unlikely to be able to make that determination on their own. 
> The only way they can know if the certificate is trustworthy/correct is if
> they verify the fingerprint.  (And again, the fingerprint must come via a
> secure channel, so placing the fingerprint on the webmail.tcl.com server's
> help pages would be insufficient.)
> 
> Please let me know if there's anything I can do to help,
> [me]
> ====

Dear Andrew:
Not only tcl mail,The AT4 wireless mail(mail.at4wireless.com) used for Telefonica testing people also have this problem ,and they want to the issue achievable to be implemented in a short period of time.

	Warren WU
	Comment 48 • 10 years ago

Dear Vance:
The AT4 wireless mail also have this problem,Telefonica want we solved this problem in this week, whether we can find a temporary solutions for this?

	Vance Chen [:vchen][skype:vance.lucida][vchen@mozilla.com]
	Comment 49 • 10 years ago

(In reply to wuww@tcl.com from comment #48)
> Dear Vance:
> The AT4 wireless mail also have this problem,Telefonica want we solved this
> problem in this week, whether we can find a temporary solutions for this?

As Andrew pointed out in Comment#45, it requires at least 6 weeks of engineering effort to come out solution. So could you provide here the contact information of the AT4 lab tester? Maybe we can help to discuss with the test house and convince them to use a valid certification.

Thanks

	Jack Liu
	Comment 50 • 10 years ago

Dears,

Customer do need a workaround for this.

As customer required, the final solution is MUST not per-domain solution, decision should make by end user on whether or not accept self-signed certification.

	Vance Chen [:vchen][skype:vance.lucida][vchen@mozilla.com]
	Comment 51 • 10 years ago

(In reply to Jack Liu from comment #50)
> Dears,
> 
> Customer do need a workaround for this.
> 
> As customer required, the final solution is MUST not per-domain solution,
> decision should make by end user on whether or not accept self-signed
> certification.

Hi Jack -

Please still do provide us the contact information of your customers. We still want to discuss with them about the benefit about the valid certification.

Thanks

	berwe2501
	Comment 52 • 10 years ago

Dear Developers,

[warning - this may be considered a rant and rave]

Without in any way reducing my gratefulness for your efforts and achievements, I would like to make my totally personal and subjective comment that in this case you are going in the wrong direction trying to make reality fit your product instead of the other way round.
As (probably) many buyers of a FFOS device I chose it, because I don't like the lock-in and patronizing attitude of the big players in the market. However, issues like this email problem make me again feel I'm at the mercy of people thinking they know better what I want than I do myself.

Please provide a reliable solution for using self-signed certificates, even if it is a separate app with a bunch of "all warranty void" warnings, or even a reliable way of doing this via a usb connection to the device.

Please, please, please!!!!

Thank you
  Waltraud

	Beatriz Rodríguez [:brg]
	Comment 53 • 10 years ago

(In reply to Vance Chen [:vchen][vchen@mozilla.com] from comment #51)
> (In reply to Jack Liu from comment #50)
> > Dears,
> > 
> > Customer do need a workaround for this.
> > 
> > As customer required, the final solution is MUST not per-domain solution,
> > decision should make by end user on whether or not accept self-signed
> > certification.
> 
> Hi Jack -
> 
> Please still do provide us the contact information of your customers. We
> still want to discuss with them about the benefit about the valid
> certification.
> 
> Thanks

Customers just want email service to work on their devices(like it is already working in Android and iPhone), please find a way to unlock this situation.

	Andrew Sutherland [:asuth] (he/him)
	Comment 54 • 10 years ago

(In reply to berwe2501 from comment #52)
> As (probably) many buyers of a FFOS device I chose it, because I don't like
> the lock-in and patronizing attitude of the big players in the market.
> However, issues like this email problem make me again feel I'm at the mercy
> of people thinking they know better what I want than I do myself.

I should clarify that this bug is only about creating a path to add an exception from within the email app as triggered by the account setup process.  The primary concern in this case is that extremely few users will have a sufficient understanding of the underpinnings of TLS or the certificate authority infrastructure to make an informed decision about adding an exception if it is naively implemented.  There are safe-ish mitigations described in comment 11 and elsewhere that allow us to help the user to make an informed decision, but they fundamentally constitute a reimplementation of the underlying security model of the internet.

There is no opposition from the developers of the email app to provide UI in the settings app to allow exceptions to be manually added.  Such a flow is much less likely to result from warning-blindness where the user just keeps hitting the "yes, just give me my mail!" button.  Bug 867899 and bug 769183 nominally cover this, although an additional bug may need to be created depending on the UX flow deemed acceptable by the security team.

I've updated the bug summary to match this.

	Andrew Sutherland [:asuth] (he/him)
	Comment 55 • 10 years ago

(In reply to Jack Liu from comment #50)
> As customer required, the final solution is MUST not per-domain solution,
> decision should make by end user on whether or not accept self-signed
> certification.

Along the lines of what Vance requests, can you provide the literal requirement and information about who to talk to about the requirement in the context of the risk profiles enumerated on this bug?

	Andrew Sutherland [:asuth] (he/him)
	Comment 56 • 10 years ago

To help move this bug forward I've started a thread "B2G, email, and SSL/TLS certificate exceptions for invalid certificates" on dev-platform and provided a pointer to the thread on dev-b2g, dev-gaia, dev-webapi, dev-security, and dev-security-policy.

If you're not already subscribed, you can find the message in the archive and potentially comment via google groups at:
https://groups.google.com/forum/#!topic/mozilla.dev.platform/lT4Mhi-B1JI

Subscription information for the group, including via NNTP where the message is also available for new subscribers, can be found at:
http://www.mozilla.org/about/forums/#dev-platform

	Joni Chan
	Comment 57 • 10 years ago

I'm the content manager for SUMO. Do we still need a support article at this point or do we expect some UI changes in the near future? What do we want the article to tell users?

	Jack Liu
	Comment 58 • 10 years ago

Dear Vance, Andrew,

Sorry for later reply, have send your message to our internal team, they will help transfer message to customer. Ideally, DT & TEF will contact with mozilla directly.

Thanks.

	Lucas Adamski [:ladamski]
	Comment 59 • 10 years ago

I'm not sure this is actually a valid feature, much less realistic for 2.0 as currently defined.  Per comment 11 we're trying to solve a number of very different problems within a single bug.  There are at least 3 main problems (probably more):

a) "minor" subdomain / wildcard mismatches - probably the lowest hanging fruit here.  Still weakens the security model and presents risk (where you have different orgs hosted in subdomains for example) so requires some detailed discussion.

b) certificates that chain to unknown roots (i.e. enterprises) - users should have a way of importing that root so it enables access to intranets

c) self-signed certificates - this problem is not solvable.  Nobody ever checks the fingerprint so an in-band exception mechanism is effectively a "disable security" button.

None of these really should be the email app's problem, though I appreciate the effort to reduce risk by only enabling this during account setup.  If these are platform features that the email app can then enable (at account setup) 

More broadly though, supporting these use cases is putting energy into the past.  The future is an environment where certificates are cheap and there's no excuse to not have a valid one.  HSTS for example explicitly forbids in-band exceptions.  Organizations that host mail services should be savvy enough to buy and installed trusted certificates.

	Andrew Sutherland [:asuth] (he/him)
	Comment 60 • 10 years ago

A post to dev-gaia indicated confusion at the state of this bug so I am updating/misusing the user story to (more concisely) reflect the current state and known workarounds.  I'm also explicitly expressing dependencies on the system bugs where the problem should be addressed.

	JY
	Comment 61 • 10 years ago

(In reply to Lucas Adamski [:ladamski] (plz needinfo) from comment #59)
> I'm not sure this is actually a valid feature, much less realistic for 2.0
> as currently defined.  Per comment 11 we're trying to solve a number of very
> different problems within a single bug.  There are at least 3 main problems
> (probably more):
> 
> a) "minor" subdomain / wildcard mismatches - probably the lowest hanging
> fruit here.  Still weakens the security model and presents risk (where you
> have different orgs hosted in subdomains for example) so requires some
> detailed discussion.
> 
> b) certificates that chain to unknown roots (i.e. enterprises) - users
> should have a way of importing that root so it enables access to intranets
> 
> c) self-signed certificates - this problem is not solvable.  Nobody ever
> checks the fingerprint so an in-band exception mechanism is effectively a
> "disable security" button.
> 
> None of these really should be the email app's problem, though I appreciate
> the effort to reduce risk by only enabling this during account setup.  If
> these are platform features that the email app can then enable (at account
> setup) 
> 
> More broadly though, supporting these use cases is putting energy into the
> past.  The future is an environment where certificates are cheap and there's
> no excuse to not have a valid one.  HSTS for example explicitly forbids
> in-band exceptions.  Organizations that host mail services should be savvy
> enough to buy and installed trusted certificates.

I don't see why users could not import self-signed certificates as well. I don't see it as a "feature of the past", it's very present to me, as I cannot use any of my services, and the phone is totally useless to me "as is".

Please inform me if this kind of feature isn't planned at all in the future, as there is no point for me to wait if that's the case, and the phone will go back to the store then.

	JY
	Comment 62 • 10 years ago

(In reply to JY from comment #61)
> (In reply to Lucas Adamski [:ladamski] (plz needinfo) from comment #59)
> > I'm not sure this is actually a valid feature, much less realistic for 2.0
> > as currently defined.  Per comment 11 we're trying to solve a number of very
> > different problems within a single bug.  There are at least 3 main problems
> > (probably more):
> > 
> > a) "minor" subdomain / wildcard mismatches - probably the lowest hanging
> > fruit here.  Still weakens the security model and presents risk (where you
> > have different orgs hosted in subdomains for example) so requires some
> > detailed discussion.
> > 
> > b) certificates that chain to unknown roots (i.e. enterprises) - users
> > should have a way of importing that root so it enables access to intranets
> > 
> > c) self-signed certificates - this problem is not solvable.  Nobody ever
> > checks the fingerprint so an in-band exception mechanism is effectively a
> > "disable security" button.
> > 
> > None of these really should be the email app's problem, though I appreciate
> > the effort to reduce risk by only enabling this during account setup.  If
> > these are platform features that the email app can then enable (at account
> > setup) 
> > 
> > More broadly though, supporting these use cases is putting energy into the
> > past.  The future is an environment where certificates are cheap and there's
> > no excuse to not have a valid one.  HSTS for example explicitly forbids
> > in-band exceptions.  Organizations that host mail services should be savvy
> > enough to buy and installed trusted certificates.
> 
> I don't see why users could not import self-signed certificates as well. I
> don't see it as a "feature of the past", it's very present to me, as I
> cannot use any of my services, and the phone is totally useless to me "as
> is".
> 
> Please inform me if this kind of feature isn't planned at all in the future,
> as there is no point for me to wait if that's the case, and the phone will
> go back to the store then.

hmm... seems I went too fast. If b) is on the agenda (is it?) then it should be okay. I was talking about self-signed CA, and I am very concerned as you may have guessed.

	adrian.rosian
	Comment 63 • 10 years ago

@andrew, the ability to add self-signed certificates or certificate exceptions is a good workaround for the email providers out there. There are a number of situations where you cannot ask for a valid certificate (like being an employee, or anyway having this model imposed to you for whatever reason). Not allowing this equates to not being able to use the email. In my case, as mentioned before, this equates to me returning the phone.

Now I am a software developer myself and I understand your pain, but please, adjust to the real world just a bit, even if it takes to make my whole screen red while doung it!

> I don't see why users could not import self-signed certificates as well. I don't see it as a "feature of the past", it's very present to me, as I cannot use any of my services, and the phone is totally  > useless to me "as is".
> 
> Please inform me if this kind of feature isn't planned at all in the future, as there is no point for  me to wait if that's the case, and the phone will go back to the store then."

	Gerhard Roland
	Comment 64 • 10 years ago

I urgently need an email application that can present user certificates from the key store to an IMAP server asking for them. In the meantime i have to switch my ZTE openC to Android where the build in Mail client is capable of that. Thanks for your help.

	Ralph Daub [:rdaub]
	Comment 65 • 9 years ago

For tracking purposes -
A user in the SUMO forums is having issues related to this bug: https://support.mozilla.org/en-US/questions/1035187

	Ralph Daub [:rdaub]
	Comment 66 • 9 years ago

For tracking purposes -
A user in the SUMO forums is having issues related to this bug: https://support.mozilla.org/en-US/questions/1045317

	Julien Vehent
	Comment 68 • 9 years ago

From the user story:
> - Use the browser app to add a certificate exception.  This should definitely work for ActiveSync, it may work for IMAP/SMTP/POP3 if the same certificate is hosted at the same domain name on the https port.

I tested this today with a vhost on 443 that serves a certificate from my personal PKI. I can see and add the certificate exception when browsing https://smtp.mydomain.net, but the connection to smtp.mydomain.net:587 using SSL (not starttls) still fails.

	Andrew Sutherland [:asuth] (he/him)
	Comment 69 • 9 years ago

Yes, https://dxr.mozilla.org/mozilla-central/source/security/manager/ssl/nsICertOverrideService.idl#39 indicates that certificate exceptions are stored on a per-port basis and that workaround was optimistic.  I have updated the user story.

You will need to manually add your personal PKI via the painful command line process (or implement the system functionality to allow adding a certificate via the UI).  If you are using a personal CA/PKI for added security, you will also need to (somehow) add pin directives via https://dxr.mozilla.org/mozilla-central/source/security/manager/ssl/nsISiteSecurityService.idl#162, although it's not clear that pinning works for TCPSocket connections since the code checks for HSTS/HPKP type identifiers all over the place and it seems possible they would not be passed.  (I haven't run down the full dataflow.)

	BMO Automation
	Comment 70 • 6 years ago

Firefox OS is not being worked on