Intent to Ship: Private Network Access preflight requests for subresources

[Titouan Rigoudy]

Contact emails

tit...@chromium.org, va...@chromium.org, cl...@chromium.org

Explainer

https://github.com/WICG/private-network-access/blob/main/explainer.md

Specification

https://wicg.github.io/private-network-access/

Design docs

https://docs.google.com/document/d/1FYPIeP90MQ_pQ6UAo0mCB3g2Z_AynfPWHbDnHIST6VI/edit

Summary

Sends a CORS preflight request ahead of any private network requests for subresources, asking for explicit permission from the target server. A private network request is any request from a public website to a private IP address or localhost, or from a private website (e.g. intranet) to localhost. Sending a preflight request mitigates the risk of cross-site request forgery attacks against private network devices such as routers, which are often not prepared to defend against this threat.

Blink component

Blink>SecurityFeature>CORS>PrivateNetworkAccess

TAG review

https://github.com/w3ctag/design-reviews/issues/572

TAG review status

Pending

Risks

Interoperability and Compatibility

The main interoperability risk, as always, is if other browser engines do not implement this. Compat risk is straightforward: web servers that do not handle the new preflight requests will eventually break, once the feature ships. The plan to address this is as follows: 1. Send preflight request, ignore result, always send actual request. Failed preflight requests will result in a warning being shown in devtools. 2. Wait for 3 milestones. 3. Gate actual request on preflight request success, with deprecation trial for developers to buy some more time. 4. End deprecation trial 4 milestones later. UseCounters: https://chromestatus.com/metrics/feature/timeline/popularity/3753 https://chromestatus.com/metrics/feature/timeline/popularity/3755 https://chromestatus.com/metrics/feature/timeline/popularity/3757 The above measure pages that make at least one private network request for which we would now send a preflight request.

Gecko: Worth prototyping (https://github.com/mozilla/standards-positions/issues/143)

WebKit: No signal (https://lists.webkit.org/pipermail/webkit-dev/2021-November/032040.html) Pending response.

Web developers: No signals Anecdotal evidence so far suggests that most web developers are OK with this new requirement, though some do not control the target endpoints and would be negatively impacted.

Other signals:

Ergonomics

None.

Activation

Gating access to the private network overnight on preflight requests would likely result in widespread breakage. This is why the plan is to first send requests but not act on their result, giving server developers time to implement code handling these requests. Deprecation warnings will be surfaced in DevTools to alert web/client developers when the potential for breakage later on is detected. Enforcement will be turned on later (aiming for 3 milestones), along with a deprecation trial for impacted web developers to buy themselves some more time. Experience suggests a large fraction of developers will not notice the advance deprecation warnings until things break.

Security

This change aims to be security-positive, preventing CSRF attacks against soft and juicy targets such as router admin interfaces. DNS rebinding threats were of particular concern during the design of this feature: https://docs.google.com/document/d/1FYPIeP90MQ_pQ6UAo0mCB3g2Z_AynfPWHbDnHIST6VI/edit#heading=h.189j5gnadts9

Debuggability

Relevant information (client and resource IP address space) is already piped into the DevTools network panel. Deprecation warnings and errors will be surfaced in the DevTools issues panel explaining the problem when it arises.

Is this feature fully tested by web-platform-tests?

Yes

DevTrial instructions

https://github.com/WICG/private-network-access/blob/main/HOWTO.md

Flag name

PrivateNetworkAccessRespectPreflightResults

Requires code in //chrome?

False

Tracking bug

https://crbug.com/591068

Launch bug

https://crbug.com/1274149

Estimated milestones

DevTrial on desktop

98

DevTrial on android

98

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5737414355058688

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/PrB0xnNxaHs/m/jeoxvNjXCAAJ

This intent message was generated by Chrome Platform Status.

[Joe Medley]

Titouan,

Will the default for the runtime flag be 'Enabled' in 98?

The DevTrial number should reflect when the flag was first available. 'Shipping' refers to when it can be used in production without web developers or users doing anything. This can mean the flag was removed or it can mean the flag's default was changed to 'Enabled'.

Joe

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

--
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/CAPATO9fdAK%2BnrTfUzug8ub_DhV_LE0b7XrgZ7j5%2Bj_BHtW-FXg%40mail.gmail.com.

[Erik Anderson]

Given this specifically calls out subresources and the design doc lists “the case of navigations” as “followup work,” you’re explicitly not touching how navigations (top-level or an iframe) work at this stage, correct?

 

I expect the most significant compat impact to come from Windows apps that delegate to the default browser to do a login flow where the last step of the auth flow is making a request to a localhost HTTP server to pass back to the app an auth ticket.

 

I anticipate most of those are top-level navigations, but my experience with the first version of Microsoft Edge (pre-Chromium) which prevented localhost loopback for subresources (including iframes), there are apps that handle it some other way which we broke. Some of those may have been passing it back via an iframe navigation (I don’t recall—it was 6+ years ago) in which case they’ll potentially still work after this change.

 

The Microsoft Edge team will work to reach out to Microsoft teams that are potentially impacted. If the roadmap is going to eventually force a preflight before allowing a navigation to a private network origin, we would ideally include clear guidance on what’s likely coming there as well. Is there a general timeline you have in mind for expanding this to navigations as well?

--

[Titouan Rigoudy]

Thanks for the responses!

Joe: the `PrivateNetworkAccessSendPreflights` feature flag will be enabled by default in M98 (if this intent gets 3 LGTMs). The `PrivateNetworkAccessRespectPreflightResults` will be enabled by default later, I am aiming for M101.

On Tue, Nov 30, 2021 at 11:42 PM Erik Anderson <Erik.A...@microsoft.com> wrote:

Given this specifically calls out subresources and the design doc lists “the case of navigations” as “followup work,” you’re explicitly not touching how navigations (top-level or an iframe) work at this stage, correct?

That is correct.

 

I expect the most significant compat impact to come from Windows apps that delegate to the default browser to do a login flow where the last step of the auth flow is making a request to a localhost HTTP server to pass back to the app an auth ticket.

 

I anticipate most of those are top-level navigations, but my experience with the first version of Microsoft Edge (pre-Chromium) which prevented localhost loopback for subresources (including iframes), there are apps that handle it some other way which we broke. Some of those may have been passing it back via an iframe navigation (I don’t recall—it was 6+ years ago) in which case they’ll potentially still work after this change.

If they indeed use either top-level or iframe navigations, then they will be unaffected by this change.

 

The Microsoft Edge team will work to reach out to Microsoft teams that are potentially impacted. If the roadmap is going to eventually force a preflight before allowing a navigation to a private network origin, we would ideally include clear guidance on what’s likely coming there as well. Is there a general timeline you have in mind for expanding this to navigations as well?

I don't have a very clear timeline yet, but I wish to tackle nested navigations in particular in M100.

Cheers,

Titouan

[Yoav Weiss]

On Monday, November 29, 2021 at 4:37:24 PM UTC+1 Titouan Rigoudy wrote:

Contact emails

tit...@chromium.org, vahl@chromium.org, clamy@chromium.org

Explainer

https://github.com/WICG/private-network-access/blob/main/explainer.md

Specification

https://wicg.github.io/private-network-access/

Design docs

https://docs.google.com/document/d/1FYPIeP90MQ_pQ6UAo0mCB3g2Z_AynfPWHbDnHIST6VI/edit

Summary

Sends a CORS preflight request ahead of any private network requests for subresources, asking for explicit permission from the target server. A private network request is any request from a public website to a private IP address or localhost, or from a private website (e.g. intranet) to localhost. Sending a preflight request mitigates the risk of cross-site request forgery attacks against private network devices such as routers, which are often not prepared to defend against this threat.

Blink component

Blink>SecurityFeature>CORS>PrivateNetworkAccess

TAG review

https://github.com/w3ctag/design-reviews/issues/572

TAG review status

Pending

Risks

Interoperability and Compatibility

The main interoperability risk, as always, is if other browser engines do not implement this. Compat risk is straightforward: web servers that do not handle the new preflight requests will eventually break, once the feature ships. The plan to address this is as follows: 1. Send preflight request, ignore result, always send actual request. Failed preflight requests will result in a warning being shown in devtools.

Would that include deprecation reports?

 

2. Wait for 3 milestones. 3. Gate actual request on preflight request success, with deprecation trial for developers to buy some more time.

We'd also need to communicate this widely in order to get relevant developers to sign up for the deprecation trial. UKM investigation can help us focus efforts on that front.

 

4. End deprecation trial 4 milestones later. UseCounters: https://chromestatus.com/metrics/feature/timeline/popularity/3753 https://chromestatus.com/metrics/feature/timeline/popularity/3755 https://chromestatus.com/metrics/feature/timeline/popularity/3757

That's a lot of usage :/ I remember you did a bunch of UKM investigations in the past. Did that include this case as well?

[Titouan Rigoudy]

Thanks for the response Yoav, answers inline.

On Wed, Dec 1, 2021 at 1:22 PM Yoav Weiss <yoav...@chromium.org> wrote:

On Monday, November 29, 2021 at 4:37:24 PM UTC+1 Titouan Rigoudy wrote:

Contact emails

tit...@chromium.org, va...@chromium.org, cl...@chromium.org

Explainer

https://github.com/WICG/private-network-access/blob/main/explainer.md

Specification

https://wicg.github.io/private-network-access/

Design docs

https://docs.google.com/document/d/1FYPIeP90MQ_pQ6UAo0mCB3g2Z_AynfPWHbDnHIST6VI/edit

Summary

Sends a CORS preflight request ahead of any private network requests for subresources, asking for explicit permission from the target server. A private network request is any request from a public website to a private IP address or localhost, or from a private website (e.g. intranet) to localhost. Sending a preflight request mitigates the risk of cross-site request forgery attacks against private network devices such as routers, which are often not prepared to defend against this threat.

Blink component

Blink>SecurityFeature>CORS>PrivateNetworkAccess

TAG review

https://github.com/w3ctag/design-reviews/issues/572

TAG review status

Pending

Risks

Interoperability and Compatibility

The main interoperability risk, as always, is if other browser engines do not implement this. Compat risk is straightforward: web servers that do not handle the new preflight requests will eventually break, once the feature ships. The plan to address this is as follows: 1. Send preflight request, ignore result, always send actual request. Failed preflight requests will result in a warning being shown in devtools.

Would that include deprecation reports?

Not so far. Blink is not made aware of the warnings yet, they go from the network service to the browser process and then straight to devtools. More wiring would be needed for Blink to notice the warning and send a deprecation report.

 

 

2. Wait for 3 milestones. 3. Gate actual request on preflight request success, with deprecation trial for developers to buy some more time.

We'd also need to communicate this widely in order to get relevant developers to sign up for the deprecation trial. UKM investigation can help us focus efforts on that front.

That is true. I am planning to write a blog post on web.dev or the chrome blog to help raise awareness.

4. End deprecation trial 4 milestones later. UseCounters: https://chromestatus.com/metrics/feature/timeline/popularity/3753 https://chromestatus.com/metrics/feature/timeline/popularity/3755 https://chromestatus.com/metrics/feature/timeline/popularity/3757

That's a lot of usage :/ I remember you did a bunch of UKM investigations in the past. Did that include this case as well?

I did not look at these metrics during my previous UKM analysis - I was focusing on non-secure contexts initiating private network requests. I can look into them again however, and try to reach out to the biggest users before enforcement is turned on.

Cheers,

Titouan

[Daniel Bratell]

This sounds like a change that would disproportionately affect "enterprise" so it's probably best to involve the Chrome enterprise team sooner rather than later. The numbers are higher than I would have expected. Makes me wonder if there is some specific source of those. I would have expected it to be rarer than that to embed a resource from a private network.

/Daniel

--

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/CAPATO9f6QS%3D4oJqnJg6NR%3DpoKcT149h8LeiSzkfd%3Dqq8qV6pLA%40mail.gmail.com.

[Titouan Rigoudy]

Good idea, I will alert the enterprise team of the upcoming change.

There are also existing enterprise policies [1] [2] introduced for the previous change (secure context restriction) that also work in this context to disable the new behavior entirely. Their descriptions need a little updating for it to be clear that they apply to this change as well. Filed crbug.com/1275567 to fix that.

As for specific sources: UKM data might not tell us unfortunately, since AFAIU that data is not reported by enterprise deployments?

Cheers,

Titouan

[1] https://chromeenterprise.google/policies/#InsecurePrivateNetworkRequestsAllowed

[2] https://chromeenterprise.google/policies/#InsecurePrivateNetworkRequestsAllowedForUrls

[Yoav Weiss]

https://groups.google.com/a/chromium.org/g/blink-dev/c/xWVtdGDLz_Q/m/kyofZuRfBAAJ may be a relevant conversation on that front. It may be worthwhile to talk to Andrew to see what they did on that front.

[Titouan Rigoudy]

Thanks for the pointer! I've reached out and will see what I can do.

Cheers,

Titouan

[Mike Taylor]

Hi Titouan,

I'm curious what the plan is for structured headers. https://github.com/WICG/private-network-access/issues/45 is marked as blocked - has there been other progress or thinking behind the scenes?

thanks,

Mike

--
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/CAPATO9fdAK%2BnrTfUzug8ub_DhV_LE0b7XrgZ7j5%2Bj_BHtW-FXg%40mail.gmail.com.

[Titouan Rigoudy]

Hi Mike,

There is no support for structured headers so far, for consistency reasons, and there has been no movement to deprecate the "true" value for Access-Control-Allow-Credentials. The value of such a deprecation seems minimal.

I could pretty easily add support for the structured "?1" value on top of the "true" token for the new Access-Control-Allow-Private-Network header, and specify that, but I'm not sure it would be terribly useful. Do you think otherwise?

Cheers,

Titouan

[Mike West]

I'm not sure it makes sense to introduce a structured header here, given that it's layering on top of CORS headers that I don't think there's substantial interest in changing.

-mike

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPATO9f3dAnHromxwvp8jWRxVLYVKZ0PAG5snX2KDFAYz4kc7Q%40mail.gmail.com.

[Mike Taylor]

Thanks - I also don't think there's a lot of value in this particular header being the odd-one-out, just wanted to confirm we're not going to ship "true" first and try to change that to ?1 later (which is always challenging).

[Mike West]

_I_ don't think we should do that, but I'd defer to Titouan's preference. :)

-mike

[Titouan Rigoudy]

I agree!

Cheers,

Titouan

[Titouan Rigoudy]

Yoav, do you think UKM analysis should block sending preflights without enforcing their success? I believe sending these will allow us to get more precise information on the affected websites through the usecounter recorded in crrev.com/c/3310846. I can then analyze UKM data and use the results to inform the decision whether and when to switch enforcement on?

Cheers,

Titouan

[Yoav Weiss]

I agree UKM analysis should not block step 1, as it holds little risk. (There's still some risks that servers will choke in the face of preflights, but that seems minor compared to the enforcement risk)

Therefore, LGTM1 for step 1 (preflights with no enforcement), but not further (yet). Please come back to this thread with any data you may have as a result of adding UKMs.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPATO9ePgpof%2BBDWS9X7sfHHAqgc6Arem3b78ZGC%3D%2Bp4jB6_AQ%40mail.gmail.com.

[Titouan Rigoudy]

Thanks! I'll come back for further discussion with UKM data in hand.

Cheers,

Titouan

[Titouan Rigoudy]

*assuming I get 2 more LGTMs, that is.

[Mike Taylor]

LGTM2 for step 1.

[Chris Harrelson]

LGTM3 for step 1.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6e557fb7-5b1d-20bc-aae5-65526ca8efb7%40chromium.org.

[Titouan Rigoudy]

Hi all,

Just to let you know that due to a couple issues, chief among which a renderer crash (crbug.com/1279376), we are rolling this feature back from Chrome 98.

A few issues have been identified and will block our next attempt at shipping this. In the meantime, we gathered some useful information about impact and notified developers of the upcoming change. I'll write a doc summarizing the timeline and lessons learned, then share as appropriate here.

Cheers,

Titouan

[Mike Taylor]

Thanks for the update Titouan. Looking forward to reading your doc.

[Titouan Rigoudy]

Hi all,

Here's the promised doc: https://docs.google.com/document/d/1fdwetZXUz_Q03ZpGwXizq5AE1yn_lMhamUJMwvsHvTU/edit (public, comment access for committers only)

Cheers,

Titouan

[Logan Wei]

Hello,  is there now an updated timeline to roll out this change?  Will the trial restart in Chrome 102 or a later version?  

[Titouan Rigoudy]

Hi all,

Thanks for the timely question, I was about to send an update here.

We have fixed nearly all of the blockers identified in the above doc. The only outstanding issue is the aforementioned crash, which required a bit more design work than the rest. That work has been completed and CLs to fix the problem are now in review; they should land shortly and make it in Chrome 102.

We would like to ship again in Chrome 102 in warning-only mode, just as we last tried in Chrome 98. Preflights will be sent but their results will not be enforced. Failed preflights will show warnings in DevTools, but requests will otherwise continue unimpeded.

Things will stay that way for at least 3 milestones. We will gather compatibility data by monitoring failed preflights, then circle back here to garner approvals to turn on enforcement. That launch will be accompanied by a deprecation trial for web developers to sign up for a time extension if they failed to notice the warnings in time.

Cheers,

Titouan

[John Doe]

1. In Chrome 98, there were no preflight requests when accessing from public HTTPS to private HTTP, will the same be true in the final version?

2. In the case when I have a private HTTPS server that I want everyone to have access to (also via public HTTP), what options do I have ?

[Titouan Rigoudy]

Hi there,

1. Such requests are blocked by mixed content. This launch does not change that.

2. You will want to respond 200 OK to PNA preflight requests to your private HTTPS server with the right headers. See the blog post [1] for details.

Cheers,

Titouan

[1] https://developer.chrome.com/blog/private-network-access-preflight/#server-side-requests