TLS-Gate v2: Passkanten als Prüffall — und Monitoring-Resonanz statt statischer Liste

Von: Branko → OZMAI
Stand: 28. September 2026
Typ: EXTERNAL_SOURCE (Inbox-Regel §3 — keine automatische Geltung, kein Brain-Status)
Charakter: STATUS + realer Prüffall für IDENTITAETSBINDUNG_HMAC_NETBOX_TLS_CUSTODY_PRUEFFALL_v0.1.md
+ DESIGN_INTENT (Monitoring → Postgres/Vektor). Kein Auftrag, kein Deploy.
Quelle: Repo TLS-Gate-Mock-Pipeline (git.crumbforest.org), Tags v2.0.0 (9849166) und
v2.1.0 (28f2211), dort CHANGELOG.md, docs/AUDIT.md (BWA-AUD-16…23), docs/STRUKTUR.md, deploy/.
Anschluss an: 2026-09-24_TLS-GATE-MANDANTEN-CORE-UND-LOGIN_BRANKO.md (letzter Stand dort: 911f1e5).

Legende: ✅ real/gebaut · 🧪 gebaut, getestet, nicht live · 🛠 spezifiziert · ⬜ OPEN · ❓ UNKNOWN

Zugangsdaten, Kunden-Domains, Reseller-IDs und Inhalte der vertraulichen Anbieter-Doku stehen bewusst
nicht hier.

Der Bogen in einem Satz

Seit dem 24.9. ist aus dem Mockup mit Login eine v2 geworden. Die Struktur schützt jetzt, nicht mehr
eine Deny-Liste, und neue Module kosten keinen Overhead pro Funktion. Dabei ist sichtbar geworden, dass
TLS-Gate schon heute an mehreren Passkanten genau die Trennung hält, die der whoami-Prüffall
verlangt: geprüftes Prädikat ≠ stärkere Bindung. Heute ist das alles aber statisch. Die nächste
Frage ist, was passiert, wenn Monitoring und Clients regelmäßig „funken“.

Was seit dem 24.9. real ist

Zwei Fehler, die unterwegs gefunden wurden. Beide sind für andere Repos im Wald lehrreich:

• .gitignore-Muster SSL/ traf auf macOS auch templates/ssl/ (core.ignorecase=true). 18 Dateien
  wurden still nicht committet, gefunden erst über git status und einen frischen Klon. Fix: Muster am Root
  verankern (/SSL/, /state/). Das ist derselbe Fehlertyp wie audit.php überschreibt Audit.php vom 26.9.:
  ein Name bindet stärker, als er soll.
• Flackernder Replay-Test seit v2.0.0: Der Test rechnete den „bereits benutzten“ TOTP-Code neu aus, statt
  ihn wiederzuverwenden. Über eine 30-s-Grenze war das ein frischer gültiger Code, und der Test wurde rot.
  Reproduziert per Start an Sekunde 22 des Fensters: alt 2/2 rot, neu 3/3 grün. Der Test prüfte also ein
  anderes Prädikat als das, das er zu prüfen behauptete.

Prüffall: TLS-Gate-Passkanten gegen IDENTITAETSBINDUNG … §16

Das ist Angriffsmaterial für die Hypothese, keine Bestätigung. Pro Passkante: welches Prädikat die
Evidenz tatsächlich trägt und welche stärkere Bindung daraus nicht folgt.

Zwei Stellen, an denen die Trennung heute nicht hält (Befund, kein Lob):

1. TOTP-Schlüssel liegt neben der DB (BWA-AUD-22, offen). Die sodium-Verschlüsselung trägt nur das
   Prädikat „ein DB-Dump allein gibt die Secrets nicht her“. Wer das Verzeichnis liest, hat beides. Das
   ist wörtlich F5 bzw. KEY_USE_CAPABILITY ≠ KEY_MATERIAL_ACCESS. Erst deploy/ mit getrenntem
   /etc/tlsgate/tlsgate.key löst das, und das ist noch nicht live.
2. SELinux ohne httpd_can_network_connect (RHEL-Familie): Der SOAP-Aufruf scheitert still, die App
   fällt auf den Mock zurück. Nur ein kleines Label „Mock-Fallback“ verhindert, dass man die Daten für
   Live-Daten hält. Das ist eine stille Aufwertung, die durch eine Umgebungsgrenze entsteht, nicht im Code.

Monitoring-Resonanz statt statischer Liste (DESIGN_INTENT)

Heute (statisch, ✅): Die Liste kommt auf Anfrage (Web/CLI) aus sslListExtended bzw. dem Mock. Es gibt
state/state.json + state/actions.log (Terminal-Aktionen) und audit_log (wer hat was ausgelöst).
Nichts meldet sich von selbst.

Produktion (Ist in anderen Wald-Teilen): Icinga, Checkmk und allgemein Monitoring funken regelmäßig.
Clients melden sich selbst („Resonanz“). Zielbild: Postgres mit Vektor (pgvector), irgendwann, im Rust-Core.

Unterscheidungen, die dafür tragen müssen, als Vorschlag:

• Ein Monitoring-Check ist eine neue Feststellung mit eigenem Anker: Checker, Check-Definition,
  Zeitpunkt, Ziel. Beispiel: „Checker C hat um t auf host:443 ein Cert gesehen, gültig bis X.“ Das trägt
  Freshness für diesen Moment, nicht mehr.
• Wiederholung ≠ Korroboration (PRUEFUNG_FESTSTELLUNG §7): 288 grüne Checks am Tag sind nicht 288-mal
  so viel Evidenz. Aussagekräftig sind die Zustandswechsel (grün → rot, anderes Cert, andere CA). Die
  Job-Queue/Cron aus ARCHITEKTUR M4 sollte deshalb Übergänge protokollieren, nicht Durchläufe zählen.
• Selbstmeldung ≠ Außenbeobachtung: Ein Client, der „mein Cert ist gültig“ funkt, liefert eine
  Behauptung aus der Innensicht. Der TLS-Gate-cross-check ist die Außensicht auf dieselbe Kante. Beide
  widersprechen sich nicht automatisch (Relais-Test, PRUEFUNG_FESTSTELLUNG §8). Nur mit benannter
  gemeinsamer Grundlage lässt sich daraus ein Widerspruch oder eine Korroboration machen.
• Resonanz ≠ Geltung (eigene Messung im 768-Raum, RESONANZ_UNGLEICH_GELTUNG_v0.1.md): Wenn
  Monitoring-Ereignisse als Vektoren landen, ist „ähnliches Ereignis gefunden“ ein Candidate, keine
  zulässige Grundlage für eine Entscheidung wie „verlängern“ oder „auslaufen lassen“.
• Vorschlag zur Datentrennung: Beobachtungen (Monitoring/Resonanz) in eine eigene Tabelle, nicht in
  audit_log. audit_log beantwortet „wer hat was ausgelöst“ (Berechtigung). Beobachtungen beantworten
  „was wurde wann von wem gesehen“ (Evidenz). Die Vektorspalte gehört zu den Beobachtungen und macht sie
  auffindbar, nicht wahrer. Die Nahtstelle zum Rust-Core bleibt die DB (jobs, cert_inventory,
  audit_log + Beobachtungen).

Offene Fragen an OZMAI (OPEN)

1. Reicht der bestehende VerificationAttempt (target, predicate, mechanism, policy, evidence_refs,
   assumption_refs, verifier, causal_anchor, resource_limit), um einen Monitoring-Check abzubilden, oder
   fehlt etwas für „periodisch, gleiche Definition, wechselndes Ergebnis“?
2. Ist „Zustandswechsel statt Zählung“ für Monitoring schon durch §7 (Wiederholung ≠ Bestätigung) gedeckt,
   oder ist das ein eigener Prüfvertrag?
3. Gehört die Client-Selbstmeldung in denselben Bestand wie die Außenbeobachtung (mit Herkunftsmarke), oder
   muss sie getrennt bleiben?
4. Wo liegt die Zulässigkeitsprüfung, wenn Vektor-Treffer über Monitoring-Ereignisse eine Entscheidung
   vorbereiten? Nach der Resonanz-Messung vermutlich an der Generierungs-/Passkante, nicht im Score.

Kurz: v2 steht, getaggt und getestet. Die Struktur trägt neue Module ohne Overhead. TLS-Gate hält an
mehreren Kanten schon „Prädikat ≠ stärkere Bindung“, an zwei Kanten nachweislich nicht. Und wenn aus
statisch „funkt regelmäßig“ wird, zählen Übergänge und nicht Wiederholungen, und Resonanz bleibt ein
Candidate.