source: Klonkt/src/services/ActivityPubService.js@ f85b2c3

main
Last change on this file since f85b2c3 was f85b2c3, checked in by Robin <roboburr@…>, 5 weeks ago

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

  • Property mode set to 100644
File size: 266.8 KB

HTML preview not available, since the file size exceeds 256.0 KB.Try downloading the file instead.

Note: See TracBrowser for help on using the repository browser.