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.

[sondreb]

I'm not 100% into the Pubky protocol and ecosystem yet, so take my feedback for what it is. Just some thoughts on the question at hand here:

Signing each message and validating signature on all data received is the only way to ensure that users are safe and protected against man-in-the-middle attacks. This is very popular in China and was popular in USA. In China they are still restricting usage of HTTPS for some traffic.

If no signature validation happens on client, what the users are served from their homeserver can be manipulated. This happened all the time back in the day, where ISPs injected their own JavaScript on all websites that their customers visited without HTTPS.

So you got the problem with data being manipulated, the other issue is obviously that everyone on the network between user and server, can read everything, log it, analyze it, etc. Like nobody would want to put any sensitive information on their homeservers unless setup with secure connection.

I think a solution is to have a secure protocol that runs on HTTP, which mitigates the problem of relying on centralized DNS/TLS infrastructure, but it still enables a secure channel for users over HTTP. This can also be added ontop of the homeserver/Pubky protocol, to avoid populating that protocol with additional features. I have not looked into such protocols in many years, but always dreamt about it.