If the government of Kazakhstan requires interception of TLS as a condition of access, the real question being asked is whether or not Mozilla products will tolerate being used in these circumstances.
Your options are to block the certificate, in which case Mozilla products simply become unusable to those subject to this interception, or not block the certificate. I certainly think that Mozilla should not distribute the MiTM root or do anything special to aid in its installation. I believe policy already makes clear that NO included root (commercial or government) is allowed for use in MiTM scenarios and I believe that policy should be held firm. I do believe that as it is manually installed rather than distributed as a default that it should continue to override pinning policy. This is an accepted corporate use case today in certain managed environments. The dynamic is quite different for an entire people under an entire government, but the result is the same: One has to choose whether to continue serving the user despite the adverse and anti-privacy scenario, or if one simply won't have their products be any part of that. Much has been said about the TLS 1.3 design hoping to discourage use cases like this, but the reality is what I always suspected: some enterprises or governments actually will spend the money to do full active MiTM interception. Let's posit what might happen if Mozilla made their products intentionally break for this use case. Further, let's stipulate that every other major browser follows course and they all blacklist this or any other nation-state interception certificate, even if manually installed. Isn't the logical outcome that the nation-state forks one of the open-source browser projects, patches in their MiTM certificate, and un-does the blacklisting? I think that's exactly what would happen. The trouble is, there's no reason to expect that the fork will be maintained or updated as security issues are discovered and upstream patches are issued. We wind up with an infrequent release cycle browser being used by all these users, who in turn get no privacy AND get their machines rooted disproportionate to the global population. I do definitely support a persistent UI indicator for MiTM scenarios that emphasizes on-screen at all times that the session is being protected by a non-standard certificate and some sort of link to explain MiTM and the risks. On Thu, Jul 18, 2019 at 12:04 PM Wayne Thayer via dev-security-policy < [email protected]> wrote: > On Thu, Jul 18, 2019 at 10:00 AM Ryan Sleevi <[email protected]> > wrote: > > > > > On Thu, Jul 18, 2019 at 12:50 PM Wayne Thayer via dev-security-policy < > > [email protected]> wrote: > > > >> Finally, I'll point out that Firefox implements public key pinning via a > >> preloaded list of sites, so the reported MITM will fail for those: > >> > >> > https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning#Implementation_status > > > > > > Wayne, > > > > I don't believe this is correct. Locally-installed trust anchors bypass > > pinning, as they're indicators of explicit user action (or coercion) to > > configure. As a consequence, unless the pinning mode is set to 2. Strict > > (which will typically preclude the use of a number of anti-virus > products, > > for better or worse), which it is not by default, the MITM will not fail. > > From the Firefox point-of-view, it's completely transparent whether the > > MITM is being done by local security software or a nation-state > > > > Yes, I had just realized that - in the default state, pinning in Firefox > will not block this type of MITM. > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
