Origin checking between servers

Jason Culverhouse :flipboard:

> some form of verification

You verify the "origin" by validating the HTTP Signature on the request and that it is signed by a key that belongs to the `actor` in the activity.

If the `actor` that signed the HTTP request is different than the `actor` of the activity you verify the content via the JSON-LD signature on the activity and that the signature signing key belongs to the `actor` of the activity.

Jenniferplusplus

@julian
The verification can be fetching it by ID, but it doesn't have to be. I think you can trust that objects you receive that are attributed to the actor and hosted at the same authority as the actor are valid. More generally, you should have some authorization mechanisms for federated activities.

@hrefna

julian

@[email protected] Are JSON-LD signatures implemented broadly? Mastodon's docs state the following in a warning box:

... the LD Signatures specification as a whole has been superseded by the Verifiable Credential Data Integrity 1.0 specification, which is largely incompatible with the earlier LD Signature spec. For this reason, it is not advised to implement support for LD Signatures.

I'll admit I do not know whether there has been an effort by SWICG to compile a descriptive report on the state of security in ActivityPub implementors, but I would be interested in learning more.

julian

@[email protected] said:

I think you can trust that objects you receive that are attributed to the actor and hosted at the same authority as the actor are valid.

I think that's fair. If I recall correctly the main concern was Activity spoofing by third parties (e.g. Receiving Update(Note) from domainA for a Note whose origin hostname is domainB).

Each individual code path does their own checking if needed, so in the example above, Update handling actually does origin checking too (since the passed-in object is a uri, and thus not subject to checking via upstream middleware), but now that is a case of DRY.

Question is, what activity-pairs explicitly need origin checking... or conversely, is a deny-list a better fit? (e.g. Announce(Note) can refer to Notes outside of the actor origin, so don't do an origin check)

Erin 💽✨

@julian @jenniferplusplus *every* path needs an authority check

In the case of Announce(Note), where the Note is from a different origin from the authenticating key, you should fetch it rather than trusting the embedded object

Emelia 👸🏻

@julian isn't there also a FEP for object signatures? e.g., signing the Activity as a whole with the Actor's private key? (I can't recall the trade-offs here)

cc @jenniferplusplus

Erin 💽✨

@julian @jenniferplusplus one option is just walking the tree of objects and every time you find an object with an id from a different origin than the http signature key, replace it with the result of fetching

julian

@[email protected] @[email protected]

I believe that would be @[email protected]'s FEP-8b32?

Erin 💽✨

@jenniferplusplus @julian (alternatively just replace them with stubs and fetch lazily if needed)

Emelia 👸🏻

@julian yup.

julian

@[email protected] Yes, I think that's what @oplik0 and I ended up agreeing on. If we normalize all incoming requests so that any requests containing a full object on a different domain is just reduced down to its id, then you'd safeguard yourself from most edge cases. Applying FEP-8b32 would be handy to save yourself a few network calls but is optional.

The cost is you might have to make a couple extra calls, but it's probably worth it in order to keep the logic simple, predictable, and easily auditable.