Question re: PeerTube's pubkey IDs

Steve Bate

silverpill1:

I'm using the term "origin" as defined in RFC-6454. This is also what FEP-fe34 refers to.

Thanks for the clarification.

silverpill1:

FEP-fe34 doesn't require embedded object to have same origin as the containing object (but it says that embedded object with a different origin shouldn't be trusted).

I was referring to the Athentication section that states four conditions (none of which are satisfied for an embedded actor key from a different web origin) and says:

If none of these conditions are met, the object MUST be discarded.

If the embedded "object" is the key in the actor fetch scenario, discarding it wouldn't be desirable. If you intended to suggest that the key/object should be dereferenced for verification, the wording should be changed.

silverpill1:

FEP-fe34 doesn't mention actor/key relationship because location of an actor document is not important for authentication via HTTP signatures. Only location of a key is important.

After rereading the FEP Authentication several times, I think( I see what you are trying to specify. You want the HTTP Signature key web origin to be the same as a POSTed activity URI web origin (but it could be different than the actor URI web origin?). However, I don't know why you believe that specific key/activity web origin restriction is necessary.

silverpill1:

As far as I know, all existing implementations behave in this way and don't put public key on a different server than actor.

To the extent the FEP is documenting existing practices (although using requirements language), that's fine. Developers should be aware that the way Mastodon-like servers have implemented AP+Signatures is not the only valid way to do it. Like I said before, even Mastodon doesn't appear to have the restrictions that you are proposing (for incoming posted activities).

silverpill1:

If some document contradicts both FEP-fe34 and implementer consensus, it is probably not correct and should be fixed. I can look into it if you point to a specific paragraph or sentence.

I'm not sure it contradicts the SocialCG's HTTP Signature, but it adds unnecessary and undesirable restrictions to it. You can also take a look at Mastodon's handling of HTTP Signature key verification to explore how the FEP differs from current practice. It might also be useful to have a section discussing the similarities and differences with current popular server implementations.

Also, about web origin... the AP specification uses the term "origin" in a very ambiguous way. It doesn't reference web origin (RFC-6454) at all. Some references to "origin" appear to mean the "actor who originated an activity". For example,

The receiving server MUST take care to be sure that the Update is authorized to modify its object. At minimum, this may be done by ensuring that the Update and its object are of same origin.

This could be interpreted as the Update should originate from the same actor as the object being modified, which is reasonable. That interpretation doesn't require the actor and the object URIs to have the same RFC-6454 web origin.

Again, it's very ambiguous so it's possible to have different interpretations. However, I don't agree with some parts of the FEP-fe34 interpretation.

silverpill

@julian Did you report this bug to PeerTube?

julian

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

silverpill

@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]

stevebate:

If the embedded “object” is the key in the actor fetch scenario, discarding it wouldn’t be desirable. If you intended to suggest that the key/object should be dereferenced for verification, the wording should be changed.

Yes, it should be dereferenced. This is currently covered in "Emdedded objects" section, but I see how that might be confusing. I submitted a pull request that moves this requirement closer to the list of authentication methods: https://codeberg.org/fediverse/fep/pulls/468.

stevebate:

but it could be different than the actor URI web origin?

In the context of authentication, activity ID and actor ID may have different origins. However, the second part of the FEP (titled "Authorization") prohibits this:

Identifier of an object and identifier of its owner MUST have the same origin.

In other words, actor MUST NOT own objects from different origin.

stevebate:

However, I don’t know why you believe that specific key/activity web origin restriction is necessary.

This restriction comes from the origin-based security model described in the FEP. When an HTTP signature is verified, the trust chain is established: activity -> public key (via keyId parameter) -> server.

To remove this restriction, some kind of cross-origin verification mechanism is needed. So far, I have not seen any evidence that such mechanism is actually necessary. Unnecessary complexity should be avoided.

stevebate:

To the extent the FEP is documenting existing practices (although using requirements language), that’s fine. Developers should be aware that the way Mastodon-like servers have implemented AP+Signatures is not the only valid way to do it. Like I said before, even Mastodon doesn’t appear to have the restrictions that you are proposing (for incoming posted activities).

FEP-fe34 is based on existing practices, but it doesn't describe exact behaviors, which vary significantly between implementations. If Mastodon is not compliant with FEP-fe34, that might not be a problem, sometimes the risk is quite low (e.g. authentication of emojis). I suspect that some popular server implementations are vulnerable to cache poisoning attacks, but I don't plan to audit them.

stevebate:

Also, about web origin… the AP specification uses the term “origin” in a very ambiguous way. It doesn’t reference web origin (RFC-6454) at all.

FEP-fe34 needs to provide clear instructions to developers, so I used RFC-6454 as a reference. ActivityPub spec is useless when it comes to authentication and authorization. I don't think its authors understood these aspects, otherwise there would be no need for FEP-fe34. Even developers who are very experienced with AP have limited understanding (ActivityPub was published in 2018; GHSA-3fjr-858r-92rw, which affected many projects, was published in 2024).

a

silverpill:

ActivityPub was published in 2018; GHSA-3fjr-858r-92rw, which affected many projects, was published in 2024

I would argue that there is an entire class of errors and vulnerabilities that arise from the lack of proper authentication/authorization that are not solved by solved by same-origin, and in fact might be made worse by it!

By my understanding, the cited GitHub security advisory deals with fetching a document from some location, while describing a subject whose id that does not match that location.

There is nothing inherently wrong with this! The claim you should be verifying is a different claim than the one that is actually being verified:

Incorrect: The current document is an authentic representation of the current resource.
Correct: The current document is authorized to make authentic statements about a given resource.

Understandably, it is easier to establish the former than the latter; we simply assume that anything can make authentic claims about itself. The descriptor document served at the URI in the id is conflated with the thing itself.

Trying to establish the latter usually goes no further than same-origin at most. If you assume that every URI on a given authority has the same controller, then this is fine. But this is a false assumption, because URI authority can be delegated at any point along the path, for example by configuring a web server to pass requests on a certain prefix to a different application entirely. /media might be served by a different application entirely than /users. This shouldn’t be a problem, but it is a problem because the real authority is never specified; the same origin assumption is used instead of establishing any real authority.

The error in logic that caused the vulnerability was conflating the two claims. Instead of passing down the document location, Mastodon passed down the id, because Mastodon assumed they would always be the same, but they are not always the same.

In fact, the related security advisory GHSA-jhrq-qvrm-qr36 demonstrates another fallacy of the "same-origin" line of thinking. The way that this security advisory is framed is actually papering over the flaws of same-origin instead of addressing the actual underlying issue. The assumptions being made by fediverse software aren't being corrected, they're just being augmented with other assumptions which may themselves be incorrect. The end result is a far more complicated security model built on quirks. Whenever the next vulnerability happens due to same-origin being insufficient, it will probably lead to yet another ersatz requirement being placed on what constitutes a "valid" or authentic activity, object, post, profile, key, etc.

I don't see a good reason to continue placing such unnecessary requirements. Identity servers and keyservers shouldn't be discarded entirely and for no good reason; this just creates unnecessary fragility where a bidirectional claim is sufficient (actor declares key as representative; key declares actor as controller). Actors and their objects shouldn't be locked to the same domain; this unnecessarily creates barriers to real distributed systems and to cross-domain migration.

In short, "same origin" is a model that might be sufficient for centralized models of security, but it is insufficient for true decentralized security. I don't think it's a good idea to enshrine the assumption that a single server rules everything on that domain, or that there is only one such server possible.

Instead, we should strive to recognize not just the properties of objects, but also who is claiming these properties. Before merging graphs or datasets, we should establish that they (or their associated document) are trustworthy about the claims contained within. This is in effect what "object proofs" should be doing -- signing the graph or subgraph containing only statements about a single subject.

silverpill

@julian Fixed: https://github.com/Chocobozzz/PeerTube/commit/038c41030858a98071200cdbb2b134aeaac7be9a

Steve Bate

Side question: why do I sometimes see multiple copies of a message in SocialHub? The previous two messages are apparently published from "this site" and "mitra.social". Do they have different activity/object URIs? If the AP URIs are the same, does the Discourse plugin not dedup them?

Julian Lam

It seems like a bug unrelated to deduplication, although that was my first thought as well. @silverpill's reply came from mitra.socialonly, and the fact that Discourse (as SocialHub) handled that and reported that another post came from itself suggests that perhaps it went down a logic path that is normally reserved for local posts.

But this is only conjecture. Pinging @angus!

[email protected]

devnull:

the fact that Discourse (as SocialHub) handled that and reported that another post came from itself suggests that perhaps it went down a logic path that is normally reserved for local posts.

My theory: conflict between Create and Announce(Create)

Federated SocialHub Categories

SocialHub admins can federate categories, making categories accessible in the fediverse. This is an overview of current ActivityPub actors that you can follow and participate in from the Fediverse. SocialHub Categor…

SocialHub (socialhub.activitypub.rocks)