Re: WebExtensions Overriding TLS Certificate Validation

[Franziskus Kiefer]

Sorry for the delay, I wasn't subscribed to the mailing list and didn't get
your reply.

Another discussion started on the security-policy mailing list [1] (thanks
Wayne for starting that). Please check that one out as well.
I cross-post this reply to the security-policy mailing list as I think this
conversion should involve both.

Franziskus Kiefer:
> > I agree with Tom that an API for WebExtensions that allows to make
> > connection trust decisions would be great (allowing all those
> experiments).
> > But I think we shouldn't allow the API to override Firefox's trust
> > decision, i.e. the green/whatevercolored lock.
>
> Please forgive my general lack of familiarity with the terminology here,
> but if I understand the above correctly, "connection trust decisions" ==
> influencing (in either direction) whether the TLS handshake succeeds
> without erroring out, and "Firefox's trust decision" == influencing the
> iconography displayed when the page loads?
>

Yeah, I think there are two levels here.
i) Does Firefox establish a connection at all and display the page content
ii) What "security level"/"trustworthiness" does Firefox give the page.

The question here is whether WebExtensions should be allowed to alter any
of them and in particular how that decision is communicated to the user.
Should a trust-decision made by an extension be communicated the same way
the decision from Firefox is communicated (with the green lock icon)? I
think it shouldn't.

To clarify my position: I think WebExtensions should be allowed to get most
information of the TLS connection to implement its own trust decision
algorithms. (I say most as I obviously wouldn't expose any secrets.) This
wouldn't allow the extension to make a connection with a self-signed
certificate valid. But it could for example add an icon next to the Firefox
lock icon adding additional information to the "security level" of the
connection such as web of trust information etc.

Cheers,
Franziskus

[1] https://groups.google.com/forum/#!topic/mozilla.dev.security
.policy/yyzRatMijpE


On Wed, Feb 7, 2018 at 11:45 AM, Franziskus Kiefer <fki...@mozilla.com>
wrote:

> I agree with Tom that an API for WebExtensions that allows to make
> connection trust decisions would be great (allowing all those experiments).
> But I think we shouldn't allow the API to override Firefox's trust
> decision, i.e. the green/whatevercolored lock.
>
> The lock icon is the only way we communicate security of a page to users.
> Giving this away to any extension is too dangerous imho. And, as Andrew
> said, giving extensions that use potentially dangerous APIs like this extra
> review doesn't scale well.
>
> Adding this API would also force us to keep the lock there (or break
> extensions), which is something that we probably don't want. HTTPS is
> supposed to become the default and the lock will probably go away
> long-term. This could potentially leave us in a position similar to the one
> we had with legacy extensions where we had to keep code around and couldn't
> move forward just to avoid breaking extensions.
>
> Adding additional UI could be a solution. Instead of allowing to change
> the lock icon we could allow adding an icon. Extensions could then enhance
> the trust decision Firefox took but not override it.
>
> Cheers,
> Franziskus
>
> On Wed, Feb 7, 2018 at 12:19 AM, Andrew Swan <as...@mozilla.com> wrote:
>
>>
>> On Tue, Feb 6, 2018 at 7:34 AM, Tom Ritter <t...@mozilla.com> wrote:
>>
>>> So I'm curious what the Web Extension experts think of this, and what
>>> the best way to gate and mitigate harm from this would be. I'm not
>>> sure what the status quo is with Web Extension permissions and manual
>>> review, and what options we have there.
>>>
>>
>> I don't have a strong opinion about this particular API (there are strong
>> arguments both for and against, which is the most difficult possible
>> scenario :/)
>>
>> However, I can say that we've deliberately moved away from using "we'll
>> just give extensions that use this API extra close scrutiny during
>> review". Somebody like Andreas or Jorge can probably explain the reasoning
>> for that better than I can but I think that essentially it doesn't work at
>> scale, plus it isn't clear how unlisted extensions should be handled.
>>
>> Its not a direct replacement, but when creating new APIs we have tried
>> hard to design them in a way that it is clear to users when an extension
>> has (or might have) affected something and the user can be given an
>> opportunity to easily disable the extension if that isn't something they
>> desire. (examples of this are the doorhangers for an extension-provided
>> newtab page or the proposed UI handling for tabs hidden by extensions).
>> For TLS certificate validation, I think we would have lots of options. Off
>> the top of my head, simple options would be changing the appearance of the
>> lock icon in the location bar or displaying a notification the first time a
>> page is loaded with an extension-validated certificate. (that just
>> accounts for top level page loads, not frames or other sub-resources but
>> the same is true of the "site information" block in the location bar
>> generally...)
>>
>> I don't think I have the right background to make a concrete proposal
>> here, but for anybody interested in this API, coming up with a proposal in
>> this area would make it a lot easier to reach a decision on supporting the
>> API.
>>
>> -Andrew
>>
>>
>