Authorization by Session cookies is vulnerable to untrusted proxies, can/should we do better?

[Nuhvi]

Problem statement

Currently (pubky v0.3.0 / Nov 15th 2024) we authorize clients using session cookies, these are opaque tokens that are presented to the Homeserver as is, and any holder of such token can read/write data on behalf of that original client that it was issued to.

This presents us with a challenge when we want to proxy requests through untrusted third parties that can read the clear unencrypted HTTP headers, since we effectively give them all the read/write access that the client has because they can copy that session token.

Like proxies, users may want to hire a Mirroring service, and use DNS load balancing in Pkarr to help clients failover to the mirrors if the main Homeserver is unavailable, these Mirrors can proxy the write operations or just reject them, but at least they can serve GET requests as they have up to date copy of the entire data (or some of it). However Mirrors only need global read access to mirror all user's data, they don't need to be trusted to write on client's behalf. But because session cookies work the same for read and writes, Mirrors get write access just because they can read the cookies in user's requests.

Can we do better

There are another two ways I can think of that improves this vulnerability:

1. Time-based One Time Passwords (TOTP) using a secret only known to the client.
2. Signing each request (by formatting relevant parts of the HTTP request in deterministic way), using the shared secret and HMAC, which is much faster than arymetric signatures (keypairs).

Solution no 1 is simpler, but solution no 2 is safer. But even in the case of TOTP, the attacker can only write to the Homeserver once (if they change the message instead of proxying as it is), because that TOTP they can read, can't be used for any more writes.

Should we do better than cookies?

Pros

1. Safer authorization method
2. Enable proxies and other complex setups without compromising security (even if they compromise privacy).
3. Less reliance on browsers behavior managing cookies.

Cons

1. Clients have to do more work instead of relying on browsers (user agents) to forward cookies.
2. Clients need to store their own secrets safely in local storage or elsewhere.
3. CLI clients are not as convenient as adding a cookies header or using a cookies file.. since each request has a different authorization token that needs to be calculated on the fly.

Should we do both?

A simple way to get around the cons of this new method, is to keep the support of the old method in parallel, however this increases the complexity on the server side, and it reduces the incentive to follow the better more secure practice.

Another problem is that clients can't tell whether their requests are going to be proxied or not, so they can't switch between methods as appropriate.