Some "fun" commentary on activitypub and httpsig and the don

Every AP user has a private key stored somewhere on the server, which it uses to sign outgoing messages to other servers, in an http header. On first contact, the receiving server has to fetch the public key from the sending server, and then usually caches it.

Two weeks ago I decided it was unwise to cache keys forever. If a remote loses their private key, the baddie can forge messages. Recovery is generally the origin rotates all keys, but there's no way to clear a distributed cache. Just have to wait until a receiving server notices a sig failure, then refetches the public key to check again. So there's a large window to forge messages to servers that aren't in regular contact. So I changed honk to not cache forever.

This is fine. I delete the cached public key after a few days, a new message arrives, I refetch the public key. Except for the magical mastodon secure mode. Super secure mastodon will send me messages, but not allow me to fetch the corresponding public key. This seems suboptimal.

The punchline is a few people I used to follow can no longer be followed because I can't verify the messages their server sends me. Used to work because the key was cached from years ago, before the time of super duper security, but after I expired the key, I can't refetch it. Whoops.


@tedu This recent suggestion on the Mastodon bug tracker proposing to enable authorized fetch by default might be of interest to you:

I have vague memories of there having been several problems with the implementation in Mastodon, but in general the requirement seems to be that your outgoing requests are properly signed too?

@galaxis it's not like it's so hard to implement, but i think people have a rather exaggerated sense of what it accomplishes, so I'd rather not. ah well.
Sign in to participate in the conversation
INFRa Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!