Set content-type header when sending reports.

[ScottHelme]

The CSP spec has a nice requirement that CSP reports should have the content-type header set to application/csp-report. https://www.w3.org/TR/CSP2/#send-violation-reports

Could we introduce a similar requirement for CT reports to have a content-type header set to application/ct-report?

[estark37]

@annevk @mikewest did we ever decide anything to do about the fact that CSP reports and similar violate the SOP by sending non-whitelisted Content-Type headers?

[mikewest]

We decided it's not awesome, and that we should migrate to https://wicg.github.io/reporting/ which respects CORS. What type does expect-ct send today?

[estark37]

Today Expect-CT sends application/json, but we can totally change that. By "respects CORS", do you mean that reports sent via Reporting API will send preflights?

[annevk]

Yeah, basically, that's what it would mean. (Putting more pressure on @mikewest to finish Origin Policy so origins can opt out of preflights.)

[estark37]

Thinking about this some more, why do we consider, say, HPKP reports to be a SOP violation but not OCSP requests, which can also have non-whitelisted headers (https://tools.ietf.org/html/rfc6960#appendix-A.1)?

[annevk]

@estark37 I think those would be equally problematic. It's really any outgoing request from a browser that goes to an address determined by the user or a third-party.

[sleevi]

@annevk Can you explain why? Note that the "third-party", in this case, is a trusted party responsible for the foundation of security (namely, CAs). This is not, say, the server itself, it's a trusted third-party, no different than the browser sending something to its vendor.

[annevk]

@sleevi ah, that's why I wrote think. I would classify that as second-party since there's some kind of relationship and mutual understanding.

[sleevi]

@annevk OK, so one more complication ;)

A name-constrained subCA, in which the CA has restricted the set of issuance for a particular CA certificate to a domain namespace, and, by doing so, most browsers absolve the issuing CA of its responsibility, oversight, and auditing.

That is, you could have

CA Foo (a TTP) -> Intermediate Bar (which Foo is responsible for overseeing and inherits the same TTP status) -> NameConstrained Baz (where Baz is restricted to issuance for example.com).

Baz can issue any number of additional intermediates, and control the OCSP responder URLs, the cRLDistributionPoints, and the AIA caIssuers to arbitrary URLs in an arbitrary namespace. With the exception of Firefox, all other browsers are using a separate, non-browser networking stack to perform these requests, and, depending on the OS, out of process and in a separate security context.

Can you clarify/explain where/why, in these cases, in which it is truly third-party, the concern is? :) I must admit, I'm not sure it's immediately obvious to me.

[annevk]

If Baz can be rogue without consequences it could create requests within the user's private network that browsers might not have been expected to make and therefore have unforeseen side effects on endpoints within that network. The theory being that browsers are only expected to make requests that fulfill SOP (meaning same-origin and whatever <img>, <form>, etc. can do).

It seems unlikely that any private network would be that naive that the only attacker can be the browser, but if we're not serious about holding that line I would be extremely curious to learn where the line is.

[sleevi]

@annevk With the exception of Firefox, the browser does not make these connections, the OS does. Much like, for example, interrogating some GPUs about their capabilities will result in a network fetch of DTDs for the XML specification baked into the driver (I wish I was joking).

But yes, such a name-constrained sub-CA can direct the requests at any particular endpoint. Even under a 'pessimistic' implementation (which no browser implements), which does not perform network fetches until it's verified the delegated authority (e.g. start with the root, check its CRLs for the intermediate, then check the intermediate's stated CRLs for baz, then check Baz's stated CRLs), it would still be fully possible for Baz to network requests (or file system loads; Edge uses CryptoAPI to verify certificates, which supports file:// URLs, which can then be directed to SMB hosts).

So while I understand that theory, I'm saying it's not been practiced, nor is it capable of being practiced under the current OS APIs, no more than extension APIs may make additional requests.

Sorry to hijack @estark37's bug for that discussion, but I think it's worthwhile to figure out where Expect-CT sits on that spectrum. I suspect it aligns with what you say, if only because the act of introducing a technically-constrained sub-CA which grants third-party loads (and not just second-party) is an act of delegation of sufficient complexity, while Expect-CT can be set by anyone. But it's also worth highlighting in case you wanted to confer with folks like @jcjones or @gerv on what the right implementation or policies, respectively, should exist around that. I'm not sure where that discussion should best take place :)

[estark37]

For Expect-CT reports, I think we have two options:

1. Form-encode the reports.
2. Send preflights. (In the Chrome implementation, this would probably mean sending report events out to the content/ layer to deal with CORS..?)

Anyone have thoughts? Both seem kind of gross to me. :(

[annevk]

@sleevi I created whatwg/fetch#530 for OSCP specifically.

@estark37 a third option is that we extend SOP as we did when added CORS preflights (a new type of cross-origin request). However, I'd rather we find a way to stop doing that or find a better place to draw a line (sorry, not sure what that would look like). Every now then going "oops we extended SOP" is not principled enough for my taste and difficult for server operators to work with.

[estark37]

After some pondering, I decided to leave this as JSON, with Content-Type application/expect-ct-report. I resolved the SOP issue from a spec perspective by saying that the UA should send a POST request to upload the report, and leaving it up to the UA to define what exactly is involved in sending the request (with a note that a UA that implements Fetch would end up sending a CORS preflight).

From an implementation perspective, sending CORS preflights in the Chrome impl is going to be tricky, so I'll still have to figure that out. I noticed that the Reporting API implementation doesn't actually appear to send CORS preflights, so I think CSP will still have this problem. (cc @mikewest @juliatuttle)