Changeset f85b2c3 in Klonkt for deploy

Timestamp:

08/07/2026 05:00:09 PM (5 weeks ago)

Author:

Robin <roboburr@…>

Branches:

main

Children:

952baf3

Parents:

12bed59

Message:

Bind de sleutel aan de actor waarvoor hij spreekt

verifyRequest haalde het actor-document op bij de keyId uit de handtekening en gaf
dat document daarna terug zoals het binnenkwam. De inbox beslist op verified.id,
dus op wat het document over zichzelf beweert. Wie een document neerzet met de id
van zijn slachtoffer naast zijn eigen publieke sleutel, en ondertekent met zijn
eigen private helft, werd geloofd. De server van het slachtoffer wordt daarbij
nooit geraadpleegd en kan het dus ook niet tegenspreken.

De identiteit moet komen uit waar de sleutel is opgehaald, niet uit wat het
document over zichzelf zegt. Drie voorwaarden erbij: dezelfde herkomst als de
keyId, de keyId moet de sleutel zijn die de actor adverteert, en het sleutelblok
moet naar die actor zelf verwijzen.

Er gaat niets af en er is bewust geen uitzonderingslijst. Een "behalve bij een
bekende peer"-ontsnapping is precies de deur die dit dichtdoet. Het versmalt de
compatibiliteit ook niet: de regel erboven eiste al het ingebedde publicKey-object,
dus een array of een kale URI-verwijzing werkte hier nooit.

De Shaer-clients raakt dit niet. Die gaan via OAuth.verifyBearer; verifyRequest is
uitsluitend het server-naar-server-pad. Een client ondertekent nooit met een
HTTP-handtekening.

Changed files:
src/services/ActivityPubService.js

• drie bindingscontroles in verifyRequest, direct na het ophalen
• onparseerbare id of keyId valt naar null in plaats van door te glippen

New file:
test/ap-signature-keyid-binding.test.js

• de aanval zelf: een document dat de id van een andere host claimt
• en dat de echte server van het slachtoffer niet eens bevraagd wordt
• de sleutel van een buurman op dezelfde host
• een sleutelblok met een vreemde owner
• gewone federatie op de eigen host blijft werken
• een verdraaide handtekening blijft falen, dus de wiskunde is niet vervangen
• hosts zijn IP-literals uit de documentatiereeksen en fetch is gestubd, dus de test gaat nooit het netwerk op

remarks: nagemeten dat de test zonder de fix ook echt faalt (3 van 5 rood, en juist
de twee die moeten blijven werken bleven groen). Volledige suite 405 groen, in UTC
en in Europe/Amsterdam. Dit gat zit ook in stable (859b170, regel 1204), dus het
hoort daar als 1.6.1 heen; die backport is deze drie regels.

-robo
Co-Authored-By: Claude Opus 4.8 <noreply@…>

(No files)