SecurityEngineering/Untrusted Certificates in Windows Child Mode
Recent versions of Windows include "Family Safety" functionality whereby an administrator can put a user's account into "child mode", which enables monitoring of the Internet activity of that user (presumably a child or ward of the administrator). This mechanism appears to work in part by locally proxying all outbound HTTPS traffic. More specifically, the device generates a new key, creates a root certificate corresponding to that key, and adds that root as a trusted anchor in the operating system's root store. Then, when a program running on the child account attempts to make an outbound HTTPS connection, it creates and signs a new certificate that is valid for the target domain and presents that to the program. Meanwhile it initiates a connection to the actual host and prepares to ferry information between the child account and the actual host. 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, however, 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. Furthermore, if the target domain uses HSTS (HTTP Strict Transport Security) or HPKP (HTTP Public Key Pinning), the browser will not allow the user to add a certificate error override (this behavior is required by those specifications). Finding and importing the root certificate into Firefox as a trust anchor will allow connections to proceed as intended, but only the most advanced users will be able to do this. For everyone else in this situation, Firefox is not a functional browser. Due to a low volume of feedback on bugzilla, this does not appear to be an extremely widespread problem. However, we know it does affect some users, and 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.
Mozilla maintains its own root certificate program for a number of reasons. Consequently, simply trusting every root in the Windows trust database would undermine the purpose of Mozilla's program and the safety it provides users. Similarly, offering to import (or even automatically importing) the issuer of any encountered untrusted certificate severely compromise user security, as at that point any network attacker could present a certificate that has a good chance of becoming trusted by the browser. For this feature to be effective and as safe as possible, it would have to only be available if the user account is in child mode and it would have to identify and import only the root certificate being used to intercept traffic. The former appears to possible: this document identifies registry keys that indicate if the account is in child mode. It is unclear if this is available for all versions of Windows with the Family Safety functionality, however. The latter is more difficult. While there are APIs for querying the operating system's certificate database, and while this document indicates that the root will be called "Microsoft Family Safety Certificate", this could be a malicious root masquerading as the Family Safety root that has been installed by another program. However, if another program has sufficient privileges to add a new trust anchor, it can likely add that same root directly in the Firefox root store without any user intervention (or even replace Firefox entirely, and so on). So, excluding local malicious software as out of scope, there appears to be sufficient platform support to programmatically identify and import the Family Safety root certificate when an account is in child mode.