WebExtensions should be able to override certificate verification decisions

ASSIGNED
Assigned to

Status

P5
normal
ASSIGNED
a year ago
3 months ago

People

(Reporter: braydenpeterson, Assigned: mconca)

Tracking

Trunk

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

a year ago
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20100101

Steps to reproduce:

Some WebExtensions use cases require being able to override certificate verification decisions.  Some examples of such use cases are Convergence, DANE, Namecoin, and certificate pinning.

This bug was originally part of Bug 1322748, but I've been asked to split out this part of the bug, because certificate verification overrides cover relatively distinct parts of the codebase compared to retrospective certificate information in WebRequest, which is what Bug 1322748 will now focus on.  Please see Bug 1322748 for the full context.


Actual results:

WebExtensions currently cannot influence certificate verification decisions.


Expected results:

WebExtensions should have the ability to perform positive overrides (making a certificate be accepted when it would normally be rejected) and negative overrides (making a certificate be rejected when it would normally be accepted).
We're going to have to think about whether this capability should be exposed, possibly getting security + necko members involved.
Whiteboard: [design-decision-needed]
I started a conversation on dev-addons about this. https://mail.mozilla.org/pipermail/dev-addons/2018-February/003629.html
(Assignee)

Comment 3

a year ago
Let's take this one outside of the normal design-decision review process and do a thorough review, both from a security standpoint and a WebExtensions policy standpoint.

Comment 4

a year ago
I think this is a valid, useful feature.

it's a feature that could stay in the test pilot section though (for advanced users)

how permissions could be handled:
Don't ask on install, only mention that it has the capability.
Ask the first time, it tries to influence Firefox's decision
the addon could offer a text as an explanation to the user (has to be placed in a way, that it is clear, that the message doesn't come from Firefox itself)

offer the user the choices: report addon/developer, accept once, accept always (greyed out the first time it happens, so the user has to accept the same dialogue twice, as an additional protection maybe)
Granting perimission for blocking and verifying certs could be separated, since the implications are different (2 dialogues for each)

Addons in the store should go through specific validation of the code and the dev behind it.


Another question, one I cannot answer:
How do you verify the database of the addon, if it is not available? (online somewhere)
That's why it should be important to verify the dev behind the addon.

Firefox should get a blocklist, so it can revoke addons (uninstall from users browser), if they start causing harm. (might be in-place already?)


I don't think this should override decision on certs that reached their scheduled expiration date or are on the CRL. (at least I can't think of a valid reason to do so)
Verifying/blocking unverified certs, valid certs, invalid certs should be possible

I could have made totally wrong assumptions (on security) here, I'm mostly a user.
If my suggestions don't make sense, then that's ok for me.

I just wanted to provide some input, that might be helpful.

Regards

Comment 5

a year ago
Rewording the title of the bug to "WebExtensions should be able to block/veto positive certificate verification decisions" (or similar) may be useful. The reference to "override" may have the connotation (before people read the excellent description), that cases where Firefox has blocked an unsafe CA may be re-enabled through the new API.

Personally, what I want to be able to do with WebExtensions is what I could previously do with CertPatrol to block/veto unexpected certificate changes for hosts. The extreme use case is untrusted networks getting access to a valid secondary CA for MiTM. However, there are also other cases where the root CA/chain had already been verified by Firefox to be cryptographically sound, but there was still an overriding concern from CertPatrol that previous instances had some historical anomalies that the user has opted into seeing before connections were completed to be able to veto them.
If the intent is merely to tighten more than firefox does already (ie. block things firefox wouldn't) then I don't think any additional api is necessary on top of having access to cert data.  There may well be optimizations that would make that better, but it should be do-able with the patch I'm working on in bug 1322748.
Whiteboard: [design-decision-needed]
(In reply to Shane Caraveo (:mixedpuppy) from comment #6)
> If the intent is merely to tighten more than firefox does already (ie. block
> things firefox wouldn't) then I don't think any additional api is necessary
> on top of having access to cert data.  There may well be optimizations that
> would make that better, but it should be do-able with the patch I'm working
> on in bug 1322748.

No, I am explicitly interested in allowing successful HTTPS validation to occur based on mechanisms other than CA certificates. So that's being looser than what Firefox does already.
As a security-conscious user, I feel compelled to echo the previous comment and to re-iterate that the original goal as stated by the bug reporter is not only "merely to tighten more than firefox does already" but also "making a certificate be accepted when it would normally be rejected". I fully understand that this sounds scary, but I believe it is critical to enabling the use cases mentioned above.

Using the one I'm most familiar with as an example, DANE (RFC6698) provides 4 ways for a domain operator to specify certificate usage, 2 of which categorically override any built-in trust anchors[1]. The first (usage 2) allows a new trust anchor to be specified (e.g. an organisation using their own CA infrastructure), the other (usage 3) allows a self-signed certificate to be specified. Both of these usages require both positive override and negative override of the normal trust decision to be possible depending on whether or not the certificate received in the TLS handshake matches the one stored in the TLSA DNS record.

Furthermore, the patch in bug 1322748 does not provide the opportunity for an addon to abort the TLS connection before application data (HTTP headers) have been sent, potentially leaking secure cookies or other private information. This ability is paramount for example if a user is to be protected from a malicious man-in-the-middle who has somehow obtained a certificate that is trusted by the browser[2] but which an addon is able to detect is untrusted through other means, such as a web of trust (like Convergence mentioned above, Perspectives, or EFF's SSL Observatory) or even DANE, etc.

[1] https://tools.ietf.org/html/rfc6698#section-2.1.1
[2] https://www.theregister.co.uk/2011/09/06/diginotar_audit_damning_fail/
Assignee: nobody → mconca
Priority: -- → P5
Arguments in support of allowing WebExtension to override negative certificate verification decisions:
* Legacy add-ons had this ability
* It enables experimentation with new security mechanisms like DANE
* It gives advanced users more control over their security decisions

Arguments against:
* It's easy to abuse
* It adds complexity to a critical security mechanism

I think we need to determine how we can allow both positive and negative overrides while making it very clear to the user, along the lines of what Franziskus suggested here: https://mail.mozilla.org/pipermail/dev-addons/2018-February/003641.html We shouldn't allow override of the nav bar UI, but we should allow a WebExtension to achieve the same effect as adding a security exception for a website after receiving consent from the user.
I asked the community to comment on this on the mozilla.dev.security.policy list. The thread can be found at https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/yyzRatMijpE

A fairly strong consensus is emerging that this is a bad idea.
(Assignee)

Comment 11

a year ago
:wayne thank you for the pointer to that discussion. The consensus seems to be that a limited version of this API is too limited to be used for any meaningful experimentation, while a full version of the API is powerful enough to introduce significant security vulnerabilities. Trying to find a compromise quickly introduces large amounts of complexity that may not satisfy anyone.

Mozilla is a protector of security and privacy, and enabling features that allow experimentation with alternate, perhaps improved security models is a worthy goal. But we can't weaken the existing security model to get there, so WebExtensions are probably not the right way to do this.
(Reporter)

Comment 12

a year ago
(In reply to Peter Ansell from comment #5)
> Rewording the title of the bug to "WebExtensions should be able to
> block/veto positive certificate verification decisions" (or similar) may be
> useful. The reference to "override" may have the connotation (before people
> read the excellent description), that cases where Firefox has blocked an
> unsafe CA may be re-enabled through the new API.

As Tom Ritter and Will Elwood pointed out, I created this bug with the intent of covering both positive overrides and negative overrides, not only negative overrides.  And as Will pointed out, it is a security requirement that, if a WebExtension chooses to reject a certificate, no private data (such as HTTP headers or TLS client certificates) should leak to the MITM attacker.

If a consensus emerges in favor of splitting positive overrides and negative overrides into separate bugs, I wouldn't object to that.  (But I don't see evidence of such a consensus yet.)

(In reply to Wayne Thayer [:wayne] from comment #10)
> I asked the community to comment on this on the mozilla.dev.security.policy
> list. The thread can be found at
> https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/
> yyzRatMijpE
> 
> A fairly strong consensus is emerging that this is a bad idea.

Thanks for pointing out that discussion, I don't subscribe to that list so I didn't see it in real-time.  I'll read through it and see if I have any comments.
(Reporter)

Comment 13

a year ago
(In reply to Mike Conca [:mconca] (Denver, CO, USA UTC-6) from comment #11)
> :wayne thank you for the pointer to that discussion. The consensus seems to
> be that a limited version of this API is too limited to be used for any
> meaningful experimentation, while a full version of the API is powerful
> enough to introduce significant security vulnerabilities. Trying to find a
> compromise quickly introduces large amounts of complexity that may not
> satisfy anyone.

From Namecoin's point of view, it is plausible that we could do something productive (though the code would be a lot messier and we'd be a lot less happy) with only negative overrides.  We already have a workaround that can do positive overrides for Namecoin in Chromium without any kind of browser extension API, and it's plausible that we could accomplish something similar for Firefox.  So, I request that negative overrides not be rejected solely because of positive overrides being rejected.  Again, a solution of only allowing negative overrides *would not be desirable for us*, but it would be a lot better than rejecting both.

I can't speak for the various other use cases that want positive overrides; they may not be able to do anything useful with only negative overrides.

I'm tempted to argue that trying to deny users the ability to do useful things because malware might do bad things with such an API is an example of the DRM mindset (which I don't consider a valid mindset)... but I suspect that such a debate is not going to be productive here, so I'll instead move onto the next part of your comment to see if we can find some common ground.

> Mozilla is a protector of security and privacy, and enabling features that
> allow experimentation with alternate, perhaps improved security models is a
> worthy goal. But we can't weaken the existing security model to get there,
> so WebExtensions are probably not the right way to do this.

Thinking out loud here... you say that *WebExtensions* are probably not the right way to do this.  I'm curious, is it possible that we could do a different approach, perhaps as some kind of NSS extension mechanism instead of WebExtensions?  AFAIK, NSS already permits pkcs11-based extensions that can do positive overrides in a limited set of cases (by marking a CA as trusted).  From Namecoin's point of view, I don't think we'd have any objection to a positive+negative certificate override API being implemented as part of NSS rather than as part of WebExtensions, as long as Firefox honored those decisions by NSS.  Such an API wouldn't introduce any additional malware vectors AFAICT, since pkcs11-based positive overrides in NSS are already available to malware.

Or, for that matter, if you have any other suggestions for API types besides WebExtensions and NSS extensions that I haven't thought of, please feel free to suggest them.  I'm not committed to a particular solution at this point, I'd just like to find something that works.  :)

Cheers!

Updated

8 months ago
Product: Toolkit → WebExtensions

Comment 14

8 months ago
Now that bug 1322748 is complete, it may be useful to explore this issue again. In particular, what exactly was implemented during that issue in relation to web extensions and the TLS handshake sequence that could refine the scope of this issue?

This issue has two distinct issues inside of it that we have so far been reluctant to split up:

The first is adding the possibility of replacing or modifying certificate/security information to support DANE, NameCoin, and other alternatives to the CA model. That is a large change that increases the security footprint of the WebExtension API (which could be useful if users are informed about it), but it is independent of the second issue.

The second is simply to deny and abort connections using a WebExtension if they don't match an internal rule or the user of the browser chooses not to continue with the connection after seeing the TLS handshake details. If the functionality added in bug 1322748 already supports this together with `BlockingResponse.cancel` (or `BlockingResponse.redirectUrl`) that is great, but it isn't completely clear what was implemented at this point in relation to this issue.
(Reporter)

Comment 15

7 months ago
(In reply to Peter Ansell from comment #14)
> Now that bug 1322748 is complete, it may be useful to explore this issue
> again. In particular, what exactly was implemented during that issue in
> relation to web extensions and the TLS handshake sequence that could refine
> the scope of this issue?
> 
> This issue has two distinct issues inside of it that we have so far been
> reluctant to split up:
> 
> The first is adding the possibility of replacing or modifying
> certificate/security information to support DANE, NameCoin, and other
> alternatives to the CA model. That is a large change that increases the
> security footprint of the WebExtension API (which could be useful if users
> are informed about it), but it is independent of the second issue.
> 
> The second is simply to deny and abort connections using a WebExtension if
> they don't match an internal rule or the user of the browser chooses not to
> continue with the connection after seeing the TLS handshake details. If the
> functionality added in bug 1322748 already supports this together with
> `BlockingResponse.cancel` (or `BlockingResponse.redirectUrl`) that is great,
> but it isn't completely clear what was implemented at this point in relation
> to this issue.

Assuming that the documentation [1] is accurate, the 2nd issue is not resolved by bug 1322748:

> You can only call this function from inside the webRequest.onHeadersReceived listener.

That means that by the time a WebExtension can obtain this data, the HTTP request (including login cookies) and the HTTP response headers (possibly confidential as well) have already been transmitted over the TLS connection, meaning that the hypothetical MITM attacker already obtained them.  Solving this requires presenting the data to the WebExtension *before* any HTTP data is transmitted over the TLS connection.  (It also should be done before any client certificates are transmitted during the TLS handshake, since those also may be confidential.)

[1] https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/webRequest/getSecurityInfo

Updated

6 months ago
Duplicate of this bug: 1489080
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
You need to log in before you can comment on or make changes to this bug.