Re: Show: blog about http signatures

út 8. 10. 2024 v 21:21 odesílatel Evan Prodromou <evan@prodromou.name>
napsal:

> With TLS, you can use client certificates as well as server
> certificates. So, when making a connection to a remote server,  a local
> server can use its client certificate to authenticate itself. The remote
> server will know that the request comes from `social.example` and can
> authorize the request accordingly.
>
> This saves a few extra HTTP requests and makes key caching headaches go
> away. It can also authenticate at the connection level, rather than per
> request, which should speed things up.
>
> However, it's harder to authenticate requests for a particular actor.
> So, for a GET request for a `Note` object addressed to
> `actor1@social.example`, there's not an easy way to specify that the
> request is on behalf of `actor2@social.example` and should be refused.
>
> I think there are ways to do it, including using the rarely-used `From`
> header, but the structure has to be defined.  Another option is making a
> new client certificate per actor, but that requires a lot more
> certificate-signing infrastructure and using different connections per
> actor.
>

From header is email address only, so would not be a fit, here


>
> Evan
>
> On 2024-10-08 1:43 p.m., perillamint wrote:
> > Hello, Marcus.
> >
> > Think about the following scenario:
> >
> > There are two ActivityPub server implementations, A (and actor a), B
> > (and actor b), and malicious attacker M.
> >
> > M sends an Activity to server B's inbox with an object that claims it
> > originated from server A's actor a, and its to or cc does not include
> > "https://www.w3.org/ns/activitystreams#Public".
> >
> > Without the HTTP signature, since the object is not public, there is
> > no way to validate it by requesting the original object from server A.
> > Server A  can't validate the requester's identity, so it cannot give
> > the original object. TLS can't help here because there is no way to
> > distinguish M and B apart. (Let's not talk about TLS client cert. It
> > is hard on ActivityPub and will not work well when the server
> > administrator cannot control TLS termination such as CDN)
> >
> > The HTTP signature or JSON-LD signature solves this problem. Server B
> > asks for Actor a's public key to server A and validates the HTTP
> > request or object against the retrieved key. M cannot spoof the
> > signature without tampering with server B, so this effectively
> > prevents M from masquerading as an Actor on server A.
> >
> > If there is any alternative idea, please let us know. Unfortunately,
> > your blog article does not describe alternative methods to solve this
> > problem except "TLS", so I don't have any idea about how you are going
> > to improve this signature madness.
> >
> >
> > On 08/10/2024 16:20, Marcus Rohrmoser wrote:
> >>
> >> Dear fellow swicglers,
> >>
> >> recently I came across http signatures again and wrote down what I
> >> found this time.
> >>
> >> In the meantime, Johannes pointed me to a w3c report on the topic,
> >> which confirmed my suspicion that it serves no usecase and is
> >> possibly a cargo cult.
> >>
> >> I'm eager to hear your take on it.
> >>
> >> https://blog.mro.name/2024/10/http-signing/
> >>
> >> Your,
> >> Marcus
> >>
> >
> >
>
>