Skip to content

Question re: PeerTube's pubkey IDs

Uncategorized
  • 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. user B@server pretends to send a Create(Note) from user A@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.

  • @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.

  • @julian Yes, this is secure because web origin remains the same. I simply remove the fragment, it works for everything except GoToSocial.

    Nevertheless, mismatch between signature keyId and publicKey.id is a bug.

    cc @peertube

  • 😅 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.

Diese Artikel könnten Dich auch interessieren.