Exposing SSLStatus to WebExtensions (and possibly extending it)

[Giorgio Maone]

Hello everybody,

In https://bugzilla.mozilla.org/show_bug.cgi?id=1322748#c4 David Keeler
suggested to bring this issue up in a public forum in order to decide
how and how much to expose of the nsISSLStatus interface and its
dependencies to WebExtensions, considering that many Firefox add-ons use
it either to provide enhanced security UIs or to enforce stricter
security policies tailored on specific use cases.

Additionally, exposing also ECDHE/DHE parameters has been asked for the
same reasons ( https://bugzilla.mozilla.org/show_bug.cgi?id=1312195 ).

The most natural place to provide WebExtensions with this data is, IMHO,
in webRequest.onBeforeSendHeaders or in an ad-hoc event (onConnect?)
which needs anyway to be called before any HTTPS payload is actually
exchanged on the wire.

Personally (i.e. for the purposes of the Tails Download and Verify
Extension which I maintain) I would be fine with a thin wrapper over
nsISSLStatus and nsIX509Cert, but platform developers, security guys and
other add-ons authors likely have different but hopefully reconcilable
views on this matter, therefore I'm cross-posting to dev-platform,
dev-security and dev-addons hoping for the best outcome.

Cheers

--
Giorgio Maone
https://maone.net

[pubkeypin]

Giorgio Maone:
> Hello everybody,

Thank you for starting the discussion Giorgio.

> In https://bugzilla.mozilla.org/show_bug.cgi?id=1322748#c4 David Keeler
> suggested to bring this issue up in a public forum in order to decide
> how and how much to expose of the nsISSLStatus interface and its
> dependencies to WebExtensions, considering that many Firefox add-ons use
> it either to provide enhanced security UIs or to enforce stricter
> security policies tailored on specific use cases.

My add-on "PubKeyPin" works with the raw certificates of the whole chain
for each network connection.

The preparsed values offered by nsISSLStatus and nsIX509Cert are used
and nsIASN1Sequence and nsIASN1Object must be utilized to access the not
directly provided parts of the certificates - for example the subject
public key info.

It would be nice, if the new API gives direct access to all values of
all certificates, that are used in each network connection.

[...]

> The most natural place to provide WebExtensions with this data is, IMHO,
> in webRequest.onBeforeSendHeaders or in an ad-hoc event (onConnect?)
> which needs anyway to be called before any HTTPS payload is actually
> exchanged on the wire.

>From a security point of view, the most important secure connections are
the ones initiated by the browser itself in the background (update
checks, blocklist request, safebrowsing list retrieval, file downloads,
...).

If they can't be controlled or evaluated, stricter security rules
implemented via add-ons for "minor" webrequests are "flawed" from the
beginning.

To be able to warn the user about something suspicious in the "browser
area" or to tighten the used security settings or allowed certificates,
I would like to have at least read access to these connections, too.
That is, if i'm correct, currently not possible with "webRequest".

> Personally (i.e. for the purposes of the Tails Download and Verify
> Extension which I maintain) I would be fine with a thin wrapper over
> nsISSLStatus and nsIX509Cert, but platform developers, security guys and
> other add-ons authors likely have different but hopefully reconcilable
> views on this matter, therefore I'm cross-posting to dev-platform,
> dev-security and dev-addons hoping for the best outcome.

Some things, not directly related to nsISSLStatus, that "PubKeyPin" and
possibly others need something equivalent for before thinking about
porting to WebExtensions are OS.File, nsICryptoHash or the
nsIDOMWindowUtils and nsIWebProgress.

> Cheers

All the best,
pubkeypin

--
OpenPGP Fingerprint
2003 8F71 6157 C7CC 13F6 355E B9AA 110C E8BC D29C

[Martin Thomson]

I think that it is reasonable to expose this sort of information to
web extensions, and - for some things - possibly even to the web.

I don't think that we should start with nsISSLStatus directly. Though
it does have some relevant values, we should be careful to specify -
and justify - individual values. A short list of the things you care
about and a reason for each would be quite helpful.

On Fri, Jan 27, 2017 at 4:44 AM, Giorgio Maone <gio...@maone.net> wrote:
> Hello everybody,

>
> In https://bugzilla.mozilla.org/show_bug.cgi?id=1322748#c4 David Keeler
> suggested to bring this issue up in a public forum in order to decide
> how and how much to expose of the nsISSLStatus interface and its
> dependencies to WebExtensions, considering that many Firefox add-ons use
> it either to provide enhanced security UIs or to enforce stricter
> security policies tailored on specific use cases.
>

> Additionally, exposing also ECDHE/DHE parameters has been asked for the
> same reasons ( https://bugzilla.mozilla.org/show_bug.cgi?id=1312195 ).
>

> The most natural place to provide WebExtensions with this data is, IMHO,
> in webRequest.onBeforeSendHeaders or in an ad-hoc event (onConnect?)
> which needs anyway to be called before any HTTPS payload is actually
> exchanged on the wire.
>

> Personally (i.e. for the purposes of the Tails Download and Verify
> Extension which I maintain) I would be fine with a thin wrapper over
> nsISSLStatus and nsIX509Cert, but platform developers, security guys and
> other add-ons authors likely have different but hopefully reconcilable
> views on this matter, therefore I'm cross-posting to dev-platform,
> dev-security and dev-addons hoping for the best outcome.
>

> Cheers
>
> --
> Giorgio Maone
> https://maone.net
>
>

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform