Remote: mutual authentication and hybrid TLS transport (opt-in)

Open
  • Is something wrong?
#211 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
8/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Active
Tech stack
rust
Domain
authentication, networking, security

Research direction

The issue names no source files, tests or entry points, so there is no code to start from. It requires a documented current state, an ADR and approval before any change, and it depends on DK-09 and #103, which are not yet resolved. Done would be an approved plan, then one reviewed PR with the listed TLS tests passing; a newcomer should not start implementation here.

Written by the indexing model from the issue text.

Description

area:api-ipc priority:P3 type:feature

Ziel und Umfang

Implementiere nur hinter deaktiviertem Feature-Flag einen TLS-1.3-Transport mit geprüfter Client-/Server-Identität, Zertifikats-/Key-Pinning oder PKI, Widerruf und fail-closed; frische ephemere Handshakes, kein 0-RTT, Resumption zunächst aus; TLS-KeyUpdate und erzwungene Neuverbindung nach überprüfter Policy. Keine eigene KEM-/TLS-Protokollkonstruktion; OpenSSL-3.5+-Integration nur nach ADR.

Priorität und Abhängigkeiten

  • Priorität: P1
  • Vorbedingungen: DK-09; zusätzlich #103 für Identitätsverwaltung (DK-Referenzen sind Titel dieser Reihe; nach Erstellung durch konkrete Issue-Links auflösbar)
  • Phase: B – späterer optionaler Netzwerkbetrieb

Sicherheitsregeln

  • Vor Umsetzung Ist-Zustand, betroffene Dateien, Architektur und Risiken dokumentieren; Freigabe einholen.
  • Ein kleiner, eigenständig reviewbarer PR; keine ungeplanten Refactorings.
  • Kein offener Netzwerkport, keine automatische Remote-Freigabe, kein stiller unsicherer Fallback.
  • Keine privaten Schlüssel, Passphrasen oder Tokens in Images, Logs, CLI-Argumenten oder Build-Layern.
  • Windows-/Debian-/ARM64-Pakete, bestehende CLI/API, Schlüsselcontainer und .pqkf v1/v2 bleiben kompatibel.

Tests und Akzeptanzkriterien

MITM, falsche Identität, abgelaufene/widerrufene Zertifikate, Downgrade, Replay, KeyUpdate, Reconnect, Schlüssellebensdauer, Abbruch und Last getestet; Port bleibt standardmäßig geschlossen; kein unsicherer Fallback.

  • Positiv-, Negativ-, Manipulations-, Fehler-/Abbruch- und Regressionstests passend zum Scope dokumentiert und grün.
  • CI: fmt, clippy, tests, Security-/Dependency-Checks; Zielplattformen soweit einschlägig.
  • Dokumentation und Bedrohungsmodell auf Deutsch und Englisch aktualisiert.

Definition of Done

  • Architektur-/Implementierungsplan vor Änderung freigegeben.
  • Genau ein unabhängiger PR mit Review und grüner CI.
  • Bestehende Daten und Installationswege nachweislich nutzbar.
  • Rollback getestet; Release-Notes und Einschränkungen dokumentiert.

Rollback

Feature deaktivieren, Remote-Listener schließen, lokaler Betrieb bleibt nutzbar.

Reihe: DK-10 von 12. Verwandt: #95, #104; Docker ist ergänzend zu bestehenden Core-/Daemon-Issues, kein Ersatz.

Dominant language
Rust
Stars
0
Forks
0
Avg merge
1h 22m
Merged PRs (30d)
72

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from SpecterAoD/pqkeep

All issues in SpecterAoD/pqkeep

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.