New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Form-encode Expect-CT report bodies? #356

Closed
estark37 opened this Issue May 30, 2017 · 15 comments

Comments

Projects
None yet
4 participants
@estark37
Contributor

estark37 commented May 30, 2017

Background for this issue is in bifurcation/expect-ct#18, where it is argued that Expect-CT reports should have a special Content-Type, like Content Security Policy reports, but it is also argued that they should be sent with CORS preflights when Expect-CT is implemented by a web browser, since they are not a whitelisted safe request.

Unfortunately, implementing preflights for Expect-CT reports probably can't be done in Chrome in any reasonable amount of time, and would probably be difficult for other implementors as well. Expect-CT is checked at connection setup time, completely divorced from any context from which we can construct an Origin header.

Therefore I think we need to resort to using application/x-www-form-urlencoded for reports, if we want Expect-CT to be reasonably implementable in a web browser without violating the SOP.

@ScottHelme @mikewest @eranmes

@estark37

This comment has been minimized.

Show comment
Hide comment
@estark37

estark37 May 30, 2017

Contributor

@sleevi do you think this is the right way forward given the time pressures on Expect-CT?

Contributor

estark37 commented May 30, 2017

@sleevi do you think this is the right way forward given the time pressures on Expect-CT?

@sleevi

This comment has been minimized.

Show comment
Hide comment
@sleevi

sleevi May 30, 2017

@estark37 It's above my paygrade. I'm not sure these requests should abide by CORS, especially if we think of "Expect-CT" as part of an input to the PKI validation blackbox, but if it helps adoption, then such is the life of standards and compromises.

sleevi commented May 30, 2017

@estark37 It's above my paygrade. I'm not sure these requests should abide by CORS, especially if we think of "Expect-CT" as part of an input to the PKI validation blackbox, but if it helps adoption, then such is the life of standards and compromises.

@reschke

This comment has been minimized.

Show comment
Hide comment
@reschke

reschke Jun 6, 2017

Contributor

Use an HTTP method other than POST?

Contributor

reschke commented Jun 6, 2017

Use an HTTP method other than POST?

@estark37

This comment has been minimized.

Show comment
Hide comment
@estark37

estark37 Jun 6, 2017

Contributor

@reschke that doesn't resolve the issue; preflight requests are required as long as there is a non-whitelisted Content-Type header of application/json.

Contributor

estark37 commented Jun 6, 2017

@reschke that doesn't resolve the issue; preflight requests are required as long as there is a non-whitelisted Content-Type header of application/json.

@reschke

This comment has been minimized.

Show comment
Hide comment
@reschke

reschke Jun 6, 2017

Contributor

That would be a bug in CORS. No preflight is needed if the HTTP method by definition can not ve generated by an HTML form.

Contributor

reschke commented Jun 6, 2017

That would be a bug in CORS. No preflight is needed if the HTTP method by definition can not ve generated by an HTML form.

@estark37

This comment has been minimized.

Show comment
Hide comment
@estark37

estark37 Jun 6, 2017

Contributor

That's not a bug in CORS, it's exactly the point of CORS -- to prevent requests that cannot be generated by legacy web content (for example, via an img tag or an HTML form submission) unless the server opts in.

Contributor

estark37 commented Jun 6, 2017

That's not a bug in CORS, it's exactly the point of CORS -- to prevent requests that cannot be generated by legacy web content (for example, via an img tag or an HTML form submission) unless the server opts in.

@reschke

This comment has been minimized.

Show comment
Hide comment
@reschke

reschke Jun 6, 2017

Contributor

Yes.

But form content and links can only generate GET, HEAD and POST requests.

I was suggesting to use a different method than these.

Contributor

reschke commented Jun 6, 2017

Yes.

But form content and links can only generate GET, HEAD and POST requests.

I was suggesting to use a different method than these.

@estark37

This comment has been minimized.

Show comment
Hide comment
@estark37

estark37 Jun 6, 2017

Contributor

But CORS also disallows non-GET/HEAD/POST methods without a preflight, and that's not a bug; it's because servers might rely on web content not being able to generate those methods and would be vulnerable if web content could send such requests.

Contributor

estark37 commented Jun 6, 2017

But CORS also disallows non-GET/HEAD/POST methods without a preflight, and that's not a bug; it's because servers might rely on web content not being able to generate those methods and would be vulnerable if web content could send such requests.

@reschke

This comment has been minimized.

Show comment
Hide comment
@reschke

reschke Jun 6, 2017

Contributor

Yes, indeed. I was temporarily confused.

Contributor

reschke commented Jun 6, 2017

Yes, indeed. I was temporarily confused.

@estark37

This comment has been minimized.

Show comment
Hide comment
@estark37

estark37 Jun 19, 2017

Contributor

After further discussion on the list (https://lists.w3.org/Archives/Public/ietf-http-wg//2017AprJun/0168.html), I suppose we should leave things as they are: leave it up to the UA to decide if and how to send preflights, with the report-collection server advised to expect preflights from some clients ("The UA MAY perform other operations as part of sending the HTTP POST request, for example sending a CORS preflight as part of [FETCH]").

While it isn't feasible to implement true preflights in a network stack like Chrome's, we could feasibly implement null-origin preflights for Expect-CT reports.

Contributor

estark37 commented Jun 19, 2017

After further discussion on the list (https://lists.w3.org/Archives/Public/ietf-http-wg//2017AprJun/0168.html), I suppose we should leave things as they are: leave it up to the UA to decide if and how to send preflights, with the report-collection server advised to expect preflights from some clients ("The UA MAY perform other operations as part of sending the HTTP POST request, for example sending a CORS preflight as part of [FETCH]").

While it isn't feasible to implement true preflights in a network stack like Chrome's, we could feasibly implement null-origin preflights for Expect-CT reports.

@estark37

This comment has been minimized.

Show comment
Hide comment
@estark37

estark37 Jul 19, 2017

Contributor

Moving discussion over to Fetch (whatwg/fetch#567), will circle back here if it turns out there's something we should do in Expect-CT specifically. cc @martinthomson

Contributor

estark37 commented Jul 19, 2017

Moving discussion over to Fetch (whatwg/fetch#567), will circle back here if it turns out there's something we should do in Expect-CT specifically. cc @martinthomson

@estark37 estark37 closed this Jul 19, 2017

@martinthomson

This comment has been minimized.

Show comment
Hide comment
@martinthomson

martinthomson Jul 19, 2017

Contributor

@estark37, I don't want to create a false impression that there is no issue remaining. Is your intent to track the issue we discussed in some other way?

As we discussed, I think that the requesting origin for the request is the origin of the response that contained the Expect-CT header field.

Contributor

martinthomson commented Jul 19, 2017

@estark37, I don't want to create a false impression that there is no issue remaining. Is your intent to track the issue we discussed in some other way?

As we discussed, I think that the requesting origin for the request is the origin of the response that contained the Expect-CT header field.

@estark37

This comment has been minimized.

Show comment
Hide comment
@estark37

estark37 Jul 19, 2017

Contributor

@martinthomson I thought your suggestion was to discuss with Fetch how to handle these requests?

I'm fine with using the Expect-CT origin as the Origin for the preflight, but I'm still not sure that the Expect-CT spec is the right place to say that, as it doesn't make sense for non-browser clients. (I think it belongs better in Fetch.)

Contributor

estark37 commented Jul 19, 2017

@martinthomson I thought your suggestion was to discuss with Fetch how to handle these requests?

I'm fine with using the Expect-CT origin as the Origin for the preflight, but I'm still not sure that the Expect-CT spec is the right place to say that, as it doesn't make sense for non-browser clients. (I think it belongs better in Fetch.)

@estark37 estark37 reopened this Jul 19, 2017

@martinthomson

This comment has been minimized.

Show comment
Hide comment
@martinthomson

martinthomson Jul 19, 2017

Contributor

OK, that sounds good. My suggestion is to keep this open until we have greater clarity about how this is captured, even if that means closing this with no action because Fetch is covering it.

Contributor

martinthomson commented Jul 19, 2017

OK, that sounds good. My suggestion is to keep this open until we have greater clarity about how this is captured, even if that means closing this with no action because Fetch is covering it.

@estark37

This comment has been minimized.

Show comment
Hide comment
@estark37

estark37 May 19, 2018

Contributor

This is covered as an exception in Fetch now: https://fetch.spec.whatwg.org/#cors-protocol-exceptions

Contributor

estark37 commented May 19, 2018

This is covered as an exception in Fetch now: https://fetch.spec.whatwg.org/#cors-protocol-exceptions

@estark37 estark37 closed this May 19, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment