Re: Cookies and schemes.

[Willy Tarreau <[e-mail]>]

On Tue, Mar 10, 2020 at 09:02:25AM +1100, Martin Thomson 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://

Maybe that can work.

>  The Sec-Nonsecure-Cookie header field seems like it might not be great long term.

I don't believe in adding attributes to legacy applications anyway. If they
rely on older mechanisms it's because they cannot be changed, and it's not
by changing default behavior that we'll make them suddenly capable of adapting
their code to emit new cookie attributes.

> Tf the goal is to support temporally-constrained transfer, then binding the
> cookies to the redirect avoids pulling from previous state.  Also, the
> redirector could have just packed this information into the target URL, so
> it's not a new tracking vector.

Absolutely.

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

  1) client connects over HTTP to example.com
  2) the load balancer doesn't find a cookie, applies the load balancing
     algorithm and forwards the request to server #1
  3) server responds, load balancer appends cookie "SERVER=srv01" to the
     response
  4) client makes a few more HTTP requests presenting "SERVER=srv01",
     which the LB spots and continues to pass to server #1. Since the
     client presents the cookie, the LB doesn't append it on new responses.
  5) one such response is now a 302, client then sends a request over
     HTTPS, still presenting the cookie "SERVER=srv01". The load balancer
     sees it and forwards it to the server and doesn't append it on response.

Past this point, if the client stops presenting the cookie, we'll lose the
binding. I'm still not clear on how to address this without systematically
appending a cookie to responses, which is bad. We're exactly in the situation
where I was thinking that it would be nice to have the ability for the client
to signal the server "I'm going to expire this cookie, please renew it if
still needed".

Maybe the right approach would be to change the default behavior with a
new attribute. Currently without any attribute the cookie is presented
to both schemes, while with the secure attribute it's presented only to
HTTPS. By having an explicit such as "secure-and-insecure" or something
like this, we could have load balancers explicitly set this one for
server affinity, and let the client present it to both HTTP and HTTPS.
Then with this, we could stop presenting an HTTP-learned cookie over
HTTPS at all by default.

Just my two cents,
Willy