server: redirected fetch does not work #288

New issue

Closed

opened 2022-12-14 22:49:13 +00:00 by Johann150 · 2 comments

Johann150 commented

2022-12-14 22:49:13 +00:00

Owner

Example:

you are on yourself.example, for some reason seeing a post on something.example that is actually from author.example. At least with Misskey & Co. you should be able to copy the something.example link (since it HTTP redirects the activitypub representation to author.example) to get your instance to fetch the post from author.example).

However there seems to be a problem with this as whenever I tried this it caused a different bug for every author.example replacement I tried. Here are some example log lines with errors:

apparent openSSL error (SSL alert 80)

request failed, reason: write EPROTO C0671B8FF07F0000:error:0A000438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error:../deps/openssl/openssl/ssl/record/rec_layer_s3.c:1600:SSL alert number 80

certificate expired (it had definitely not expired)

request failed, reason: certificate has expired

certificate DNS name mismatch (in this case mk.absturztau.be was used as something.example and chaos.social as author.example)

request failed, reason: Hostname/IP does not match certificate's altnames: Host: mk.absturztau.be. is not in the cert's altnames: DNS:assets.chaos.social

Example: you are on `yourself.example`, for some reason seeing a post on `something.example` that is actually from `author.example`. At least with Misskey & Co. you should be able to copy the `something.example` link (since it HTTP redirects the activitypub representation to `author.example`) to get your instance to fetch the post from `author.example`). --- However there seems to be a problem with this as whenever I tried this it caused a different bug for every `author.example` replacement I tried. Here are some example log lines with errors: - apparent openSSL error (SSL alert 80) ``` request failed, reason: write EPROTO C0671B8FF07F0000:error:0A000438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error:../deps/openssl/openssl/ssl/record/rec_layer_s3.c:1600:SSL alert number 80 ``` - certificate expired (it had definitely not expired) ``` request failed, reason: certificate has expired ``` - certificate DNS name mismatch (in this case `mk.absturztau.be` was used as `something.example` and `chaos.social` as `author.example`) ``` request failed, reason: Hostname/IP does not match certificate's altnames: Host: mk.absturztau.be. is not in the cert's altnames: DNS:assets.chaos.social ```

Johann150 added this to the (deleted) project 2022-12-14 22:53:47 +00:00

Johann150 referenced this issue from a commit

2022-12-20 21:07:27 +00:00

server: handle redirects in signed get

Johann150 commented

2022-12-20 21:16:02 +00:00

Author

Owner

The error invalid response that e.g. jeder was seeing will still occur with the above patch. The "problem" is that in the resolver we check that the thing we actually got has the id we asked for.

	`// Did we actually get the object that corresponds to the canonical URL?`
	`// Does the host we requested stuff from actually correspond to the host that owns the activity?`
	`\|\| !(getApId(object) == null \|\| getApId(object) === value)`

This check was previously done separately in the kernel in different places, see 3582fd8260. The check itself is necessary, otherwise people could change data that is "owned" by different hosts that they are not authorized to change.

Maybe that commit needs to be rolled back and the respective checks reinstated (e.g. ef53ec276a). Another solution would be to signal to the resolver that a redirect to a different URL or even host would be okay in the case of when it is used by ap/show (and default to such a redirect not being okay otherwise).

The error `invalid response` that e.g. jeder was seeing will still occur with the above patch. The "problem" is that in the resolver we check that the thing we actually got has the `id` we asked for. https://akkoma.dev/FoundKeyGang/FoundKey/src/commit/aa33708b909b99a4aefb83d66b65e2f43619ffb9/packages/backend/src/remote/activitypub/resolver.ts#L95-L97 This check was previously done separately in the kernel in different places, see 3582fd826017ee17196f68a1646100f385d3617c. The check itself is necessary, otherwise people could change data that is "owned" by different hosts that they are not authorized to change. Maybe that commit needs to be rolled back and the respective checks reinstated (e.g. ef53ec276a49c2722a2f0677e587d9b43af239c7). Another solution would be to signal to the resolver that a redirect to a different URL or even host would be okay in the case of when it is used by `ap/show` (and default to such a redirect not being okay otherwise).

Johann150 commented

2022-12-21 20:32:45 +00:00

Author

Owner

With the latest two commits, redirected fetch works for me.

Johann150 closed this issue

2022-12-21 20:32:45 +00:00

Johann150 added the

fix

label 2022-12-23 10:18:18 +00:00

Johann150 removed this from the (deleted) project 2022-12-23 10:18:20 +00:00