https://datatracker.ietf.org/doc/rfc7239/
-
RFC 7239: Forwarded HTTP Extension
Forwarded HTTP Extension (RFC 7239, June 2014)
IETF Datatracker (datatracker.ietf.org)
Maybe useful for inbox forwarding when combined with HTTP Signatures? The parameters of the original HTTP Signature could be included in the POST for the forwarded activity...
-
POST /inbox HTTP/1.1
Host: mastodon.example
Signature: ...
Forwarded: Signature=""could this work? anyone interested in collaborating with me on a FEP for this? potential review/adoption by implementers? right now, inbox forwarding is pretty neglected as it depends on LD Signatures which are out-of-standard. @ me if you have any input!
-
@tedu actually, wouldn't the Host and (request-target) mismatch too?
-
@tedu i don't know why the destination would accept it, or on which grounds. typically the signature contains "(request-target) Host Date Digest" and all of those have to be faithfully reproduced or else the initial signature won't validate. the authoring server cannot know the request-target or host ahead-of-time, since that information is only known by the forwarding server.
-
@trwnh oh, I meant you can send me http requests with Host: mastodon.social and I'll probably process them, because it doesn't really matter. But getting the client library to send requests like that is more complicated, and kinda moot. Anyway.
-
@tedu like, if you signed only the digest then would that be "enough"? these kinds of security decisions aren't really documented anywhere
-
@tedu we're basically saying that for POST requests, not only do you need to verify that the content was unmodified, but also you want the signature to only apply to the POST /inbox request made at a certain Date to a certain Host. this prevents replay.
-
@tedu i guess that's true for objects but not really for activities. if you signed only the digest for activities, then you could intercept and record a Create activity and replay it even after they send out a Delete. the next counterstep would be to include/require a timestamp within every activity, i guess. which... it's probably "enough" to include the timestamp anywhere, really? in the activity, in the http request, in the ld sig, whatever.
-
@trwnh yeah, so I think if we can get everyone to agree to relax sig checking to only date and digest, it would allow forwarding without the complication of ld sig. so, uh, good luck.
For something like Create, we could also use the published time in the activity, and if it looks old, reverify by fetching.
-
@tedu i think that wont work for private messages
the initial conceit was, we could still get rid of ld sigs and even keep replay prevention by forwarding the original signature using the Forwarded: header. this requires storing no additional info, just verifying the forwarded signature (and verifying the same-origin policy, which is the real underpinning here). this assumes we don't care to authenticate the forwarder... which we might care, for example to prevent spam forwards.
-
@tedu worst case scenario, we verify two http sigs, but in return we do away with ld sigs entirely.
-
@trwnh I always thought giving everything an ID and just forwarding the URL was the best solution...
-
@trwnh that's still fine? The fetch the receiver does will be authenticated
-
@erincandescent what if it’s private
-
-
@trwnh isn't this a problem we have with fetching posts today?