SecurityEngineering/Untrusted Certificates in Windows Child Mode
Recent versions of Windows include "Family Safety" functionality whereby a user's account can be put into "child mode", which enables monitoring of the Internet activity of that user. This mechanism appears to work in part by locally proxying all web traffic. Normally this would not be possible for TLS traffic (i.e. https:// urls). To monitor TLS traffic, the Family Safety functionality creates a new root certificate and adds it as a trust anchor to the operating system's root store. When a program running on the child account attempts to make an outbound HTTPS connection, the proxy creates and signs a new certificate that is valid for the target domain and presents that to the program. If the program uses the operating system's trust store (as Chrome does, for example), it will find that the certificate was issued by a trusted root and the connection will proceed. If the program uses its own trust store (as Firefox does), it will terminate the connection because the certificate was not issued by a trusted root. This means that Firefox is not a functional browser for these users.
A few bugs have been filed on this issue: bug 1189110, 1183930, bug 1067174, and bug 1189275 (the latter three have been marked as duplicates of the first one). The number of users who do not know about bugzilla or simply switched browsers almost certainly dwarfs those who were able to reach us. Addressing this situation would help retain existing users and provide choice for those who use "child mode" accounts.
Before the advent of HSTS (HTTP Strict Transport Security) and HPKP (HTTP Public Key Pinning), users would be able to add certificate error overrides on a site-by-site basis. This would allow them to continue using Firefox while in child mode. However, these specifications require that the browser not allow any overrides for domains using these features. HSTS and HPKP are becoming increasingly popular and as a result this is no longer a workable solution.
If the user were to find and import the Family Safety root certificate into Firefox, this would allow connections to proceed as intended. Only the most advanced users will be able to do this. Again, this is not a realistic solution.
Automatically trusting all trust anchors in the operating system's root store would solve this problem. However, Mozilla maintains its own discrete root certificate program for a number of reasons. Implementing this solution would undermine the purpose of Mozilla's program and the safety it provides users.
A more targeted approach would be to only offer to import the Family Safety root certificate if the user account is in child mode. According to this document, there are registry keys that indicate if this is the case. Once Firefox has identified that an account is in child mode, it needs to import and trust only the Family Safety root certificate. There are APIs for querying the operating system's certificate database and this document indicates that the root will be called "Microsoft Family Safety Certificate". This solution would be the safest option for users.
Firefox needs to make it clear to the user that by trusting the Microsoft Family Safety Certificate, they are allowing another party to monitor their web traffic. Additionally, while it is unclear that inspecting the certificate in question is in any way useful, some users will no doubt expect to be able to do so. Consequently, there should probably be an option to view the certificate being imported.
As a final note, locally-running malicious software that masquerades as the Windows Family Safety mechanism is considered out of scope for this project. If another program has sufficient privileges to add a new trust anchor and modify registry keys, it can likely add that same root directly into the Firefox root store without any user intervention (or even replace Firefox entirely, and so on). We cannot realistically defend against this threat.