Chrome has, to date, intentionally rejected the ability of extensions to modify the connection security attributes in this way.
Mozilla will need to make a call based on its trust of the extensions ecosystem, the potential for harm, and the various other impacts. For example, an extension that modified a trust decision favorably may cause a resource to be cached on an otherwise-invalid connection, and that resource will persist even if/when the extension is removed. Thus, remediation of a 'malicious' extension may imply eliminating all persistent storage of the user - depending on what the intended level of remediation is. I don't know if content-modification scripts are granted that same privilege. It would similarly be worth thinking about how the user would be presented to make such an informed decision about granting such an extension access. Given the profound capabilities implied by certificate verification, and the risks, Chrome has not yet supported a view that general users would be able to have sufficient context to make an informed and reasonable decision. That said, we're very supportive of proposals by EFF to expose connection-level information (without the ability to impose decision making capabilities) via the webRequest API, which I understand Mozilla has implemented something similar? https://groups.google.com/a/chromium.org/d/msg/security-dev/qdSaEtR2Sss/mxIytQdTCAAJ includes one such discussion of the various tradeoffs implied. On Tue, Feb 27, 2018 at 11:23 AM, Alex Gaynor via dev-security-policy < [email protected]> wrote: > A reasonable compromise that jumps out to me is allowing extensions to make > an otherwise-secure connection fail, but not allow them to rehabilitate an > insecure connection. This would allow experimenting with stricter controls > while avoiding some of the really scary risks. > > Alex > > On Tue, Feb 27, 2018 at 11:20 AM, Wayne Thayer via dev-security-policy < > [email protected]> wrote: > > > I am seeking input on this proposal: > > > > Work is underway to allow Firefox add-ons to read certificate information > > via WebExtensions APIs [1]. It has also been proposed [2] that the > > WebExtensions APIs in Firefox be enhanced to allow a 3rd party add-on to > > change or ignore the normal results of certificate validation. > > > > This capability existed in the legacy Firefox extension system that was > > deprecated last year. It was used to implement stricter security > mechanisms > > (e.g. CertPatrol) and to experiment with new mechanisms such as > Certificate > > Transparency and DANE. > > > > When used to override a certificate validation failure, this is a > dangerous > > capability, and it’s not clear that requiring a user to grant permission > to > > the add-on is adequate protection. One solution that has been proposed > [4] > > is to allow an add-on to affect the connection but not the certificate > UI. > > In other words, when a validation failure is overridden, the page will > load > > but the nav bar will still display it as a failure. > > > > I would appreciate your constructive feedback on this decision. Should > this > > capability be added to the Firefox WebExtensions APIs? > > > > - Wayne > > > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1322748 > > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1435951 > > [3] https://mail.mozilla.org/pipermail/dev-addons/2018- > > February/003629.html > > [4] https://mail.mozilla.org/pipermail/dev-addons/2018- > > February/003641.html > > _______________________________________________ > > 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 > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
