Re: webRequests TLS introspection API proposal

[Chris Bentzel]

+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+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.

[Chris Palmer]

+Dominic and Devlin, who may have thoughts about privacy and extensions.

You received this message because you are subscribed to the Google Groups "Security-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-dev+unsubscribe@chromium.org.

[Dominic Battre]

Hi.

Here are my thoughts:

I think that exposing identifying information to an extension that is installed by a user or admin and that has the power to do really nasty stuff (e.g. JS injection) already is ok. I don't see this as a major privacy regression. This is different from Chrome exposing this information for every user by default. I think that the WebRequest API permission is covering this case and that the extension is in charge of not abusing users' trust. So in this case, the EFF would need to decide whether they feel it reasonable to collect this potentially sensitive information. - I am writing all of this assuming that no information would be leaked that can be used to impersonate a user! Please let me know if that information is wrong.

Other thoughts from skimming the proposal:

• I would consider to make the reporting of TLS information optional and happening only if the listener's opt_extraInfoSpec (see chrome.webRequest.onCompleted.addListener(...)) gets an extra parameter to subscribe to TLS information. This is for performance reasons.
• I don't understand why the information is not presented to onErrorOccurred.

So regarding the two open questions:

"Should including this information require an extra manifest permission or should the existing webRequest permission be enough?" --> I think we don't need an extra permission unless the extensions security team considers this useful for some kind of screening of extensions using this feature. That depends on your analysis of the sensitivity.

"Does exposing information about the sent chain create a privacy risk when it may expose enterprise level MITMs which may be personally (or organizationally) identifying?" --> Yes, but I think that this privacy risk is covered by the webRequest permission. A similar privacy risk already exists for the webRequest API in general.

Best regards,

Dominic

-- 

Google Germany GmbH - Erika-Mann-Str. 33 - 80636 München - Germany

Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

[Roland Shoemaker]

Thanks for the feedback, comments inline.

On Tue, May 30, 2017 at 10:06 AM Ryan Sleevi <rsl...@chromium.org> wrote:

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)

I'd be happy with either a composed string or a simple uint16 here, I think the only real reason against using the uint16 is that it means any extension that wants to stringify it has to implement something similar to BoringSSL's SSL_CIPHER_get_rfc_name which could get a little complicated. That said the same could be said about extensions that want to decompose the string into the constituent parts.

 

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.

Re-reading the User Data Privacy section of the Developer Program Policies I agree with this interpretation, given it is probably not the most important reason for implementing this API I'll just remove this usecase from the proposal in order to not confuse people down the line. 

 

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.

On Fri, May 26, 2017 at 4:42 AM, Mike West <mk...@chromium.org> wrote:

+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+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.

--
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.

[Roland Shoemaker]

Thanks for the feedback, comments inline.

On Wed, May 31, 2017 at 2:52 AM Dominic Battre <bat...@chromium.org> wrote:

Hi.

Here are my thoughts:

I think that exposing identifying information to an extension that is installed by a user or admin and that has the power to do really nasty stuff (e.g. JS injection) already is ok. I don't see this as a major privacy regression. This is different from Chrome exposing this information for every user by default. I think that the WebRequest API permission is covering this case and that the extension is in charge of not abusing users' trust. So in this case, the EFF would need to decide whether they feel it reasonable to collect this potentially sensitive information. - I am writing all of this assuming that no information would be leaked that can be used to impersonate a user! Please let me know if that information is wrong.

Other thoughts from skimming the proposal:

• I would consider to make the reporting of TLS information optional and happening only if the listener's opt_extraInfoSpec (see chrome.webRequest.onCompleted.addListener(...)) gets an extra parameter to subscribe to TLS information. This is for performance reasons.

I think this is a good idea, given that this will involve passing around relatively large buffers containing DER it is probably only something we should expose to extensions that actually make use of the provided information.

 

• I don't understand why the information is not presented to onErrorOccurred.

I want to say that in the past Sleevi (feel free to correct me, my memory is pretty vague on this point) had voiced issues with providing information in the cases of validation errors as it would provide extensions a opportunity to be less than helpful (or in the worst case actively malicious in attempting to work around invalid or untrusted certificates). That said I think there is value in providing information on both onCompleted and onErrorOccurred, but only if we can resolve the potential issues with misbehaving extensions.

 

 

-mike

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.

--
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/CAHC0%3DGM%3DikXOG42JkSxgcOwSNHU%2BKmOG4BXLhjzDSO33tw0onw%40mail.gmail.com.

--

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

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

[Ryan Sleevi]

On Mon, Jun 5, 2017 at 8:17 PM, Roland Shoemaker
<rolands...@gmail.com> wrote:
> Thanks for the feedback, comments inline.
>
> On Wed, May 31, 2017 at 2:52 AM Dominic Battre <bat...@chromium.org> wrote:
>>
>> I don't understand why the information is not presented to
>> onErrorOccurred.
>
>
> I want to say that in the past Sleevi (feel free to correct me, my memory is
> pretty vague on this point) had voiced issues with providing information in
> the cases of validation errors as it would provide extensions a opportunity
> to be less than helpful (or in the worst case actively malicious in
> attempting to work around invalid or untrusted certificates). That said I
> think there is value in providing information on both onCompleted and
> onErrorOccurred, but only if we can resolve the potential issues with
> misbehaving extensions.

Apologies for letting this thread drop.

Correct - in the presence of onErrorOccurred, more information about
the system and user is possible to be disclosed.

That said, given the existence of the Chrome Sockets API, an extension
or application that has access to the sockets API can leverage
something like a JS TLS stack (e.g.
https://github.com/digitalbazaar/forge ) and thus obtain this
information anyways. So perhaps this is, pragmatically, less of a
concern.

[Roland Shoemaker]

I've worked on a short PR that introduces an extension to the onCompletedOptions enum so extensions that don't care about TLS info don't have to worry about large extraneous objects being added to their details object, would be interested in thoughts: https://github.com/EFForg/webrequest-tlsinfo-api/pull/15.

I think offering this information on onErrorOccurred would definitely be interesting but I think it also butts up against the issues you've previously discussed about not wanting to present TLS error strings to extensions doesn't it? I guess we could just not provide that information but I think that is what most developers are going to want when using that event listener... Idk maybe that's fine?

[Roland Shoemaker]

Given there seems to be little objection to the current state of this proposal (as far as I can tell anyway) would there be any objections to starting work on a new patch that implements the proposal as it currently stands? (Once the onCompletedOptions extensions discussed above is resolved of course)

[Devlin Cronin]

From my end, I'm happy to defer to the others on this thread.  I have no problems with this at a high level for the webRequest API, but others are more familiar with the intricacies.

[Ryan Sleevi]

I think it's good to go forward from a networking point of view. I'm
not sure I know enough on the extensions implementation to be an
effective reviewer for it :)