[question] Does Akkoma handle `(created)` pseudo-header in HTTP signatures

tsmethurst commented

2024-06-09 20:03:52 +00:00

Hiya, in GoToSocial v0.16.0-rc1 we've switched from using the Date header in outgoing HTTP signatures to using the (created) pseudo-header described here: https://datatracker.ietf.org/doc/html/draft-cavage-http-signatures-12#section-2.1.4

So the Signature header on outgoing GtS GET requests now looks something like this:

keyId="https://example.org/users/someone/main-key",algorithm="hs2019",created=1717961994,headers="(request-target) (created) host",signature="[LONG_STRING_OF_BASE64_STUFF]"

I tested this against Mastodon and the *keys and it seems to work just fine there, but I was recently told it might not be working correctly for Akkoma, and indeed trying to fetch something from akko.wtf using a GtS 0.16.0-rc1 instance has the Akkoma instance return Request not signed.

Just wanted to check: does Akkoma (or rather the Pleroma library it depends on) handle the (created) pseudo-header? Or does it always assume the Date header will be present and fail if it's not?

This part of the spec would suggest that the latter behavior is correct when algorithm="rsa-sha256":

In order to generate the string that is signed with a key, the client
MUST use the values of each HTTP header field in the headers
Signature Parameter, in the order they appear in the headers
Signature Parameter. It is out of scope for this document to dictate
what header fields an application will want to enforce, but
implementers SHOULD at minimum include the (request-target) and
(created) header fields if algorithm does not start with rsa,
hmac, or ecdsa. Otherwise, (request-target) and date SHOULD
be included in the signature.

To include the HTTP request target in the signature calculation, use
the special (request-target) header field name. To include the
signature creation time, use the special (created) header field
name. To include the signature expiration time, use the special
(expires) header field name.

However in GtS's case it uses algorithm="hs2019", so omitting Date and including (created) should be OK.

One workaround we could do if necessary would be to include both (created) AND Date, but since they essentially convey the same information I'd rather avoid that if possible.

Could you give more info on what might be needed here?

Hiya, in GoToSocial v0.16.0-rc1 we've switched from using the `Date` header in outgoing HTTP signatures to using the `(created)` pseudo-header described here: https://datatracker.ietf.org/doc/html/draft-cavage-http-signatures-12#section-2.1.4 So the `Signature` header on outgoing GtS GET requests now looks something like this: ``` keyId="https://example.org/users/someone/main-key",algorithm="hs2019",created=1717961994,headers="(request-target) (created) host",signature="[LONG_STRING_OF_BASE64_STUFF]" ``` I tested this against Mastodon and the *keys and it seems to work just fine there, but I was recently told it might not be working correctly for Akkoma, and indeed trying to fetch something from akko.wtf using a GtS 0.16.0-rc1 instance has the Akkoma instance return `Request not signed`. Just wanted to check: does Akkoma (or rather the Pleroma library it depends on) handle the `(created)` pseudo-header? Or does it always assume the `Date` header will be present and fail if it's not? This part of the spec would suggest that the latter behavior is correct when `algorithm="rsa-sha256"`: > In order to generate the string that is signed with a key, the client > MUST use the values of each HTTP header field in the `headers` > Signature Parameter, in the order they appear in the `headers` > Signature Parameter. It is out of scope for this document to dictate > what header fields an application will want to enforce, but > implementers SHOULD at minimum include the `(request-target)` and > `(created)` header fields if `algorithm` does not start with `rsa`, > `hmac`, or `ecdsa`. Otherwise, `(request-target)` and `date` SHOULD > be included in the signature. > > To include the HTTP request target in the signature calculation, use > the special `(request-target)` header field name. To include the > signature creation time, use the special `(created)` header field > name. To include the signature expiration time, use the special > `(expires)` header field name. However in GtS's case it uses `algorithm="hs2019"`, so omitting `Date` and including `(created)` should be OK. One workaround we could do if necessary would be to include both `(created)` AND `Date`, but since they essentially convey the same information I'd rather avoid that if possible. Could you give more info on what might be needed here?

tsmethurst commented

2024-06-09 20:11:40 +00:00

Author

For a bit of context on this, this issue is why we're trying this different way of creating signatures, and this bit of code in Mastodon is what gracefully handles the hs2019 (created) case.

For a bit of context on this, [this issue](https://github.com/superseriousbusiness/gotosocial/issues/2857) is why we're trying this different way of creating signatures, and [this bit of code](https://github.com/mastodon/mastodon/blob/35b517c207a5a5b24d5ac67ed9ad98943dcc3d7f/app/controllers/concerns/signature_verification.rb#L187-L192) in Mastodon is what gracefully handles the `hs2019` `(created)` case.

floatingghost commented

2024-06-09 20:42:09 +00:00

Owner

seems to be the case that the upstream lib doesn't support it, and that's been known about for a while (apparently)

see: https://git.pleroma.social/pleroma/elixir-libraries/http_signatures/-/issues/2

so yeah seems like we'll need to poke around and see if we can fix it our side

seems to be the case that the upstream lib doesn't support it, and that's been known about for a while (apparently) see: https://git.pleroma.social/pleroma/elixir-libraries/http_signatures/-/issues/2 so yeah seems like we'll need to poke around and see if we can fix it our side

👍 1

tsmethurst commented

2024-06-10 16:34:00 +00:00

Author

Thanks!

I've opened an issue here to track GtS switching to (created): https://github.com/superseriousbusiness/gotosocial/issues/2991

As soon as this is fixed in at least Akkoma (but preferably Pleroma as well) I think we can switch back to (created) from Date.

Thanks! I've opened an issue here to track GtS switching to `(created)`: https://github.com/superseriousbusiness/gotosocial/issues/2991 As soon as this is fixed in at least Akkoma (but preferably Pleroma as well) I think we can switch back to `(created)` from Date.

norm commented

2024-06-12 04:14:52 +00:00

Contributor

worth noting there's a merge request for adding support for that: https://git.pleroma.social/pleroma/elixir-libraries/http_signatures/-/merge_requests/8

perhaps this could be added to the akkoma fork of the library until it's upstreamed?

EDIT: seems like this was added to the created-pseudoheader branch of the akkoma library fork

worth noting there's a merge request for adding support for that: https://git.pleroma.social/pleroma/elixir-libraries/http_signatures/-/merge_requests/8 perhaps this could be added to the akkoma fork of the library until it's upstreamed? EDIT: seems like this was added to the `created-pseudoheader` branch of the akkoma library fork

floatingghost commented

2024-06-12 15:20:05 +00:00

Owner

the created-pseudoheader branch was actually my experiment to do the same thing that doesn't quite work (hence the wip tag)

i'll look at this PR, maybe they've beaten me to the punch and saved me trauma trying to fix my own branch

the `created-pseudoheader` branch was actually my experiment to do the same thing that doesn't quite work (hence the wip tag) i'll look at this PR, maybe they've beaten me to the punch and saved me trauma trying to fix my own branch

floatingghost commented

2024-06-12 17:54:12 +00:00

Owner

I am running an updated version of the library/akkoma on https://ihatebeinga.live

you should be able to communicate with this instance using the new psudoheader now 🦐

I am running an updated version of the library/akkoma on https://ihatebeinga.live you should be able to communicate with this instance using the new psudoheader now 🦐

floatingghost commented

2024-06-17 21:53:26 +00:00

Owner

updated over at https://github.com/superseriousbusiness/gotosocial/issues/2991 - merged our update

reopen this if you don't find it works

updated over at https://github.com/superseriousbusiness/gotosocial/issues/2991 - merged our update reopen this if you don't find it works

floatingghost closed this issue

2024-06-17 21:53:26 +00:00

[question] Does Akkoma handle (created) pseudo-header in HTTP signatures #797

[question] Does Akkoma handle `(created)` pseudo-header in HTTP signatures #797