Does the instance actor have special privileges?
-
infinite love ⴳreplied to Erin 💽✨ @38C3 on last edited by
@erincandescent @julian @thisismissem @silverpill Mastodon I think considered the idea of trying first with the instance proxy key and then if that failed try again with your key.
This makes it better from a usability perspective but the security qualities are just as lacking as before. The server could theoretically try with any/every user’s key. You end up having to put a lot of trust in the server anyway, so you fall back to having origin-based security anyway…
-
@silverpill @thisismissem @julian Yeah, it raises the bar very slightly to say that instead of any key on a domain, you need to use a specific key id on the domain. But it could be the same key material, and that wouldn’t even hurt security meaningfully.
-
@[email protected] I opened the issue in the Sharkey repo and received a response that is along the lines of what was discussed here:
For privacy, Sharkey (and all other Misskey forks) fetch unknown posts using the instance.actor account. This works for public posts, but breaks for followers-only / direct messages.
...
Any "simple" fix would allow remote instances to de-anonymize local users, which is the same vulnerability that Mastodon has had for years.Which is fair. I was thinking that one could simply assume that the recipients of the received object would be an identical set of subset of
inReplyTo, but that is not a guarantee at all! -
> treat the resolved actor via HTTP signature to be like an API token, it's basically a fancy password!
yup, exactly. imagine if we used out-of-band bearer tokens. same principle. same with DPoP. the keys are all custodial in most cases. any “security” comes from the bidirectional link between actor and key (and it’s not much, but it’s barely enough to establish an identity at all)
-
End of the day we're talking about machines talking to other machines. I can see potential privacy concerns, but it seems like it would be hard to utilise as a malicious actor... but I've no opsec expertise.
@[email protected] @[email protected] @[email protected] @[email protected]
-
@julian @silverpill @erincandescent @thisismissem Security-wise all bets are off if you want to establish anything other than “the signature claims to be from this key, and the key claims to be owned by this actor, and the actor links back to the same key, so we can assume the actor’s controller is the signing party”
note that i said “actor’s controller” and not just “actor”. this is an important distinction. just like web keys are custodial, web actors are custodial too
-
Erin 💽✨ @38C3replied to infinite love ⴳ on last edited by@trwnh @julian @silverpill @thisismissem fundamentally trust lies in the server here; if you're not using LD signatures (and maybe even then?) I'm pretty sure you'd actually be fine to use one public key for every user
But what matters is the authorisation identity, not so much the key itself; in the fully general case it is impossible for a server to know everyone who should have access to a third party object (b/c BTo/BCC + implementation defined features), so when a user explicitly requests a resource then the server should use their identity -
infinite love ⴳreplied to Erin 💽✨ @38C3 on last edited by
@erincandescent @julian @thisismissem @silverpill it matters that the key claims to be owned by an actor, and that the actor claims to own that key. the actual cryptography is merely a formality to link the http request to the public key through the private key. a “fancy password” like julian said.
-
infinite love ⴳreplied to infinite love ⴳ on last edited by
@erincandescent @julian @thisismissem @silverpill also trust lies in the server application but there’s no way to identify a server separately from the hostname(s) it’s running on. hence why/how gleason was able to circumvent signed fetches by simply using a different hostname
-
Erin 💽✨ @38C3replied to infinite love ⴳ on last edited by
@trwnh @julian @thisismissem @silverpill In any case I don’t think “origin based authentication” for fetches is a good idea for the simple reason that its not, to my knowledge, what implementations do today and it strongly risks leaking private posts. Certainly what the ActivityPub spec heavily implies if not outright says is that anything fetchable via a given identity should be visible to that identity, and I’m generally iffy on the idea of trying to make implementations execute potentially complicated ACLs on behalf of each other; that way is certainly a security disaster.
So that then leaves us with the question: is leaking the identity of the actor who has pasted a post’s URL into their instance’s search bar a real issue?
-
@trwnh @julian @silverpill @thisismissem To some degree my opinion is of course coloured “no, its not an issue” here by the fact that I run a single user instance; whether it came from
[email protected]or[email protected]there is little ambiguity as to whether it was me. -
@julian @silverpill @thisismissem @trwnh this is the part of the conversation where if she were still involved in things Christine would bust in and start shouting “OCapPub!!!!” at us all
-
infinite love ⴳreplied to Erin 💽✨ @38C3 on last edited by
@erincandescent @julian @thisismissem @silverpill yeah i think proxying your request has less value the less users you have, but it’s a nonzero value for any server with more than one user. but also users should have a checkbox in ui to say “try this request as me”.
-
Jenniferplusplusreplied to Erin 💽✨ @38C3 on last edited by
@erincandescent @julian @thisismissem @trwnh @silverpill
I don't think it is a real problem. Especially when you balance the reader's desire for anonymity with the author's desire to know who they're talking to.My larger concern is there's no good way to sustain this restriction over time. Once the server has those posts, it has no reliable way to restrict authorization on them, and no way at all to check authorization with the origin other than to fetch them all over again with a new key.
-
Erin 💽✨ @38C3replied to Jenniferplusplus on last edited by
@jenniferplusplus @julian @thisismissem @trwnh @silverpill
All of the following asssumes you are caching the remote object:
In the common case, the people who can view it are listed directly in the recipients or are in a collection where the server can know all local users who are members (e.g. a followers collection). You can just drive your decisions off of the straightforward ACLs in the message.
For “undisclosed” recipients (delivered directly to the actor’s inbox but no addressing property, or fetched by this actor), you can maintain a private list of additional recipients who are allowed to view the post
In the case that an actor who is not in either the in-post recipient lists or your “known extra recipients” list tries to access the post, you must send a request to the origin to find out if they have access permission. You can optimise this by sending the usual HTTP caching headers (If-None-Match, etc) alongside your authorization header(s). If the remote permits them, you addt hem to the list.
-
-
@[email protected] if you have no user context, then it makes sense... but in the two use cases I mentioned, you do.
- Resolving via search bar, user initiated.
- Retrieving
inReplyTo, user can be assumed from leaf nodetoorcc(although whether that's a wise assumption is up for debate)
