SecurityEngineering/Untrusted Certificates in Windows Child Mode: Difference between revisions
(background information on the issue) |
(finish introduction) |
||
| Line 3: | Line 3: | ||
----- | ----- | ||
Recent versions of Windows include 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). | 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. | ||
Revision as of 21:55, 29 October 2015
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.