Skip to content

fix(geraeteabmeldung): ein Relay, der eine Abmeldung verschweigt (§12) - #14

Open
Henner4746 wants to merge 2 commits into
mainfrom
fix/geraeteliste-verschwiegen
Open

Henner4746 wants to merge 2 commits into
mainfrom
fix/geraeteliste-verschwiegen

Conversation

@Henner4746

Copy link
Copy Markdown
Owner

Worum es geht

Kontakte bekamen die signierte Geräteliste nur über den Relay. Ein Relay, der eine neue Fassung annimmt, aber weiter die alte ausliefert und das abgemeldete Gerät nicht trennt, hebelte die Geräteabmeldung aus. Kontakte verschlüsselten weiter ans abgemeldete Tablet, und es schrieb weiter als Besitzer. Dazu kamen drei Wege, auf denen es mit Hilfe des Relays mitlas, obwohl der Kontakt die neue Liste schon kannte:

  • Bündel unter fremder Kennung
  • Erstnachricht unter fremder Kennung
  • „Zielgerät unbekannt“ löscht die Sitzung

Spezifikation und Befund: docs/GERAETEABMELDUNG.md §12 (Entwurf im ersten Commit, Umsetzung im zweiten).

Was sich ändert

App (2.0.1)

  • Listenstempel le/lh/ke in jeder Nutzlast, die Liste als eigene Art 20. Nach jeder Änderung wird sie verteilt, auch einmal an das gerade abgemeldete Gerät.
  • Ankündigung: Nennt ein Stempel eine neuere Fassung, als die App kennt, gilt die bekannte Liste als veraltet. Dann geht nur etwas an Geräte, die die neue Fassung selbst gestempelt haben, und nur von ihnen wird etwas angenommen.
  • Heilen: Wer mit einem älteren ke schreibt, bekommt die Liste nachgeschickt.
  • Widerspruch: Zwei Fassungen derselben Epoche lösen einen warnenden Hinweis im Chat aus.
  • „Geräte verwalten“ warnt, wenn der Relay die eigene letzte Änderung nicht ausliefert.
  • Sitzungen gehören zum Geräteschlüssel:
    • Der signierte Prekey wird zusätzlich vom Geräteschlüssel signiert und beim Sitzungsaufbau gegen die Liste geprüft.
    • Jede PreKey-Nachricht trägt einen Sitzungsnachweis. Der Empfänger prüft ihn und nimmt eine fremde neue Sitzung zurück.
    • Eine falsche Signatur wird nie angenommen. Eine fehlende wird erst mit 2.0.2 Pflicht (geraeteNachweisPflicht).
  • „Zielgerät unbekannt“ lässt die Sitzung stehen, wenn das Gerät in der signierten Liste steht.

Relay

  • spk_geraete_sig wird bei /register gegen die Liste geprüft (sonst 403), in einer neuen Spalte gespeichert und je Gerät in /prekey ausgeliefert. Die Änderung ist rein additiv: alte Apps senden das Feld nicht, alte Relays ignorieren es.

Reihenfolge beim Ausliefern

Erst den Relay (neue Spalte, wird beim Start per ALTER angelegt), dann die App.

Belege

  • app/test/net/geraeteliste_verschwiegen_test.dart: 10 Fälle gegen eine Attrappe, die Fassungen verschweigt und Geräte verleugnet, mit echten Gegenstellen (eigener libsignal-Speicher und Geräteschlüssel je Gerät)
  • payload_listenstempel_test.dart, sitzungsdatensatz_test.dart, ein Oberflächentest der Warnung, 8 Fälle in test_relay.py
  • Mutationsproben: App 20/20, Relay 6/6
  • Gesamtlauf: App 1542 Tests, Relay 176, alle grün

Offen

  • zwei_geraete_test.dart liegt mit rund 168 von etwa 186 erlaubten Abrufen knapp unter der Herkunftsbremse des Test-Relays. Eine eigene Sitzung schafft dort gerade Luft; ihr Commit kommt auf diesen Zweig nach.

🤖 Generated with Claude Code

Henner4746 and others added 2 commits October 18, 2026 22:22
…dung verschweigt

Befund aus dem Security-Review vom 18.10.2026 plus drei Wege, auf denen das
abgemeldete Geraet mit Hilfe des Relays wieder mitliest (Buendel und
Erstnachricht unter fremder Kennung, Loeschen auf 'Zielgeraet unbekannt').
§5/§6 berichtigt: Stufe 2 hielt gegen Verschweigen nicht.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Kontakte bekamen die signierte Geraeteliste nur ueber den Relay. Nahm er
eine neue Fassung an und lieferte weiter die alte aus, verschluesselten sie
weiter an das abgemeldete Geraet, und es schrieb weiter als Besitzer. Dazu
drei Wege, auf denen es mit Hilfe des Relays mitlas, obwohl der Kontakt die
neue Liste kannte (Buendel und Erstnachricht unter fremder Kennung,
"Zielgeraet unbekannt" loescht die Sitzung). Umgesetzt nach
docs/GERAETEABMELDUNG.md §12:

App
- Listenstempel le/lh/ke in jeder Nutzlast, die Liste als eigene Art 20.
  Verteilen nach jeder Aenderung (auch einmal an das abgemeldete Geraet),
  Ankuendigung merken, veraltete Liste: nur an Geraete, die sie gestempelt
  haben, und nur von ihnen annehmen. Heilen ueber ke, Widerspruch zweier
  Fassungen derselben Epoche mit Hinweis im Chat.
- "Geraete verwalten" warnt, wenn der Relay die eigene letzte Aenderung
  nicht ausliefert.
- Signierter Prekey zusaetzlich vom Geraeteschluessel signiert und beim
  Sitzungsaufbau gegen die Liste geprueft; Sitzungsnachweis in jeder
  PreKey-Nachricht (Basisschluessel aus dem Sitzungsdatensatz gelesen),
  beim Empfang geprueft, eine fremde neue Sitzung wird zurueckgenommen.
  Falsche Signaturen nie, fehlende bis zur Pflicht in 2.0.2.
- "Zielgeraet unbekannt" laesst die Sitzung stehen, wenn das Geraet in der
  signierten Liste steht.

Relay
- spk_geraete_sig bei /register gegen die Liste geprueft (403), in einer
  neuen Spalte gespeichert, je Geraet in /prekey ausgeliefert.

Nachladen nach einem Stempel hat eine eigene Bremse: mit der von Stufe 2
geteilt, verbrauchte der erste Stempel einer Kontaktanfrage die Minute, und
ein Geraet, das darin zuruecksetzte, kam nicht mehr durch
(sicherung_test.dart im Gesamtlauf). Abrufe, die nichts Neues bringen,
entfallen (Fremde, Art 20, faellige Geraetepruefung, Pruefung nach dem
Veroeffentlichen, wenn schon verglichen); zwei_geraete_test.dart lief sonst
in die Herkunftsbremse des Test-Relays.

Belege: geraeteliste_verschwiegen_test.dart (10 Faelle gegen eine
verschweigende Attrappe), payload_listenstempel_test.dart,
sitzungsdatensatz_test.dart, Oberflaechentest der Warnung, 8 Faelle in
test_relay.py. Mutationsproben: App 20/20, Relay 6/6. Gesamtlauf: App
1542, Relay 176 gruen.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@sonarqubecloud

Copy link
Copy Markdown

Quality Gate Failed Quality Gate failed

Failed conditions
0.0% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube Cloud

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant