Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Allowing WebExtensions to Override Certificate Trust Decisions
630 views
Skip to first unread message
Wayne Thayer
Feb 27, 2018, 11:21:03 AM2/27/18
to mozilla-dev-security-policy
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
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
Alex Gaynor
Feb 27, 2018, 11:23:37 AM2/27/18
to Wayne Thayer, mozilla-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
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
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
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
jomo
Feb 27, 2018, 11:45:06 AM2/27/18
to dev-secur...@lists.mozilla.org
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
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
Ryan Sleevi
Feb 27, 2018, 12:14:01 PM2/27/18
to Alex Gaynor, mozilla-dev-security-policy, Wayne Thayer
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-secur...@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 <
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-secur...@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 <
> > [3] https://mail.mozilla.org/pipermail/dev-addons/2018-
> > February/003629.html
> > [4] https://mail.mozilla.org/pipermail/dev-addons/2018-
> > February/003641.html
> > February/003629.html
> > [4] https://mail.mozilla.org/pipermail/dev-addons/2018-
> > February/003641.html
Matthew Hardeman
Feb 27, 2018, 2:55:09 PM2/27/18
to Alex Gaynor, mozilla-dev-security-policy, Wayne Thayer
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.
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.
Tim Hollebeek
Feb 27, 2018, 3:19:01 PM2/27/18
to Wayne Thayer, mozilla-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
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
Hanno Böck
Feb 27, 2018, 5:26:56 PM2/27/18
to dev-secur...@lists.mozilla.org
Hi,
On Tue, 27 Feb 2018 09:20:33 -0700
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
On Tue, 27 Feb 2018 09:20:33 -0700
> 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
> 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.
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
Peter Saint-Andre
Feb 27, 2018, 5:40:33 PM2/27/18
to Hanno Böck, dev-secur...@lists.mozilla.org
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
> <dev-secur...@lists.mozilla.org> 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
> Hi,
>
> On Tue, 27 Feb 2018 09:20:33 -0700
> Wayne Thayer via dev-security-policy
> <dev-secur...@lists.mozilla.org> 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?
powerful footgun.
Peter
Wayne Thayer
Feb 27, 2018, 6:15:47 PM2/27/18
to Peter Saint-Andre, dev-secur...@lists.mozilla.org, Hanno Böck
On Tue, Feb 27, 2018 at 3:40 PM, Peter Saint-Andre via dev-security-policy <
dev-secur...@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
> > <dev-secur...@lists.mozilla.org> 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
dev-secur...@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
> > <dev-secur...@lists.mozilla.org> 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?
>
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.
>
cert" and by "upgrade" he meant "indicate a valid cert in the UI when
validation has failed".
Peter Saint-Andre
Feb 27, 2018, 6:18:58 PM2/27/18
to Wayne Thayer, dev-secur...@lists.mozilla.org, Hanno Böck
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 <dev-secur...@lists.mozilla.org
> On Tue, Feb 27, 2018 at 3:40 PM, Peter Saint-Andre via
> dev-security-policy <dev-secur...@lists.mozilla.org
> <mailto:dev-secur...@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
> > <dev-secur...@lists.mozilla.org
>
> 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
> > <dev-secur...@lists.mozilla.org
> <mailto:dev-secur...@lists.mozilla.org>> 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. :)
> >
> >> 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".
Peter
Ryan Sleevi
Feb 27, 2018, 6:52:59 PM2/27/18
to Wayne Thayer, MDSP, Hanno Böck, Peter Saint-Andre
On Tue, Feb 27, 2018 at 6:15 PM, Wayne Thayer via dev-security-policy <
dev-secur...@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
dev-secur...@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.
>
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.
Jakob Bohm
Feb 27, 2018, 7:59:33 PM2/27/18
to mozilla-dev-s...@lists.mozilla.org
(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
Dimitris Zacharopoulos
Feb 28, 2018, 4:45:56 AM2/28/18
to ry...@sleevi.com, Wayne Thayer, MDSP, Hanno Böck, Peter Saint-Andre
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
This reminds me of "Enterprise level" decisions where some custom
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
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.
Kurt Roeckx
Feb 28, 2018, 6:46:28 AM2/28/18
to mozilla-dev-s...@lists.mozilla.org
On 2018-02-27 17:23, Alex Gaynor 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've seen extensions give a dialog box about an error and asking the
> 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.
user what to do in case the extensions thinks it's an invalid
certificate by firefox say it's ok. But I think those dialogs actually
happen after the connection has been set up and maybe even already
closed. Adding them as part of the validation might cause delays and
errors in some circumstances, which is why OCSP currently has a timeout.
Kurt
Tom Ritter
Feb 28, 2018, 11:54:55 AM2/28/18
to Alex Gaynor, mozilla-dev-security-policy, Wayne Thayer
On 27 February 2018 at 10:23, Alex Gaynor via dev-security-policy
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-secur...@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.
I'm obviously the person who filed that bug and began this discussion,
> 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.
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
Ryan Sleevi
Feb 28, 2018, 1:14:28 PM2/28/18
to Tom Ritter, Alex Gaynor, mozilla-dev-security-policy, Wayne Thayer
On Wed, Feb 28, 2018 at 11:54 AM, Tom Ritter via dev-security-policy <
dev-secur...@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
dev-secur...@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.
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".
>
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.
Alex Gaynor
Feb 28, 2018, 1:42:25 PM2/28/18
to Tom Ritter, mozilla-dev-security-policy, Wayne Thayer
If the "fail verification only" option is not viable, I personally think we
shouldn't expose this to extensions.
I don't think the ability to experiment with new trust models for the web
is worth the price we'd be paying in malicious-extension risk, in
fracturing the ecosystem risk, or in general complexity risk.
Alex
On Wed, Feb 28, 2018 at 11:54 AM, Tom Ritter <t...@ritter.vg> wrote:
> On 27 February 2018 at 10:23, Alex Gaynor via dev-security-policy
> <dev-secur...@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.
>
> 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.
>
shouldn't expose this to extensions.
I don't think the ability to experiment with new trust models for the web
is worth the price we'd be paying in malicious-extension risk, in
fracturing the ecosystem risk, or in general complexity risk.
Alex
On Wed, Feb 28, 2018 at 11:54 AM, Tom Ritter <t...@ritter.vg> wrote:
> On 27 February 2018 at 10:23, Alex Gaynor via dev-security-policy
> <dev-secur...@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.
>
> 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
> DNSSEC-Stapling) - every single one of them would not actually allow
> experimenting with Server Authentication modes if all they could do is
> 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".
>
>
> 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".
>
>
Ryan Hurst
Feb 28, 2018, 8:32:27 PM2/28/18
to mozilla-dev-s...@lists.mozilla.org
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.
> If the "fail verification only" option is not viable, I personally think we
> shouldn't expose this to extensions.
>
Ryan Hurst
Wayne Thayer
Mar 2, 2018, 12:19:30 PM3/2/18
to mozilla-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
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
Andrew
Mar 3, 2018, 3:59:00 PM3/3/18
to mozilla-dev-s...@lists.mozilla.org
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?
0 new messages