Question re: PeerTube's pubkey IDs
-
As part of security checking for incoming events, we check that the
keyId
sent in the HTTP signature is actually owned by the actor that the activity came from. This is to guard against activity spoofing from separate users at the same server (e.g. userB@server
pretends to send aCreate(Note)
from userA@server
).Our check is pretty simple, the
keyId
matched against the public key id as retrieved from the actor.Except it fails for PeerTube because:
- PeerTube's actors all have the
#main-key
suffix on their public key IDs (e.g.https://tilvids.com/accounts/thelinuxexperiment#main-key
) - The HTTP Signature's
keyId
does not include the#main-key
suffix (e.g.https://tilvids.com/accounts/thelinuxexperiment
)
So the key ownership cross-check fails.
I could adjust the logic to strip out the URL's hash, but I was wondering if that was actually secure. I assume this is what is already done since PeerTube successfully federates with other softwares.
- PeerTube's actors all have the
-
@julian iirc, that hash fragment part isn't exactly spec behavior?
-
ideally peertube would use keyId to link to the key and not to the actor, but i would guess that the way that this is handled in other softwares is to implicitly accept both keys and actors. so don't just always strip the hash, but instead only strip it for the initial HTTP GET. maintain the hash when checking for key
id
. but you'll still have to handle the invalid case where the keyId is actually an actor. -
-
Thanks all;
- @thisismissem@hachyderm.io I wasn't actually sure which spec this was a part of (although to be honest I also wasn't planning on reading through a spec to find out)
- @trwnh@socialhub.activitypub.rocks this is for verification on receipt of activity, not for an unsolicited GET from me. Didn't think it was a link to the actor id, but that makes sense!
- @silverpill@mitra.social yeah origin based security deems it safe, but I don't happen to like that security model, personally. I suppose that is the tradeoff... Plus someone could just assign the same pubkey to every user, rendering the whole exercise moot.