Re: Allowing WebExtensions to Override Certificate Trust Decisions

[Andrew via dev-security-policy]

On Wednesday, February 28, 2018 at 7:32:27 PM UTC-6, Ryan Hurst wrote:
> On Wednesday, February 28, 2018 at 10:42:25 AM UTC-8, Alex Gaynor wrote:
> > If the "fail verification only" option is not viable, I personally think we
> > shouldn't expose this to extensions.
> > 
> 
> I agree, there are far too many ways this will be abused and the cases in 
> which it would be useful are not worth the negative consequences to the 
> average browser user, at least in my opinion.
> 
> Ryan Hurst

What new risks would this expose users to that they are not already exposed to 
via the webRequest permission and the 
https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/tabs/executeScript
 API?

It seems to me that extensions can already get pretty much full control of the 
user's browsing experience. Is possibly enabling MITM _really_ any worse than 
that?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Allowing WebExtensions to Override Certificate Trust Decisions

[Wayne Thayer via dev-security-policy]

Thanks everyone for your input on this topic. The consensus seems to be
that allowing WebExtensions to muck with certificate validation decisions
is a bad idea. The bug [1] has been updated with that sentiment and a link
to this discussion.

- Wayne

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1435951
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Allowing WebExtensions to Override Certificate Trust Decisions

[Ryan Hurst via dev-security-policy]

On Wednesday, February 28, 2018 at 10:42:25 AM UTC-8, Alex Gaynor wrote:
> If the "fail verification only" option is not viable, I personally think we
> shouldn't expose this to extensions.
> 

I agree, there are far too many ways this will be abused and the cases in which 
it would be useful are not worth the negative consequences to the average 
browser user, at least in my opinion.

Ryan Hurst
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Allowing WebExtensions to Override Certificate Trust Decisions

[Ryan Sleevi via dev-security-policy]

On Wed, Feb 28, 2018 at 11:54 AM, Tom Ritter via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> Of the examples I gave (Cert Patrol, Perspectives, Convergence, DANE,
> DNSSEC-Stapling) - every single one of them would not actually allow
> experimenting with Server Authentication modes if all they could do is
> reject certificates and not accept them.


Yup. And I think it's a policy/product question whether experimenting with
such methods is the right thing. Would extensions be given control over
sandboxing (i.e. when something runs sandboxed and what it can/can't do)?
If not, the arguments that apply there apply here. If so, then there's no
limit to what extensions can do, so it's a moot point.

Similarly, would there be extension APIs for manipulation of the trust
store? If so, then such an extension can always add a global 'dummy' CA
with a shared key (that is, the "Convergence CA" or the "DANE CA"). This
model would be such that any domain that wanted to experiment with protocol
'foo' - e.g. DANE - could sign a certificate using this root, causing it to
be accepted by Firefox - and then use the 'negative' API to implement
whatever protocol changes they want. Thus, the ability for extensions to
modify trust anchors is fundamentally equivalent to the ability to
positively grant trust.

However, I think the argument for these protocols is further weakened by
asking whether extensions should be able to control/add TLS extensions, as
some of these protocols may require (think TACK -
http://tack.io/draft.html#anchor5 ). If not, then such an API doesn't
"really" allow experimentation with the trust ecosystem. If not, then the
argument that it can be used to experiment with alternative PKI trust
models doesn't really hold - or, at least, it holds that some trust models
are better than other.

I do not think it's good for the ecosystem and interoperability to support
these sorts of experimentation in the Web Platform. The risks to users are
significant, the ability to make an informed decision is extremely scarce,
and the benefits of these experiments only work if they're done at scale -
which inherently means fragmenting the trust model of the ecosystem,
introducing more errors (which may further desensitize users), or weakening
baseline security assurances that sites and users have to to rely on.

It's very much Firefox's call, but Chrome's consistently rejected these,
due to the security risks to users, the ecosystem risks to site operators,
and the fundamental undermining of the web security model that such APIs
would necessarily introduce.


> And in many cases, it will
> completely prevent any such experimentation, because you can't ask a
> CA to sign a cert saying "No really, I just want you to include this
> weird data under this weird not-documented/not-standardized x509
> extension".
>

To be fair, this is not entirely accurate. Yes, it's totally true that if
it's not documented, you're SOL - but I would argue argue that if it's not
documented, *no one* should be relying on it, extension APIs or not.

Regarding not-standardized, that's not a requirement, per the Baseline
Requirements. The relevant section is 7.1.2.4, and it does permit
experimentation - within the bounds of reason, safety, and
interoperability. The onus is on the CA (and, if it's the Subscriber trying
to convince the CA, the Subscriber), to convince the ecosystem that it
meets those criteria. If they can't do that, then it seems exactly the sort
of thing that would prevent risk to Mozilla users as well.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Allowing WebExtensions to Override Certificate Trust Decisions

[Tom Ritter via dev-security-policy]

On 27 February 2018 at 10:23, Alex Gaynor via dev-security-policy
 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.

I'm obviously the person who filed that bug and began this discussion,
but I think this compromise is one of those compromises where no one
gets what they want.

Firefox gets a complicated API that gets shimmed into
security-sensitive code and can disrupt TLS handshakes.

Web Extension developers get something that doesn't do the most
valuable thing they would like to do: experiment with new Server
Authentication modes.

Of the examples I gave (Cert Patrol, Perspectives, Convergence, DANE,
DNSSEC-Stapling) - every single one of them would not actually allow
experimenting with Server Authentication modes if all they could do is
reject certificates and not accept them. And in many cases, it will
completely prevent any such experimentation, because you can't ask a
CA to sign a cert saying "No really, I just want you to include this
weird data under this weird not-documented/not-standardized x509
extension".


Unless people show up claiming that that functionality is sufficient
for them to do things they want to do; I don't think it would be
valuable to implement this compromise.

-tom
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Allowing WebExtensions to Override Certificate Trust Decisions

[Dimitris Zacharopoulos via dev-security-policy]

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

Re: Allowing WebExtensions to Override Certificate Trust Decisions

[Jakob Bohm via dev-security-policy]

On 27/02/2018 17:20, Wayne Thayer 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



How about allowing the WebExtensions to only request a worse result
(failure/lower trust) and to forcibly mark the origin (extension name)
of such restriction in the internal state and UI?

For example, an extension could mark lack of CT as non-EV (i.e. not
green).  Or it could completely fail certificates found in some CRL
representation.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Allowing WebExtensions to Override Certificate Trust Decisions

[Ryan Sleevi via dev-security-policy]

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

Re: Allowing WebExtensions to Override Certificate Trust Decisions

[Peter Saint-Andre via dev-security-policy]

On 2/27/18 4:15 PM, Wayne Thayer wrote:
> On Tue, Feb 27, 2018 at 3:40 PM, Peter Saint-Andre via
> dev-security-policy  > wrote:
> 
> On 2/27/18 3:26 PM, Hanno Böck via dev-security-policy wrote:
> > Hi,
> >
> > On Tue, 27 Feb 2018 09:20:33 -0700
> > Wayne Thayer via dev-security-policy
> >  > wrote:
> >
> >> 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.
> >
> > Wouldn't be a good compromise to say: Extensions can downgrade
> > security, but they can't upgrade it?
> 
> 
> 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.
> 
> 
> Don't you mean the other way around? Otherwise, we're creating a
> powerful footgun.
> 
> I assume that by "downgrade", Hanno meant "change the UI to indicate a
> bad cert" and by "upgrade" he meant "indicate a valid cert in the UI
> when validation has failed".

OK, we're all in agreement but using opposite terminology. :)

Peter



signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Allowing WebExtensions to Override Certificate Trust Decisions

[Wayne Thayer via dev-security-policy]

On Tue, Feb 27, 2018 at 3:40 PM, Peter Saint-Andre via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 2/27/18 3:26 PM, Hanno Böck via dev-security-policy wrote:
> > Hi,
> >
> > On Tue, 27 Feb 2018 09:20:33 -0700
> > Wayne Thayer via dev-security-policy
> >  wrote:
> >
> >> 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.
> >
> > Wouldn't be a good compromise to say: Extensions can downgrade
> > security, but they can't upgrade it?
>

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.

>
> Don't you mean the other way around? Otherwise, we're creating a
> powerful footgun.
>
> I assume that by "downgrade", Hanno meant "change the UI to indicate a bad
cert" and by "upgrade" he meant "indicate a valid cert in the UI when
validation has failed".
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Allowing WebExtensions to Override Certificate Trust Decisions

[Peter Saint-Andre via dev-security-policy]

On 2/27/18 3:26 PM, Hanno Böck via dev-security-policy wrote:
> Hi,
> 
> On Tue, 27 Feb 2018 09:20:33 -0700
> Wayne Thayer via dev-security-policy
>  wrote:
> 
>> 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.
> 
> Wouldn't be a good compromise to say: Extensions can downgrade
> security, but they can't upgrade it?

Don't you mean the other way around? Otherwise, we're creating a
powerful footgun.

Peter




signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Allowing WebExtensions to Override Certificate Trust Decisions

[Hanno Böck via dev-security-policy]

Hi,

On Tue, 27 Feb 2018 09:20:33 -0700
Wayne Thayer via dev-security-policy
 wrote:

> 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.

Wouldn't be a good compromise to say: Extensions can downgrade
security, but they can't upgrade it?
I.e. if a certificate is valid according to "normal" WebPKI validation
but there's an additional validation mechanism that fails the extension
could say "tread this like an untrusted cert", but it couldn't say
"our positive validation of that cert overrides the normal validation".

Is there any existing use case that would not work with that?

As far as I can see and if I understand it right all of those examples
should be able to work on top of existing validation.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Allowing WebExtensions to Override Certificate Trust Decisions

[Tim Hollebeek via dev-security-policy]

Wow, this is a tough one.  I've wanted to write such an extension myself for
quite some time.  In fact, I probably would write one or more extensions, if 
Mozilla were to allow this, for a variety of use cases.
 
That said, such extensions are extremely dangerous, and users are just going
to accept any warning that might exist about using such an extension.  But I
don't think designing for the ignorant and clueless is wise.  You'll just find
better idiots.

I personally find persuasive the argument that an extension already has the
ability to do equivalently bad things.  The research group I used to work with
many years ago did lots of work with application extensions of all kinds, and
web extensions in particular were obscenely powerful because of the very
rich structure of the Document Object Model.

I'm sure (I hope!) things have been tightened up at least a little bit since 
then,
but I think in the presence of a malicious extension, the question of whether
it can affect the connection UI is rather moot.  Naïve users are going to lose
to a malicious extension every time, no matter what, and I seriously doubt
that even sophisticated users will have much of a chance in such scenarios,
whether the connection UI can be changed by the extension, or not.

It's probably useful to discuss this in conjunction with what controls Mozilla
has available in its ecosystem to combat malicious extensions in general,
as opposed to this particular case, which doesn't seem to be very special.
That more general question might lead to good principles that can be
applied in this specific situation.

Basically, I think it's a question of what the security model/policy for
extensions should be, how to balance the risks vs benefits of various pieces of
exposed functionality.  The tension between powerful, open APIs and
limited, but safer APIs has existed forever, and there isn't one point on
the spectrum that is optimal.

We recently had a case internally where some Office automation was not
possible due to some ad hoc restrictions imposed during the ILOVEYOU
era.  Addressing security risks piecemeal instead of holistically generally
results in a random set of arbitrary restrictions instead of a coherent
security model.  Figure out what the security policy and security model
is, and it will tell you whether allowing extensions to modify the connection
UI is ok.

-Tim

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Wayne
> Thayer via dev-security-policy
> Sent: Tuesday, February 27, 2018 9:21 AM
> To: mozilla-dev-security-policy 
> 
> Subject: Allowing WebExtensions to Override Certificate Trust Decisions
> 
> 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
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Allowing WebExtensions to Override Certificate Trust Decisions

[Matthew Hardeman via dev-security-policy]

Altering the security UI based on a third party extension seems risky in
either direction.

If a broad pinning scheme was unlikely to cause problems, HPKP would still
be a thing.  Other criteria for stricter than standard validation seem hard
to guarantee over the long haul also.

Even if a whole separate permission can be affirmatively gained from the
user at extension install/update time, the amount of UI engagement and
critical thinking from the user is significant.  Most people would just say
yes, rather than attempt to understand the risk/reward.

You could always do something ridiculous, along the lines of a "Mavis
Beacon Teaches Typing" thing which forces you to literally type in several
sentences as you read them on-screen (at a human pace -- no copy-paste)
acknowledging exactly what it is that you're granting permission to do and
how the user must be smarter than the firefox people.  In fact, the last
thing the user should have to type would be something like "I believe I am
smarter than the Firefox people, and that I can pick and choose who to
trust as well as who to delegate trust decisions to better than the Firefox
people are able.  Grant the permission."

But it seems far easier to just say no.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Allowing WebExtensions to Override Certificate Trust Decisions

[Ryan Sleevi via dev-security-policy]

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 <
dev-security-policy@lists.mozilla.org> 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 <
> dev-security-policy@lists.mozilla.org> 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
> > dev-security-policy@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
> >
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Allowing WebExtensions to Override Certificate Trust Decisions

[jomo via dev-security-policy]

IMHO it should be possible to affect the connection and the UI. This
would allow plug-ins for alternative certificate validation methods,
such as Convergence
(https://en.wikipedia.org/wiki/Convergence_%28SSL%29) / FreeSpeechMe
(https://bit.namecoin.org/freespeechme.html).

While I agree that it is a potentially dangerous capability, a bad
extension can already gain full access to a secure website's content.
Possibly the UI could reflect that an extension has changed the normal
validation result?

- jomo

On 27.2.18 17:20, Wayne Thayer via dev-security-policy 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
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Allowing WebExtensions to Override Certificate Trust Decisions

[Alex Gaynor via dev-security-policy]

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 <
dev-security-policy@lists.mozilla.org> 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
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy