Re: Cookies and schemes.

On Tue, Mar 10, 2020 at 08:29:50AM +0100, Mike West wrote:
> > 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.

We've already seen the mess created by set-cookie2, please don't suggest
doing the same again! It would be hard to retrofit into existing components
and it will always result in a hack. It's worth mentioning that all the crap
we have to live with were created as quick and dirty solutions to a problem.
Even the set-cookie header field by the way, specified in 2 or 3 paragraphs
only.

> 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.

It will be worse. Those having trouble configuring them will modify their
LBs to put everything into cookie and systematically duplicate them into
the other ones, considering that "the browser will figure which one it
needs anyway".

> 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.

It's already the case by definition as long as the transmission operates
in clear. Anything can be put in the response, including some links or
whatever. If you have data showing that cookies are not passed anymore
cross redirects from HTTP to HTTPs, then that's fine and it means that
we don't need this anymore. But I never received complaints that haproxy
started to lose affinity on redirects, which makes me think it's still
valid.

> 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)?

For many infrastructure components it's a pain because it involves
creating a storage *somewhere* that *someone* has to be in charge of,
and in mutualized environments it's a real pain.

> 2.  Perhaps we prefix the non-secure cookie names with `__Non-secure-`
> rather than minting a new header?

I really like this. It's by far the easiest solution. Usually nobody
cares about the load balancer's cookie name because the LB will remove
it before passing the request to the server, so this one can be changed
at will by the person responsible for the LB. There are always edge
cases of course, like a management page hosted on the application to
perform some specific tests or maintenance operations but the 1% doing
this know exactly what they're doing and will figure a different way
to do it.

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

For the latter, just the LB, not the server, which is exactly what can
boost adoption.

> 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.

The problem is that by breaking 10% of the web every 3 months we're
making everyone totally incompetent on infrastructure, rendering the
whole web totally insecure. I'd rather use motivation that trouble
making. Using the cookie name is perfect because it is visible in the
browser. So when your site requires that all your users see they learn
cookies called "insecure_something", you do have a great motivation to
try to improve the situation without being forced to rush an even more
horribly insecure hack to suit a browser's next imposed deadline that
threatens to destroy your site.

> 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.

That sounds reasonable to me as I said earlier.

> 3.  Never the twain shall meet.

Sorry, can't parse that :-/

> 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.

Ideally yes, but ideally all the web would have been developed in 2019
and would be fresh new. The reality is that a lot of the content we use
was created way earlier by people having switched jobs and running on
components that are only maintained in good enough condition, and do
not evolve very quickly. By pressuring all content providers too much
we're progressively only keeping commercial stuff online and amateur/
enthousiast has no place anymore because of the hassle and costs
required by constant adaptations just to publish knowledge for free.
And I'm sensitive to remaining careful about this as well. So in practice
I'm also concerned about keeping the ability for a working site which
starts in HTTP with unimportant contents to decide to turn to HTTPS
when needed if that's the way the site works. It's always better to
do that than to make the situation so painful that they stay in clear
when that becomes quite borderline.

And that's still very frequent. A friend of mine who does a bit of
security consulting for small businesses told me that the hardest
thing he has to explain to customers is always to use HTTPS for
e-commerce sites! The risk of accidental breakage is often not
accepted. And that breaks because they're often left with too few
options to do what they need, which also means that once it works,
nobody's allowed to touch it anymore, so it's not even imaginable
to improve the situation from there! This is the reality of small
sites still using HTTP nowadays.

> I don't think we should add new attributes in order
> to support sites that push users back and forth from HTTPS to HTTP.

I think that once the cost of switching the connection to HTTPS has been
digested, there's no point in going back to HTTP from HTTPS. However,
easing the transition from HTTP to HTTPS seems very important to
encourage migrating ealier in the session, even if reaching that
state requires several baby steps from the site's operator.

Cheers,
Willy

Received on Tuesday, 10 March 2020 20:51:29 UTC