Re: Show: blog about http signatures

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.

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
>>
>
>

Received on Tuesday, 8 October 2024 19:20:51 UTC