Verification of delegated ActivityPub profiles #98

cuteBoiButt commented 2024年04月07日 07:15:47 +02:00

"Delegated" in the same sense that matrix uses it, for example, here: https://matrix-org.github.io/synapse/latest/delegate.html
(hosting on sub.example.tld while preserving federated @username@example.tld usernames)

Digging through the code, it seems like doipjs does not perform any WebFinger requests for AP validation at all, which means it will fail to validate https://example.tld/@username AP claims for delegated profiles cuz there is just nothing there, actual profile is hosted on a different (sub)domain.
Is there any specific reason as to why no WebFinger request is performed for AP validation if initial attempt to locate profile at provided url fails?

Example of a failed validation: https://keyoxide.org/hkp/61ADEA93AEEC0534176B36494C82DB4C8F1BA6FA

My setup looks like this:
i have a 301 redirect for both webfinger and nodeinfo endpoints pointing to the subdomain hosting AP capable software, like so:
example.tld/.well-known/webfinger 301 => sub.example.tld/.well-known/webfinger
example.tld/.well-known/nodeinfo 301 => sub.example.tld/.well-known/nodeinfo

sub.example.tld/.well-known/webfinger endpoint will return { subject: "acct:username@example.tld", ... } when looking up either acct:username@example.tld or acct:username@sub.example.tld which allows to establish a two-way relationship between example.tld and sub.example.tld in order to prevent any hijacking by a malicious 3rd party.

I know this approach is not standardized, but this appears to be the only way to achieve delegation atm.
And it seems to be enough for other popular AP-capable software, namely Mastodon, to correctly recognize delegated profiles "hosted" on @example.tld and properly federate with them.
(try looking up @cuteBoiButt@torchmc.ru on your favorite Mastodon instance to see this in action :з)

I can try to cook up a pr improving AP validation to support such setups if there are no objections ^.^

"Delegated" in the same sense that matrix uses it, for example, here: https://matrix-org.github.io/synapse/latest/delegate.html (hosting on `sub.example.tld` while preserving federated `@username@example.tld` usernames) Digging through the code, it seems like doipjs does not perform any WebFinger requests for AP validation at all, which means it will fail to validate `https://example.tld/@username` AP claims for delegated profiles cuz there is just nothing there, actual profile is hosted on a different (sub)domain. Is there any specific reason as to why no WebFinger request is performed for AP validation if initial attempt to locate profile at provided url fails? Example of a failed validation: https://keyoxide.org/hkp/61ADEA93AEEC0534176B36494C82DB4C8F1BA6FA My setup looks like this:  i have a 301 redirect for both webfinger and nodeinfo endpoints pointing to the subdomain hosting AP capable software, like so:   `example.tld/.well-known/webfinger` 301 => `sub.example.tld/.well-known/webfinger`   `example.tld/.well-known/nodeinfo` 301 => `sub.example.tld/.well-known/nodeinfo` `sub.example.tld/.well-known/webfinger` endpoint will return `{ subject: "acct:username@example.tld", ... }` when looking up either `acct:username@example.tld` or `acct:username@sub.example.tld` which allows to establish a two-way relationship between `example.tld` and `sub.example.tld` in order to prevent any hijacking by a malicious 3rd party. I know this approach is not standardized, but this appears to be the only way to achieve delegation atm. And it seems to be enough for other popular AP-capable software, namely Mastodon, to correctly recognize delegated profiles "hosted" on `@example.tld` and properly federate with them. (try looking up `@cuteBoiButt@torchmc.ru` on your favorite Mastodon instance to see this in action :з) I can try to cook up a pr improving AP validation to support such setups if there are no objections ^.^

cooperaj commented 2024年10月25日 12:48:07 +02:00

I can try to cook up a pr improving AP validation to support such setups if there are no objections ^.^

Did you find any time to take a look at this?

I think I've seen this issue before but can't find it. The main problem is that there is no official/proper way to reverse engineer a webfinger endpoint or acct from an ActivityPub actor uri - which is what you add to your PGP key. There is an upstream bug in the Mastodon repo that talks about solutions for this but it's not gone anywhere.

From keyoxides point of view the only way to do this right now is to brute force the checks i.e. keep trying subdomains until the webfinger attempts fail or you run out of them. But that doesn't cover the possibility that your handle exists on a completely different domain (which is allowed). That said that could be exceedingly rare.

A possible pseudo algorithm could be:

1. Access https://social.services.example.com/users/actor
2. Find Mastodon/ActivityPub profile
3. Derive and access https://social.services.example.com/.well-known/webfinger?resource=acct:actor@social.services.example.com
   a) It specifies the 'subject' as 'acct:actor@example.com'
4. Derive and access https://example.com/.well-known/webfinger?resource=acct:actor@example.com
5. Verify it matches the response of 3) and contains the URI of 1)

As I've said though, deriving the URL in 3) from the profile URI of 1) is the tricky part and would mostly just be guesswork on keyoxides part.

EDIT
That said, having now looked at the code, some derivation work is already being done in the implementation to get display name. It shouldn't be too hard to implement the above using that information.

> I can try to cook up a pr improving AP validation to support such setups if there are no objections ^.^ Did you find any time to take a look at this? I think I've seen this issue before but can't find it. The main problem is that there is no official/proper way to reverse engineer a webfinger endpoint or acct from an ActivityPub actor uri - which is what you add to your PGP key. There is an upstream bug in the Mastodon repo that talks about solutions for this but it's not gone anywhere. From keyoxides point of view the only way to do this right now is to brute force the checks i.e. keep trying subdomains until the webfinger attempts fail or you run out of them. But that doesn't cover the possibility that your handle exists on a completely different domain (which is allowed). That said that could be exceedingly rare. A possible pseudo algorithm could be: 1) Access https://social.services.example.com/users/actor 2) Find Mastodon/ActivityPub profile 3) Derive and access https://social.services.example.com/.well-known/webfinger?resource=acct:actor@social.services.example.com a) It specifies the 'subject' as 'acct:actor@example.com' 5) Derive and access https://example.com/.well-known/webfinger?resource=acct:actor@example.com 6) Verify it matches the response of 3) and contains the URI of 1) As I've said though, deriving the URL in 3) from the profile URI of 1) is the tricky part and would mostly just be guesswork on keyoxides part. EDIT That said, having now looked at the code, some derivation work is already being done in the implementation to get display name. It shouldn't be too hard to implement the above using that information.