Unifying the notions of "secure context" (trustworthy url/origin)

82 views
Skip to first unread message

Frédéric Wang

unread,
Jan 19, 2021, 9:22:51 AMJan 19
to blink-dev
Hello,

I've recently tried to improve consistencies of our different functions
implementing a "secure context" in Chromium [1]. I have a few CLs
pending before the remaining step in [2] but I'm almost reaching the
point where there would essentially be two definitions aligned with the
spec:

(A) https://w3c.github.io/webappsec-secure-contexts/#is-origin-trustworthy
(B)
https://w3c.github.io/webappsec-secure-contexts/#potentially-trustworthy-url

with the latter defined from the former. So far I believe I've tried to
be very careful not to cause serious web-exposed behavior changes.
However, this last step is making SecurityOrigin::IsSecure returns true
for "local URLs" (loopback address, localhost, *.localhost, file:
scheme) which is maybe not what we want in specific cases. Hence I'd
like to check whether this is ok before sending an intent. Please find
below the details of the remaining call sites affected.

* PerformanceNavigationTiming::PerformanceNavigationTiming: This is used
to implement step 1 of [3]. However, the specification refers to "secure
transport" which sounds stricter than (B).

* Performance::GenerateResourceTiming: I believe this corresponds to [4]
which relies on (B).

* Cookie Store's ToCanonicalCookie: Explainer [5] refers to "secure
origin" but I'm not exactly sure how it compares to (B). Treating local
URLs as secure breaks tests like cookie-store/set-on-localhost.html or
cookie-store/delete-on-localhost.html

* ExecutionContextCSPDelegate::GetStatusCode: It looks like this is
implementing step 4 of [6] but I'm not clear which section describes the
security check and a fortiori how it compares to (B). Treating local
URLs as secure breaks tests like
security/contentSecurityPolicy/eval-blocked-and-sends-report.php or
reporting-observer/csp.php.

Thanks,

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=1153336
[2] https://chromium-review.googlesource.com/c/chromium/src/+/2617883
[3]
https://w3c.github.io/resource-timing/#dom-performanceresourcetiming-secureconnectionstart
[4] https://w3c.github.io/server-timing/#processing-model
[5] https://wicg.github.io/cookie-store/explainer.html#the-secure-flag
[6] https://w3c.github.io/webappsec-csp/#create-violation-for-global

--
Frédéric Wang

Yoav Weiss

unread,
Jan 24, 2021, 10:59:53 PMJan 24
to Frédéric Wang, Nicolás Peña, blink-dev
On Tue, Jan 19, 2021 at 3:24 PM Frédéric Wang <fw...@igalia.com> wrote:
Hello,

I've recently tried to improve consistencies of our different functions
implementing a "secure context" in Chromium [1]. I have a few CLs
pending before the remaining step in [2] but I'm almost reaching the
point where there would essentially be two definitions aligned with the
spec:

(A) https://w3c.github.io/webappsec-secure-contexts/#is-origin-trustworthy
(B)
https://w3c.github.io/webappsec-secure-contexts/#potentially-trustworthy-url

with the latter defined from the former. So far I believe I've tried to
be very careful not to cause serious web-exposed behavior changes.
However, this last step is making SecurityOrigin::IsSecure returns true
for "local URLs" (loopback address, localhost, *.localhost, file:
scheme) which is maybe not what we want in specific cases. Hence I'd
like to check whether this is ok before sending an intent. Please find
below the details of the remaining call sites affected.

* PerformanceNavigationTiming::PerformanceNavigationTiming: This is used
to implement step 1 of [3]. However, the specification refers to "secure
transport" which sounds stricter than (B).

https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/core/timing/performance_navigation_timing.cc;l=58?q=PerformanceNavigationTiming&ss=chromium should be true only when a secure transport was used. If you're changing IsSecure to include local addresses, maybe you could modify that call site to use a new method with the old semantics?


* Performance::GenerateResourceTiming: I believe this corresponds to [4]
which relies on (B).

I believe this is similar to the above.

+Nicolás Peña - for a second set of eyes.
 

* Cookie Store's ToCanonicalCookie: Explainer [5] refers to "secure
origin" but I'm not exactly sure how it compares to (B). Treating local
URLs as secure breaks tests like cookie-store/set-on-localhost.html or
cookie-store/delete-on-localhost.html

* ExecutionContextCSPDelegate::GetStatusCode: It looks like this is
implementing step 4 of [6] but I'm not clear which section describes the
security check and a fortiori how it compares to (B). Treating local
URLs as secure breaks tests like
security/contentSecurityPolicy/eval-blocked-and-sends-report.php or
reporting-observer/csp.php.

Thanks,

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=1153336
[2] https://chromium-review.googlesource.com/c/chromium/src/+/2617883
[3]
https://w3c.github.io/resource-timing/#dom-performanceresourcetiming-secureconnectionstart
[4] https://w3c.github.io/server-timing/#processing-model
[5] https://wicg.github.io/cookie-store/explainer.html#the-secure-flag
[6] https://w3c.github.io/webappsec-csp/#create-violation-for-global

--
Frédéric Wang

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f85fe39b-e976-0939-d0af-6edc99a41161%40igalia.com.

Frédéric Wang

unread,
Jan 25, 2021, 1:48:11 AMJan 25
to Yoav Weiss, Nicolás Peña, blink-dev
On 25/01/2021 04:59, Yoav Weiss wrote:
* PerformanceNavigationTiming::PerformanceNavigationTiming: This is used
to implement step 1 of [3]. However, the specification refers to "secure
transport" which sounds stricter than (B).

https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/core/timing/performance_navigation_timing.cc;l=58?q=PerformanceNavigationTiming&ss=chromium should be true only when a secure transport was used. If you're changing IsSecure to include local addresses, maybe you could modify that call site to use a new method with the old semantics?

Thanks Yoav. Sure I can update the call sites. But just to be clear the old/current semantics of SecurityOrigin::IsSecure already includes more than "secure transport". It considers filesystem: and blob: URLs as secure, if their inner URLs use a secure scheme. And also rely on an allow list of hosts e.g. for the enterprise policy [1]. So restricting to secure transport is a behavior change which may potentially break existing pages. Even the definition of "secure transport" is vague : I understand the spec means https and wss schemes, but chromium also supports quick-transport: [2].  Note that other places such as ClientHintsPreferences::IsClientHintsAllowed do something like "url is potentially trustworthy and its scheme is https/wss" [3].

[1] https://source.chromium.org/chromium/chromium/src/+/master:services/network/public/cpp/is_potentially_trustworthy.h;l=70;drc=df165fe93fe5317f0f701ba071280199158ab2d0

[2] https://source.chromium.org/chromium/chromium/src/+/master:url/url_util.cc;l=65;drc=ce8d17ff494cf684f35c8ff64cb6bd0947adcf46

[3] https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/platform/loader/fetch/client_hints_preferences.cc;l=97;drc=709a38ffc4f8b26f49471d58334bee65b5c5de6d ; see also https://chromium-review.googlesource.com/c/chromium/src/+/2632595 for a pending change.

-- 
Frédéric Wang

Yoav Weiss

unread,
Jan 25, 2021, 9:11:01 AMJan 25
to Frédéric Wang, Nicolás Peña, blink-dev
On Mon, Jan 25, 2021 at 7:50 AM Frédéric Wang <fw...@igalia.com> wrote:
On 25/01/2021 04:59, Yoav Weiss wrote:
* PerformanceNavigationTiming::PerformanceNavigationTiming: This is used
to implement step 1 of [3]. However, the specification refers to "secure
transport" which sounds stricter than (B).

https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/core/timing/performance_navigation_timing.cc;l=58?q=PerformanceNavigationTiming&ss=chromium should be true only when a secure transport was used. If you're changing IsSecure to include local addresses, maybe you could modify that call site to use a new method with the old semantics?

Thanks Yoav. Sure I can update the call sites. But just to be clear the old/current semantics of SecurityOrigin::IsSecure already includes more than "secure transport". It considers filesystem: and blob: URLs as secure, if their inner URLs use a secure scheme.


As Resource Timing and Navigation Timing only report http* schemes, those semantics differences are not currently exposed. 

And also rely on an allow list of hosts e.g. for the enterprise policy [1].

Huh, that bit is potentially web exposed, which isn't great. 

So restricting to secure transport is a behavior change which may potentially break existing pages. Even the definition of "secure transport" is vague : I understand the spec means https and wss schemes, but chromium also supports quick-transport: [2].  Note that other places such as ClientHintsPreferences::IsClientHintsAllowed do something like "url is potentially trustworthy and its scheme is https/wss" [3].

I 100% agree that we need to improve the spec on that front. 

Frédéric Wang

unread,
Feb 1, 2021, 2:47:04 PMFeb 1
to Yoav Weiss, Nicolás Peña, blink-dev
Hi,

I'm still interested in hearing feedback about changes in Cookie Store's ToCanonicalCookie and ExecutionContextCSPDelegate::GetStatusCode, if there is anyone familiar with this code/spec

Le 25/01/2021 à 15:10, Yoav Weiss a écrit :

As Resource Timing and Navigation Timing only report http* schemes, those semantics differences are not currently exposed.

OK, good to know.

And also rely on an allow list of hosts e.g. for the enterprise policy [1].

Huh, that bit is potentially web exposed, which isn't great.

I think this would be included if we move to a notion of "url is potentially trustworthy".

 

So restricting to secure transport is a behavior change which may potentially break existing pages. Even the definition of "secure transport" is vague : I understand the spec means https and wss schemes, but chromium also supports quick-transport: [2].  Note that other places such as ClientHintsPreferences::IsClientHintsAllowed do something like "url is potentially trustworthy and its scheme is https/wss" [3].

I 100% agree that we need to improve the spec on that front.

As I see, you want to rely on fetch concepts which at the end would still rely on W3C webappsec specs and so on the concept of "url is potentially trustworthy" or similar. Let's wait and see the outcome here before doing any change. BTW, my CL at https://chromium-review.googlesource.com/c/chromium/src/+/2617883 does not break any WPT tests for resource timing, which suggests we probably lack test coverage there.

Thanks!

-- 
Frédéric Wang

Yoav Weiss

unread,
Feb 2, 2021, 12:07:44 AMFeb 2
to Frédéric Wang, Nicolás Peña, blink-dev, tomm...@chromium.org
Can you file an issue on that front and loop me and Tom (CCed) on it? Thanks! :)
 
Thanks!

-- 
Frédéric Wang

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
Reply all
Reply to author
Forward
0 new messages