Re: Cookies and schemes.

Thanks, Martin and Willy!

On Mon, Mar 9, 2020 at 11:07 PM Martin Thomson <mt@lowentropy.net> wrote:

> On Mon, Mar 9, 2020, at 19:51, Mike West wrote:
> > https://github.com/mikewest/scheming-cookies proposes two changes:
> >
> > 1. We teach cookies about schemes, and lock them to the scheme that set
> > them (just like every other web-facing storage mechanism).
>
> Excellent!
>
> To Willy's point about transfer, perhaps we can allow any cookies that are
> set on an http:// response to follow a redirect to https://  The
> Sec-Nonsecure-Cookie header field seems like it might not be great long
> term.
>

The `Sec-Nonsecure-Cookie` header is, indeed, not something we'd want to
keep for the long term. I'm thinking of it explicitly as a stopgap for the
period of time directly after we start enforcing scheme bindings, and would
expect it to live for a quarter or so. That said, I'm not amazingly
enthusiastic about it, but it has three properties I like:

1.  It gives secure hosts access to their non-secure cookies in a way that
allows them to perform a migration if they so desire.
2.  It does not put those cookies into the `Cookie` header, meaning that a
host that doesn't intentionally perform a migration (and, in the best case,
validate the data against whatever securely-delivered state it has access
to before blindly accepting it) won't be at risk.
3.  It doesn't require us to figure out an ordering of "the same" cookie
that's distinguished only by scheme (e.g. `Set-Cookie: a=b` on both `
http://example.com/` and `https://example.com`).

If I understand the redirect proposed above, it would give network
attackers the ability to send arbitrary cookies to secure servers by
forging HTTP responses that set cookies and redirect to HTTPS. I'd like to
remain robust against this kind of attack.

Two alternatives come to mind:

1.  Perhaps we do this kind of thing only for a specific endpoint
(`/.well-known/migrate-nonsecure-cookies`, for example)?
2.  Perhaps we prefix the non-secure cookie names with `__Non-secure-`
rather than minting a new header?

Both would require more explicit involvement from the server to perform the
migration, which I think is valuable.


> > 2. We curtail non-secure schemes' cookies' lifetime by agreeing on a
> > set of heuristics for a user's "session" on a given site, and culling
> > cookies when a site's session expires.
>
> Also good.  The need for heuristics is unfortunate, but I appreciate that
> you have to do that.
>

The heuristic described in the doc seems workable, and matches my
intuitions about user's understanding of session lifetimes (modulo a lot of
fuzziness around the exact time period after closing the last window). I
hope it's something that's deployable in practice.


On Tue, Mar 10, 2020 at 4:43 AM Willy Tarreau <w@1wt.eu> wrote:

> > Have I missed a key piece of information?  Willy, could this work in the
> > cases you understand?
>
> I think it can, yes, but it would still require some infrastructure
> adaptations, and by default could degrade the behavior over HTTPS by
> forcing to always append a cookie in response. The typical case I'm
> thinking about is the following sequence:
>

For clarity, my goal is to encourage developers who require stateful
connections to use HTTPS, and to make it more difficult to persist data
outside of a secure context.

With that in mind, I'm not enthusiastic about creating long-lived
mechanisms to deal with hybrid sites that try to span both HTTP and HTTPS
connections. This proposal (in combination with +Steven Bingler
<bingler@google.com>'s schemeful same-site proposal
<https://github.com/mikewest/cookie-incrementalism/pull/3>) suggests that `
http://example.com/` and `https://example.com/` are not actually the same
site, and shouldn't be privileged with regard to each other. That seems
like the right place to land, and I'd like to ensure that the changes we
make to the platform lead in that direction towards a future in which:

1.  HTTP sites have, at most, session-based cookies as per the heuristics
described above
<https://github.com/mikewest/scheming-cookies#cookies-lifetime>.
2.  HTTPS sites have persistent cookies.
3.  Never the twain shall meet.

Ideally, the load-balancing case devolves to the LB doing an immediate
redirect to HTTPS, and then deciding which backend the user should stick to
in that secure context. I don't think we should add new attributes in order
to support sites that push users back and forth from HTTPS to HTTP.

Thanks!

-mike