this post was submitted on 30 Dec 2024
0 points (NaN% liked)

ActivityPub

0 readers
1 users here now

Focused discussion related to ActivityPub integration in NodeBB

founded 6 months ago
0
Question re: PeerTube's pubkey IDs (community.nodebb.org)
submitted 2 weeks ago by [email protected] to c/[email protected]
7 comments fedilink hide all child comments
 

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.

top 7 comments
sorted by: hot top controversial new old
[–] [email protected] 1 points 4 days ago (1 children)

@julian Did you report this bug to PeerTube?

[–] [email protected] 0 points 4 days ago (1 children)

@[email protected] not yet, although I should open an issue, thanks for the reminder!

[–] [email protected] 1 points 4 days ago (1 children)

@julian I am affected by it as well, which is strange because previously federation with PeerTube worked fine. Perhaps they broke it in a recent release

[–] [email protected] 1 points 2 weeks ago

@julian I think URL comparison should not be done as a string. Like @silverpill said, fragments are stripped before comparison, alongside the usual other considerations (normalized query parameters, UTF and case normalization for the hostname, etc)

[–] [email protected] 1 points 2 weeks ago

@julian iirc, that hash fragment part isn't exactly spec behavior?

[–] [email protected] 1 points 2 weeks ago

@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