webRequests TLS introspection API proposal

[Roland]

Hey all,

The last few months I've been working on and off on trying to get some level of TLS introspection added to the webRequests API. After working through a few non-viable designs and getting suggestions from a number of internal and external people interested in the API we (EFF) have published a proposal document on GitHub outlining the API we'd like to see (and think is a viable option for cross browser compatibility) here: https://github.com/EFForg/webrequest-tlsinfo-api/blob/master/proposal.md.

This proposal addresses the lowest hanging fruit in terms of adding TLS introspection, it's read-only and only is available via the details object of the onComplete object and expects extensions to parse ASN.1 themselves if they actually want to locally extract information from certificates/chains. There is an argument to be made that more interactivity would be useful but I think that can only really be properly assessed once extensions have access to the most basic information to see how they would actually make use of this.

We've also had some interest in implementing this proposal (or some version of it) from the Firefox team and would like to get some level of consensus about the shape of the API change before we actually start doing anything so we don't cause a weird non-compatible schism between implementations in Chromium and Firefox... https://bugzilla.mozilla.org/show_bug.cgi?id=1322748#c24

Feedback either here or on the GitHub repo would be extremely useful!

Thanks,

Roland Bracewell Shoemaker

[Chris Bentzel]

+security-dev 

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To post to this group, send email to net...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/712e7ed9-454d-4d9f-a210-fcff09293e2e%40chromium.org.

[ناطق القره غولي‎]

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAAuiYA_Ms%2BkgE9S-pRTaJAyP7CWpvZ3E-5ZSej0e%2BD-ZjDyRCw%40mail.gmail.com.

[Mike West]

+Ryan, who has opinions. :)

-mike

On Thu, May 25, 2017 at 5:04 PM, ناطق القره غولي <hosd9...@gmail.com> wrote:

في خميس، 25 أيار، 2017 في 4:50 م، كتب Chris Bentzel <cben...@chromium.org>:

+security-dev 

On Wed, May 24, 2017 at 6:22 PM Roland <rolands...@gmail.com> wrote:

Hey all,

The last few months I've been working on and off on trying to get some level of TLS introspection added to the webRequests API. After working through a few non-viable designs and getting suggestions from a number of internal and external people interested in the API we (EFF) have published a proposal document on GitHub outlining the API we'd like to see (and think is a viable option for cross browser compatibility) here: https://github.com/EFForg/webrequest-tlsinfo-api/blob/master/proposal.md.

This proposal addresses the lowest hanging fruit in terms of adding TLS introspection, it's read-only and only is available via the details object of the onComplete object and expects extensions to parse ASN.1 themselves if they actually want to locally extract information from certificates/chains. There is an argument to be made that more interactivity would be useful but I think that can only really be properly assessed once extensions have access to the most basic information to see how they would actually make use of this.

We've also had some interest in implementing this proposal (or some version of it) from the Firefox team and would like to get some level of consensus about the shape of the API change before we actually start doing anything so we don't cause a weird non-compatible schism between implementations in Chromium and Firefox... https://bugzilla.mozilla.org/show_bug.cgi?id=1322748#c24

Feedback either here or on the GitHub repo would be extremely useful!

Thanks,

Roland Bracewell Shoemaker

--

You received this message because you are subscribed to the Google Groups "net-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+unsubscribe@chromium.org.

To post to this group, send email to net...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/712e7ed9-454d-4d9f-a210-fcff09293e2e%40chromium.org.

--

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAAuiYA_Ms%2BkgE9S-pRTaJAyP7CWpvZ3E-5ZSej0e%2BD-ZjDyRCw%40mail.gmail.com.

--

You received this message because you are subscribed to the Google Groups "net-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+unsubscribe@chromium.org.

To post to this group, send email to net...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAHC0%3DGM%3DikXOG42JkSxgcOwSNHU%2BKmOG4BXLhjzDSO33tw0onw%40mail.gmail.com.

[Ryan Sleevi]

To avoid cross-posting, I'll BCC chromium-dev@ and net-dev@, and assume the substantive conversation on security-dev@ (unless this should be redirected somewhere else for extensions), given the concerns.

I've shared early review feedback with Roland in the past, but I'm torn on whether it's appropriate - on privacy grounds - to send the sentChain and builtChain in event of TLS errors or when it chains to a local trust anchor. It may be due to not understanding the fullness of the extensions security model with respect to permissions grants, but this would reveal significantly more information - potentially down to identifying the user - that would not otherwise be accessible.

For example, Chrome's implementation of HPKP (and Expect-CT) explicitly do not report on either of these conditions, to avoid the disclosure of users' sensitive information. Roland has already noted this as an "Open Question" at the end, and while my own take is that yes, it presents a privacy risk, I don't know whether that privacy risk is acceptable. Similarly, I don't know whether the implications can be succinctly expressed in a permission grant.

Regarding the ciphersuite, while I'm inclined to suggest that this should use the TLS ciphersuite registry (a uint16), rather than the string form, this is largely because Chrome would otherwise have no need for these strings (other than user interface reasons, which can and do change from time to time)

As for the use cases, I'm not sure whether Item 1 is compliant with the Chrome WebStore's policies (my understanding is that sharing information from webRequest was a prohibited action), and I'm not sure that Item 4 is consistent with Chrome's desired/intended feature set (in as much as Chrome itself does not attempt to make this distinction, due to the ecosystem effects). Items 2, 3, and 5 seem like reasonable use cases that would suggest there is value, but these all seem somewhat tied to the privacy-sensitive aspects.

I think it would be useful to hear more from folks on Chromium who work on privacy, permissions, and extensions to share what they think about this.