Re: Issue #356: Form-encode Expect-CT report bodies?

On Sat, Jun 10, 2017 at 1:55 AM, Martin Thomson <martin.thomson@gmail.com>
wrote:

> For those who are reading this and eating popcorn, this is probably
> worth reading also... <https://github.com/whatwg/fetch/issues/530>
>
> On 9 June 2017 at 16:42, Emily Stark <estark@google.com> wrote:
> > As I said in my first message, implementing true preflights would violate
> > very core architectural principles in Chrome, and would jeopardize our
> > ability to ship an implementation. Maybe there are other implementors who
> > would like to chime in to the contrary, but as of now I'm not very
> inclined
> > to specify something that can't realistically be implemented.
>
> I wanted to poke at that a little.  Expect-CT is a header field, sent
> by a particular origin.  You store the tuple of origin, the expect CT
> mode (none, report, require), and the report URI somewhere.  Then when
> you connect to an origin you retrieve any stored tuple and compare
> what you get with what you expect.  I don't see how a stack would be
> unable to preflight at that point.  It has the information it needs
> for a preflight check.
>

What's missing is the origin that triggered the request: in Fetch language,
the request's client's origin, which populates the `Origin` header. Hence
the suggestion for a preflight with a null Origin header and
Access-Control-Allow-Origin: *. Which would be possible, and I think safe,
but a bit hacky. Probably not more hacky than any of the other solutions
under discussion, though. :)

Having the request's client's origin available at connection setup time
would require quite some gymnastics/re-design of the Chrome network stack,
which late-binds sockets and does not know which request(s) a particular
socket will be used for at connect time.


>
> I recognize that a particular piece of software might be constructed
> in a way that makes this difficult, but it can't be impossible.


> Question: how do you manage the checks when you are using alternative
> services?  I expect that you need to store a target origin for the
> connection attempt, rather than using the host and port or SNI and
> port that you are connecting to.  (This doesn't complicate things
> regarding the question at hand, but I don't see any text on this
> point.)
>

That's a good question, I have to think about that a bit.