Unifying the notions of "secure context" (trustworthy url/origin)
Frédéric Wang
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
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
--
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
* 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].
[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
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].
Frédéric Wang
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
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3a71f44a-7532-9d45-eef3-7555ef2815d1%40igalia.com.