On 28/2/2018 1:52 πμ, Ryan Sleevi via dev-security-policy wrote:
On Tue, Feb 27, 2018 at 6:15 PM, Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
In the bug I referenced as [2], people said that they specifically need to
be able to override "negative" certificate validation decisions, so they
may not see this as a compromise. I think an example would be a site
serving a self-signed certificate for a DANE add-on to validate.
I think some of it may relate to Moz Platform questions, since they go to
the heart of extensions' behaviours.
For example, can extensions allow mixed content when it's been blocked? Can
they disable sandboxing if the user requests? There's a spectrum of
decisions that a browser makes as an intrinsic part of guaranteeing the
security of its users that it does not allow extensions or the like to
override, and may not even allow users themselves to override.
The design of the new extension model is to try to explicitly make sure
each capability granted to extensions is balanced in its security rationale
and functionality, and aligns the collective risks against the individual
rewards. There's a full spectrum here, well beyond PKI bits, so that's why
I suggest it strikes a bit core. It was one of the big benefits of the
process-sandboxing efforts, as extensions no longer had an 'implicit'
backdoor into the browser process.
Would you consider extensions that enabled SHA-1 automatically or disabled
technical enforcement of CAs? Fundamentally, the capability to alter trust
either grants that ability or is no-different-to that ability. What about
an extension called "HTTPS-made-easy" that just disabled all certificate
errors, on the view that the Web should be like it was in the HTTP days,
and solving the technical hurdle? What about vendors that force-install
extensions to Firefox users so they can use a shared key for all of their
installations? All of these things become possible or significantly easier
with an extension that can confer positive trust on something that Firefox
has deemed negative.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
This reminds me of "Enterprise level" decisions where some custom
options on FF (or Chrome) are allowed to disable some default features
(like check CT). However, these options have carefully been studied and
have been designed "explicitly" to allow some security exceptions.
Perhaps the FF team could provide the proper config options for some
well-defined cases that are driven by clear user needs.
DANE is a good case. QWACs (in addition to EV validation) would also be
nice to result to an additional indicator to the existing EV indicator.
The latter would not even need to bypass the default browser checks that
would normally perform in sight of an EV SSL/TLS Certificate. If the EV
validation fails, the entire check fails. But if the EV validation is
ok, a webExtension that would check if the Certificate chains to an CA
with "granted" status in the EU-TL, could display an additional
indicator to the user.
Dimitris.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
