Design for a stateless proxy to implement DBSC

[benweissmann]

Hello! I was thinking about writing an open-source server-side implementation of DBSC as a way to understand the spec better. One idea I had was to write a stateless proxy that could sit in front of an existing web app that uses a session cookie for authentication. The proxy would transparently handle DBSC and replace the long-lived session cookie with a short-lived cookie, handle the DBSC session initialization and refreshes, and then transform that short-lived cookie back to the application's long-lived cookie on each request. The idea would be that instead of having to make any updates to an existing app, you could place this proxy in front of the app to get the benefits of DBSC without any changes to the app itself.

One complexity is state management: the need for a persistent store to map session IDs to public keys and upstream cookie values. I've sketched out a design that would store this data in encrypted cookies, so the proxy itself could be stateless and all persistence would be handled by the client itself. I would love some feedback on this design -- in particular:

• Are there any conflicts with the spec or issues with generating the session ID by encrypting the public key itself?
• What properties must the challenge have? Here, i've defined the challenge value to be a timestamp and the session ID, signed by the server (so a compromised client can't pre-generate a bunch of signed challenges and then pass those to an attacker to use in the future -- it can't generate future-dated challenges, because the challenges have to be signed by the server).

Here's my rough sketch:

• Crypto primitives

  • Let aead(X) represent the result of JSON.stringify(X), followed by encryption with Nacl's SecretBox (XSalsa20-Poly1305) using a secret key.
  • Let hmac(Y) represent a MAC of the string Y using Nacl's Auth (HMAC-SHA-512 truncated to 256 bits)

• The proxy would be configured with a secret key (used for aead and hmac), and it would know which cookie the upstream application is using as a session cookie. For the sake of example, we'll assume that cookie is called session, and we'll refer to its value (as set by the upstream application) as upstream_session. The proxy would also be configured with a scope, to be provided in the Session Registration instructions JSON.

• When the proxy returns a response that contains the header Set-Cookie: session=upstream_session

  • If the cookie is empty or the expiration is in the past:
    • Pass the Set-Cookie as-is to clear the session
  • Otherwise, this response is establishing a new session.
    • Add Secure-Session-Registration header with challenge aead({ upstream_session, timestamp }) and path /dbsc_proxy/StartSession. Maybe support only the ES256 algorithm since the public keys are shorter.
    • Leave the Set-Cookie as-is to support browsers that doesn't support DBSC

• /dbsc_proxy/StartSession endpoint

  • Verify the JWT signature
  • Decrypt the jti value to get back { upstream_session, timestamp }
  • Make sure the timestamp is recent (1 minute?)
  • If all that passes:
    • Define the session ID as ({ upstream_session, pubkey }) where pubkey is the client-provided jwk
    • Return the session registration instructions with that session ID, refresh URL of /dbsc_proxy/RefreshSession, the configured scope, and credentials of [{ type: cookie, name: session, attributes: Domain=example.com; Path=/; Secure; HttpOnly; SameSite=Lax}]
    • Add a Set-Cookie: session=dbsc_proxy::timestamp;session_id,hmac(timestamp;session_id) header, with the session ID and current timestamp in the cookie value. Set the expiration of this cookie to 15 minutes.

• On all requests, if there is a session cookie starting with dbsc_proxy:::

  • Verify that the cookie conforms to the format timestamp;session_id;hmac(timestamp;session_id)
  • Verify that the HMAC is valid and the timestamp is within 15 minutes
  • Then, decrypt session_id to get ({ upstream_session, pubkey }) and replace the cookie with upstream_session when sending the request to the upstream server
  • When sending back the response from the upstream to the client, add a Secure-Session-Challenge response header, with the value new_timestamp;session_id;hmac(new_timestamp;session_id) (same as the session cookie, but with an updated timestamp). We could also do this only if the short-lived cookie is nearing expiration.

• /dbsc_proxy/RefreshSession endpoint:

  • If Secure-Session-Response is not provided, provide the challenge new_timestamp;session_id;hmac(new_timestamp;session_id)
  • If a signed challenge is provided:
    • Verify that the challenge conforms to the format new_timestamp;session_id;hmac(new_timestamp;session_id)
    • Verify that the new_timestamp is recent (1 minute?)
    • Verify that the session_id in the challenge matches the session id from Sec-Secure-Session-Id
    • Decrypt session_id to get ({ upstream_session, pubkey })
    • Verify that the challenge signature matches the decrypted pubkey.
    • If all that passes, respond with Set-Cookie: session=dbsc_proxy::new_timestamp;session_id,hmac(new_timestamp;session_id)

[drubery]

This is a neat idea! If we assume a very simple site that doesn't sign its cookies, it just generates a random value and uses it as a bearer token, then this works well. I think the next step up in auth complexity for sites is to sign their cookies, and once sites are doing that they have all the pieces for DBSC except the registration and refresh endpoint. Registration and refresh are both doing crypto operations the site might not want to think through the details of, so providing those implementations could be useful. I'd be surprised if that was best accomplished by a proxy rather than something like a node module. I do think that for those middle-complexity sites that if they need a proxy we've failed in our goal of easy adoption.

But there's nothing functionally wrong here, so if there are simple sites that want a proxy then this accomplishes that well! A handful of thoughts:

• You assume that every time the session cookie changes values it represents a new login. That could mean this doesn't work with sites that sign their cookies or have any other extraneous information in the session cookie's value. If you re-sign the cookie with a new timestamp (for inactivity detection, for example), the value changes and the proxy would count that as a sign-in. That opens up a security hole. Maybe sites should explicitly signal session start and end to the proxy?
• Your proxy puts everything into one cookie, but it doesn't have to be. For example, encoding the JWK into the session id technically works, but you could also have a fixed session id and use a second cookie that signs over the JWK and upstream_session.
• You had a question about challenges. The only requirement is that you have some way to check for freshness. Malware could delete the existing cookies (logging the user out) and exfiltrate the signed challenge. Then they can only do one refresh on a different device, limiting them to ~10 minutes to do their abuse, but they get to pick when the 10 minutes start. If you can check for challenge freshness you close that risk.

[benweissmann]

Thank you for that feedback! I think the point about session cookies changing is important -- it implies that for this design to work, we need to be able to change the value of the upstream cookie without changing the session ID. To your point of using multiple cookies, I think we can accomplish that by separating the upstream cookie value from the session ID and storing that in a separate, long-lived cookie. Making the upstream cookie mutable should avoid needing the upstream app to explicitly signal the start of a session, since one of my goals is for the proxy to work with no changes to an existing upstream app.

• Regarding session IDs: Is having a hard-coded session ID that is the same for all clients valid? Is the purpose of having a Session ID at all just to allow apps where you might have a single client with simultaneous sessions?

• And for challenges: would it be safe to simplify the challenge to something like timestamp;hmac(timestamp) for both the initial and refresh challenges? Is there any issue with not having the challenge contain something specific to the session that we're protecting? I'm thinking that because of the HMAC (preventing pre-generation / pre-signing of challenges by a compromised client), a client that can sign this generic value has proved timely possession of the private key, and so it's OK to refresh the session.

• To your point about this only working for unsigned cookies: I'm not sure I agree. I think that for a site that signs its cookies, you could just treat the signature (if it's stored as a separate cookie) as the session credential, and have the proxy use DBSC to protect / replace that signature. I think that with signed cookies, the cookie values themselves aren't valuable; the signature is -- so you'd treat the signature session credential for the purposes of DBSC.

• And to your point about the usefulness of a proxy: I agree that for larger apps, having a proxy is probably the wrong design, and DBSC should just be implemented as part of the app's session management. I think there's a couple reasons why having this proxy could still be worthwhile:

  • For older / legacy apps, it's a way to protect the app without having to touch it at all
  • I think that some of the pieces of this design are also applicable to implementing a library that helps with DBSC. Even if the proxy itself doesn't get much use, the existence of an implementation that requires no changes to the app, and requires no persistent storage, potentially provides some useful building blocks for an easy-to-use library. For example, if the technique of using timestamp;hmac(timestamp) as a challenge is valid, that might be much simpler to implement that what the spec implies of storing a rolling window of recent challenges and checking against those stored values (and can be computed cheaply enough that it can be provided with every response, to allow the user agent maximum flexibility on when to refresh the session).

Thanks again for taking the time to think through this with me -- really excited for this spec and to see some progress on fighting back against session-stealing malware!

---

Here's my updated thoughts on how this could work and support changing the upstream session cookie without changing the DBSC session ID:

• We will work with three values stored by the client:

  • The session ID is the fixed string "dbsc_proxy"
  • A cookie called dbsc_proxy_upstream. This holds the value aead({ upstream_session, pubkey }) and has an expiration (and all other attributes) equal to the upstream session cookie's. Conceptually, this cookie is serving as the server's storage that a particular keypair is bound to a particular session, but using an authenticated/encrypted cookie to have the client handle persistence instead of the server.
  • the session cookie (with a name matching the upstream application's session cookie). This holds the value dbsc_proxy::timestamp;hmac(timestamp;<dbsc_proxy_upstream cookie value>), i.e., a timestamp and a signature of that timestamp together with the value of dbsc_proxy_upstream. It has an expiration of 15 minutes, and otherwise has all the same attributes as the upstream cookie. Conceptually, this cookie is a token that provides a short-lived authorization for the client to make use of the session in the dbsc_proxy_upstream cookie without re-proving possession of the private key.

• When the proxy returns a response that contains the header Set-Cookie: session=upstream_session

  • If the cookie is empty or the expiration is in the past:
    • Pass the Set-Cookie as-is to clear the session
    • Also pass a Set-Cookie to clear the dbsc_proxy_upstream cookie
  • If the request did not include a dbsc_proxy_upstream cookie, this response is establishing a new session.
    • Add A Secure-Session-Registration header with challenge timestamp;hmac(timestamp) and path /dbsc_proxy/StartSession. Support only the ES256 algorithm since the public keys are shorter.
    • Leave the Set-Cookie as-is to support browsers that doesn't support DBSC

• /dbsc_proxy/StartSession endpoint

  • Check that the provided challenge matches the format timestamp;hmac(timestamp) with a valid HMAC and recent timestamp
  • Note the session cookie from the request -- this is the upstream_session
  • Return the JSON session instructions with a fixed session ID of "dbsc_proxy", refresh URL of /dbsc_proxy/RefreshSession, the configured scope, and credentials of [{ type: cookie, name: session, attributes: <session cookie attributes>}]
    • Add a Set-Cookie: dbsc_proxy_upstream=aead({upstream_session, pubkey}) with the expiration (and all other attributes) from the upstream cookie
    • Add a Set-Cookie: session=timestamp;hmac(timestamp;<dbsc_proxy_upstream cookie value>) header. Set the expiration of this cookie to 15 minutes, and all other attributes to the values from the upstream cookie.

• On all requests, if there is a session cookie starting with dbsc_proxy:: and a dbsc_proxy_upstream cookie:

  • Verify that the cookie conforms to the format timestamp;hmac(timestamp;<dbsc_proxy_upstream>)
  • Verify that the HMAC is valid and the timestamp is within 15 minutes
  • Then, decrypt dbsc_proxy_upstream to get ({ upstream_session, pubkey }).
  • When sending the request upstream:
    • drop the dbsc_proxy_upstream cookie
    • set the session cookie to the upstream value.
    • Add a Dbsc-Proxy-Public-Key header with the public key from the dbsc_proxy_upstream cookie. The proxy should remove any client-provided Dbsc-Proxy-Public-Key headers. See below for how the application should use this header.
  • When sending back the response:
    • add a Secure-Session-Challenge response header, with the value new_timestamp;hmac(new_timestamp). We could also do this only if the short-lived cookie is nearing expiration. This challenge could even be cached by the proxy, regenerated every few seconds, and re-used for different clients / multiple requests.
    • If the response contains the header Set-Cookie: session=new_upstream_session, then the app is updating the upstream session value. Return:
      • Set-Cookie: dbsc_proxy_upstream=aead({upstream_session: new_upstream_session, pubkey}) with the expiration from the upstream cookie, to update the encrypted long-lived secret
      • Set-Cookie: session=timestamp;hmac(timestamp;<dbsc_proxy_upstream cookie value>), with a timestamp and cookie expiration equal to the request's session cookie timestamp and session cookie expiration. Do NOT update timestamp; use the value from the request -- the client has not provided possession of the private key, so we must not bump the timestamp.

• /dbsc_proxy/RefreshSession endpoint:

  • If Secure-Session-Response is not provided, provide the challenge new_timestamp;hmac(new_timestamp)
  • If a signed challenge is provided:
    • Verify that the challenge conforms to the format new_timestamp;hmac(new_timestamp) with a valid HMAC and recentnew_timestamp (1 minute?)
    • Decrypt the dbsc_proxy_upstream cookie to get ({ upstream_session, pubkey })
    • Verify that the challenge signature matches the decrypted pubkey.
    • If all that passes, respond with: Set-Cookie: session=timestamp;hmac(timestamp;<dbsc_proxy_upstream cookie value>). Set the expiration of this cookie to 15 minutes, and all other attributes to the values from the upstream cookie.

• Upstream apps SHOULD record the Dbsc-Proxy-Public-Key value used by requests in their persistent session storage. If, for a particular session, the upstream app observes the public key change, or receives a request without a Dbsc-Proxy-Public-Key header after receiving one with that header, it should reject the request.

  • This protects against an attacker who can steal the long-lived session cookie during registration, but cannot interfere with the DBSC registration flow. It provides similar security to a non-proxy implementation of DBSC, where the registration endpoint should invalidate the long-lived session cookie issued during the authentication flow (and returned to the client to preserve backwards compatibility with clients that do not support DBSC).
  • If the attacker can block the DBSC registration flow and steal the long-lived cookie, they can still execute a downgrade attack, by downgrading from a DBSC flow to a regular login flow and then stealing that long-lived login cookie. But this is a general issue with DBSC: an attacker who can interfere with registration (either by blocking it to downgrade the session to non-DBSC session, or by pre-empting the client's legitimate registration with a malicious registration tied to the attacker's public key) can circumvent DBSC.
  • If DBSC adds a mechanism to prevent this sort of downgrade (for example, a header provided by browser to request only device-bound sessions), the proxy could stop sending the long-lived session token back to clients during the registration process, and instead store that token in an encrypted cookie, so it can be read by the registration endpoint but not stolen by an attacker.

[drubery]

I think we can accomplish that by separating the upstream cookie value from the session ID and storing that in a separate, long-lived cookie. Making the upstream cookie mutable should avoid needing the upstream app to explicitly signal the start of a session, since one of my goals is for the proxy to work with no changes to an existing upstream app.

My point was that if there is no one upstream cookie that is just a "session ID", your approach won't work. I gave the example of signed cookies before, but another example might be a site that puts some user preferences in the cookie. {"user_id": 12345, "ux": "dark_mode"} for example, would mean that if the user toggles dark mode you'd be generating a new DBSC session on the proxy. The upstream app has to satisfy the constraint that there is a cookie that doesn't change unless the user logs in.

Regarding session IDs: Is having a hard-coded session ID that is the same for all clients valid? Is the purpose of having a Session ID at all just to allow apps where you might have a single client with simultaneous sessions?

One site with multiple sessions is what it was originally designed for. But there's no reason you can't have a session ID per user.

would it be safe to simplify the challenge to something like timestamp;hmac(timestamp) for both the initial and refresh challenges?

I think that's safe. It's a little strange not to know the session's most recent challenge, but I agree with your reasoning that we can't get a future challenge.

To your point about this only working for unsigned cookies: I'm not sure I agree.

My point wasn't that it doesn't work for unsigned cookies. Rather that if you're already signing your cookies your application endpoints are already doing everything they'd need to do for DBSC. So you need the new registration, endpoint, refresh endpoint, and changes at login, but most of your site is unchanged. That undercuts the value of using a DBSC proxy, but it doesn't mean it won't work.

For older / legacy apps, it's a way to protect the app without having to touch it at all

Totally agreed on this one!

Upstream apps SHOULD record the Dbsc-Proxy-Public-Key value used by requests in their persistent session storage

I'm not sure I've followed this part. Can you describe the threat you're mitigating against in a little more detail? Why is that threat so significant that it's worth being the only change to the upstream app?

[benweissmann]

My point was that if there is no one upstream cookie that is just a "session ID", your approach won't work. I gave the example of signed cookies before, but another example might be a site that puts some user preferences in the cookie. {"user_id": 12345, "ux": "dark_mode"} for example, would mean that if the user toggles dark mode you'd be generating a new DBSC session on the proxy. The upstream app has to satisfy the constraint that there is a cookie that doesn't change unless the user logs in.

Right, that makes sense -- agreed, and I've updated my design to allow for cookies that change arbitrarily.

One site with multiple sessions is what it was originally designed for. But there's no reason you can't have a session ID per user.

Got it -- so is there any reason to not use a single, static value (like "dbsc_proxy") as a hard-coded session ID for every user?

My point wasn't that it doesn't work for unsigned cookies. Rather that if you're already signing your cookies your application endpoints are already doing everything they'd need to do for DBSC. So you need the new registration, endpoint, refresh endpoint, and changes at login, but most of your site is unchanged. That undercuts the value of using a DBSC proxy, but it doesn't mean it won't work.

Yup, agreed.

Upstream apps SHOULD record the Dbsc-Proxy-Public-Key value used by requests in their persistent session storage

I'm not sure I've followed this part. Can you describe the threat you're mitigating against in a little more detail? Why is that threat so significant that it's worth being the only change to the upstream app?

Yeah, and I'm curious what your take is on the threat here -- I think you probably have a much better intuition than I do for what kinds of threats we're likely to see in the wild. The scenario i'm imaginging is malware that is able to log all cookies / exfiltrate them to an attacker, but is otherwise not tampering with or changing the behavior of the browser, blocking requests, or anything like that.

This recommendation is designed to defend against that. Without this protection, what would happen is:

1. The user authenticates with the app. The app returns Set-Cookie: session=some-long-lived-token
2. The DBSC proxy leaves that cookie as-is (so that user agents without DBSC support can keep using the existing login flow / long-lived tokens), and also adds the Secure-Session-Registration header.
3. The malware steals the long-lived token
4. The user agent makes a request to StartSession to begin a DBSC session, and gets back a Set-Cookie: session=short-lived-token header

At this point, the user agent has complete the DBSC session registration, but the attacker still managed to grab the token. Now, the attacker can use that long-lived token (pretending to be a non-DBSC-supporting client). With the protection I suggested, this wouldn't work because once the legitimate client registers the DBSC session and sends any request to server, the server will note that the session is using DBSC and reject the request (it's important that we store the specific public key and not just a boolean flag for whether the session is using DBSC, to prevent the attacker from doing their own request to StartSession later -- binding the first public key means that the attacker would need to do that faster than the browser does it, which is likely much harder).

I think this is a worthwhile risk to mitigate if all of the following:

• It's more likely that we see malware that scrapes all cookies (either by reading them from browser memory or cookie storage, or by getting read-only access to network traffic), than to see malware that does that, plus tampers with network traffic (in this example, if the malware interrupts the DBSC session registration, then it can use the long-lived token it stole, because the legitimate client never successfully completes DBSC registration). The reason I think this might be a reasonable threat model is that tampering with network traffic might be much more detectable than just harvesting credentials.
• It's likely that we'll see malware that hangs out on the victim's machine for some time and monitors for site logins, rather than just scraping stored cookies once or periodically. I think this is already a relatively common model for malware, and in a world where there's significant adoption of DBSC, I could imagine that malware might even delete session cookies to entice a user to log back in so it can grab long-lived cookies during session registration.
• We expect this pattern of servers returning the long-lived cookie alongside Secure-Session-Registration is going to be a recommended path for a while. I don't think I see this pattern explicitly recommended in this spec, but it's outlined in Chrome's developer docs. I'm curious if y'all considered having browsers that support DBSC (and where the user agent has the requisite hardware / secure enclave support) supply some sort of Secure-Session-Support=true header so that servers can skip sending the long-lived token to those clients?

If you do think this threat model is one that implementors should consider, it might be worth calling out in the "server considerations" section of the spec -- something like "The registration endpoint should revoke any long-lived, non-device-bound cookies issued during authentication, so an attacker who has stolen the long-lived cookie during authentication can no longer user it after the public key is bound during session registration"

[drubery]

Got it -- so is there any reason to not use a single, static value (like "dbsc_proxy") as a hard-coded session ID for every user?

Nope! Feel free to do that.

Now, the attacker can use that long-lived token (pretending to be a non-DBSC-supporting client).

Ah, yeah. I think we want one more piece in the proxy. For a stateful server, once you've registered a DBSC session, the application endpoints must be validating the presence and validity of that short-term cookie. This is a little challenging for a stateless proxy, but DBSC assumes there is no malware at login time (see next section). So I think you can make it safe if your long-lived token just included "is DBSC user". That's initially false, and gets reissued with a true value when registration completes. If malware becomes present on the device after the value has been set to true, it can't get access to a long-lived token that doesn't require DBSC.

It's likely that we'll see malware that hangs out on the victim's machine for some time and monitors for site logins, rather than just scraping stored cookies once or periodically. I think this is already a relatively common model for malware, and in a world where there's significant adoption of DBSC, I could imagine that malware might even delete session cookies to entice a user to log back in so it can grab long-lived cookies during session registration.

Yes you're definitely right about this. DBSC's threat model has to assume there is no malware present at login time. If there is malware of equal privilege to the browser, then all bets are off. The malware could replace the browser binary entirely or prevent the real browser from accessing the TPM, or disrupt DBSC in all sorts of ways. You might be right that there's nuance here, though. I'd imagine every EDR/AV in the world would alert if some random unsigned exe replaced the browser entirely. Maybe long-lived passively observing malware is more tractable. And maybe we can do something about those? But we're kind of waiting to see how attacks shift as DBSC rolls out. Attackers could try to be present at login or force login, like you note. They could also proxy requests through the original device. We'll have to design for the attacks we see starting to scale.

I'm curious if y'all considered having browsers that support DBSC (and where the user agent has the requisite hardware / secure enclave support) supply some sort of Secure-Session-Support=true header so that servers can skip sending the long-lived token to those clients?

I think we've always thought that functionality should be a JS API, rather than a new header. And for that case, it's #117.

[benweissmann]

Ah, yeah. I think we want one more piece in the proxy. For a stateful server, once you've registered a DBSC session, the application endpoints must be validating the presence and validity of that short-term cookie. This is a little challenging for a stateless proxy, but DBSC assumes there is no malware at login time (see next section). So I think you can make it safe if your long-lived token just included "is DBSC user". That's initially false, and gets reissued with a true value when registration completes. If malware becomes present on the device after the value has been set to true, it can't get access to a long-lived token that doesn't require DBSC.

Yup, that makes sense. I think the proxy already handles this -- after session registration, it re-issues the session cookie to be a short-lived cookie (replacing the long-lived one issued by the app during authentication), and then issues the long-lived dbsc_proxy_upstream cookie, which includes the (encrypted, authenticated) public key and can't be used for anything except renewing the short-lived cookie with proof of possession of the corresponding private key. So once session registration is complete, the client only has a short-lived cookie and a long-lived device-bound cookie; the initial long-lived cookie has been replaced.

It's likely that we'll see malware that hangs out on the victim's machine for some time and monitors for site logins, rather than just scraping stored cookies once or periodically. I think this is already a relatively common model for malware, and in a world where there's significant adoption of DBSC, I could imagine that malware might even delete session cookies to entice a user to log back in so it can grab long-lived cookies during session registration.

Yes you're definitely right about this. DBSC's threat model has to assume there is no malware present at login time. If there is malware of equal privilege to the browser, then all bets are off. The malware could replace the browser binary entirely or prevent the real browser from accessing the TPM, or disrupt DBSC in all sorts of ways. You might be right that there's nuance here, though. I'd imagine every EDR/AV in the world would alert if some random unsigned exe replaced the browser entirely. Maybe long-lived passively observing malware is more tractable. And maybe we can do something about those? But we're kind of waiting to see how attacks shift as DBSC rolls out. Attackers could try to be present at login or force login, like you note. They could also proxy requests through the original device. We'll have to design for the attacks we see starting to scale.

Yup, that makes sense -- I think i'll probably include a Dbsc-Proxy-Public-Key header in the upstream requests anyway, in case the upstream application wants to do something like include it in audit logs or show which users are using DBSC. But I'll hold off on recommending that upstreams track it in the session and reject requests if it changes, until we see more about whether that would actually help prevent real-world attacks.

I think we've always thought that functionality should be a JS API, rather than a new header. And for that case, it's #117.

Gotcha, make sense!

I think I have everything I need to work on a prototype -- thanks again for talking this through! I'll share what I've got once I've built it.

[benweissmann]

I think I have this working! Here's what I have: https://github.com/benweissmann/dbsc-proxy -- I've only tested it against a stock Django app, but I think it should work for an arbitrary upstream cookie value.