Self-Update: ed25519-Signaturpflicht entfernen, Vertrauen auf TLS (https-Zwang + Hash-Check) — #113 Phase 2 Rückbau #187
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Entscheidung / Begründung
#113 Phase 2 hat eine ed25519-Signatur fuer Self-Update eingefuehrt, mit dem Pubkey einkompiliert im Agent. Architektur-Entscheidung (Dev): Der Signing-Key wuerde ohnehin auf dem Backend liegen → die Signatur haengt dann am gleichen Vertrauensanker wie der Download (das Backend) und ist damit kryptografisch redundant zu
https:///TLS, das die Quelle bereits authentifiziert. Echten Mehrwert haette nur ein Offline-Key (bewusst verworfen: "Backend kompromittiert = eh vorbei").→ Signatur-Schicht entfernen, Vertrauen sauber auf TLS stuetzen. Self-Update ist dann wieder funktionsfaehig ohne Key-Management (aktuell fail-closed durch Pubkey-Platzhalter).
Wichtig — betrifft NICHT die Agent-Auth: Die Legitimitaet des Agents gegenueber dem Backend laeuft unveraendert ueber #185 (ed25519 Challenge-Response). Dieses Issue aendert nur die Update-Integritaet (Backend→Agent), nicht die Authentifizierung (Agent→Backend).
Umsetzung (
Node-Agent/src/self_update.rs)verify_update_signature+UPDATE_PUBKEY_B64-Const + base64/ed25519-Imports entfernen; den Aufruf bei :79 raus.https://-Zwang fuer den Binary-Download: die Download-URL ({cfg.http_base}/node-agent-binary/{arch}, :63) musshttps://sein (Ausnahme localhost, analog zum wss-Zwang #113 Phase 1). Beihttp://zu Nicht-localhost → Update ablehnen (fail-closed gegen Klartext-Download).http_basewird ausserver_urlabgeleitet — Validierung dort wiederverwenden/spiegeln.X-Binary-Hash-Header gegen lokalen sha256 vergleichen; Mismatch → ablehnen. (Das ist Integritaet, nicht Authentizitaet — die macht TLS.)ureqnutzt System-/webpki-CAs → Server-Zert wird beihttps://verifiziert; sicherstellen, dass kein "accept invalid cert" gesetzt ist.Backend (
server/main.py)X-Binary-Sig-Header +.sig-Datei-Logik (main.py:356) entfernen (wird nicht mehr gebraucht).X-Binary-Hash(sha256) beibehalten.scripts/sign-release.shentfernen oder als "nur fuer optionalen Offline-Signing-Pfad (#zukunft)" markieren.Doku
wiki/Deployment-Public.mdAbschnitt 6 (Self-Update-Signatur) +wiki/Self-Update-Signinganpassen: Self-Update vertraut TLS, kein Key noetig. Hinweis: Offline-Key-Signatur ist ein optionales spaeteres Upgrade, falls theProx je als Produkt an Dritte ausgeliefert wird (schuetzt dann auch gegen kompromittiertes Backend).Akzeptanz
https://(http:// zu Nicht-localhost = abgelehnt); Server-Zert verifiziert.Bezug
Baut #113 Phase 2 gezielt zurueck (Phase 1 wss-Zwang bleibt). Kein Konflikt mit #185/#115/#114.
Branch
refactor/self-update-tls-trust-no-signatureERWEITERUNG — VPN-Hosts: Opt-in statt hartem Zwang
Entscheidung: Der
https://-Zwang (und derwss://-Zwang aus #113 Phase 1) bleibt Default, ist aber pro Host abschaltbar fuer VPN-Hosts (Transport ist dort durch WireGuard/NetBird bereits verschluesselt+authentifiziert → Klartext-Link unkritisch).Statt Klartext-Default oder manuellem Config-Edit: UI-gesteuert (siehe neues Issue, das den UI/Backend-Teil traegt). Dieses Issue (#187) deckt den Agent-Teil:
TRUSTED_TRANSPORT=vpn(oderALLOW_INSECURE_TRANSPORT=1), viapick(...)in config.rs gelesen.validate_server_url(config.rs:36) erlaubtws:///(implizit) http NUR, wenn dieser Schalter gesetzt ist ODER Host=localhost. Sonst weiterhin harter Reject (Default).http://-Binary-Download nur erlaubt, wennTRUSTED_TRANSPORTgesetzt; sonst https-Zwang. sha256-Check bleibt immer (auch ueber VPN — Integritaet).Gilt fuer beide Strecken (WS-Verbindung #113 Phase 1 + Binary-Download #187) — EIN gemeinsamer Schalter.
UI/Backend/Install-Script-Teil + Modellfeld: siehe #189. #187 = Agent-Teil (config.rs/validate_server_url/self_update liest den Schalter).
Bearbeitet zusammen mit #189 (gemeinsamer TRUSTED_TRANSPORT-Vertrag). Issue bleibt offen.
Commits: Agent `
0416d9f` · Backend `198f8b5` · Doku `727f25f`Akzeptanz: Self-Update ohne Key funktionsfähig; sha256-Check aktiv (fehlend/Mismatch → verweigert); keine Signatur-/sig-Reste; #185-Auth unverändert.
⚠️ Deploy: Node-Agent lokal neu bauen + ausrollen (kein cargo im Container). Backend-Rebuild liefert die neuen Header. Hinweis: der Crate baut im CI-Container aktuell nicht durch (pre-existing `identity.rs` `send_json` aus #185 — separat, nicht von diesem Change).
Verifiziert @
727f25f(+ Build-Fix903ea4f) → erfüllt, wird geschlossen.trusted_transportoder localhost (self_update.rs:30) — sonst verweigert, gleicher Riegel wie die WS-Verbindung ✓TRUSTED_TRANSPORT=vpn-Schalter in config.rs (v.trim()=="vpn", :39-40),validate_server_url(url, trusted_transport): wss immer, ws nur localhost||VPN, sonst Fehler ✓Backend-Build-Fix (
903ea4f):identity.rs:87enroll() nutztureq::send_json, aberureqwar ohnejson-Feature gebaut (features=["tls"]) → Agent-Build gebrochen (latenter #185-Rest, nicht von diesem Batch). Behoben →features=["tls","json"].