Nebula-Blockliste: verteile sie, der Leuchtturm wird es nicht tun

Die Durchsetzung einer Blockliste ist eine Eigenschaft des prüfenden Hosts, nicht des geprüften Zertifikats. Eine Maschine, die den Eintrag nie geladen hat, akzeptiert die Identität weiter, und nichts im Handshake warnt dich davor, dass zwei Peers uneins sind. Die billige Lösung und die teure Lösung für einen offengelegten Nachweis unterscheiden sich in Reichweite und Umkehrbarkeit, also entscheide bewusst. Die folgenden Abschnitte behandeln, was der Eintrag tut, wohin er geliefert werden muss, wann die Rotation die bessere Antwort ist und wie du beweist, dass eine der beiden gewirkt hat.

Was ein Blocklisteneintrag tatsächlich tut

Die PKI-Konfiguration listet Fingerabdrücke auf, die ein Host ablehnen muss, obwohl das Zertifikat gültig signiert und nicht abgelaufen ist. Die Durchsetzung erfolgt lokal gegen die Liste, die dieser Host beim Start des Dienstes geladen hat. Nichts am Eintrag reist im Zertifikat mit, daher kann ein Peer die Entscheidung nicht aus dem Nachweis ableiten, der ihm gezeigt wird. Deshalb spielt ein Leuchtturm hier keine Rolle: Leuchttürme helfen Peers, einander zu finden, und leiten Verkehr weiter, wo ein direkter Pfad scheitert. Sie sind eine Entdeckungs- und Weiterleitungsschicht, kein Verteilungskanal für Konfiguration.

Das Aktualisieren einer Maschine ändert die Entscheidungen dieser Maschine und lässt jeden anderen Peer genau so, wie er war. Ein Peer, der der signierenden Autorität vertraut und den Eintrag nie gesehen hat, hat keinen Grund, irgendetwas abzulehnen. Das Widerrufen zu testen, indem du den Leuchtturm beobachtest, beweist daher nichts, weil die Komponente, die du beobachtest, nie gebeten wurde, die Liste durchzusetzen.

Identifiziere das Zertifikat, nicht das Gerät

Verwende den Fingerabdruck des Nachweises, den du ablehnen willst, denn ein Hostname, eine Gerätebezeichnung oder eine aktuelle Adresse identifiziert heute eine Maschine und nächsten Monat etwas anderes. Keine dieser Zeichenketten steht in der Blockliste, und keine übersteht eine Neuinstallation. Drucke das Zertifikat, lies den Fingerabdruck und prüfe, dass er zu dem Nachweis gehört, der ausgemustert wird, und nicht zu seinem Ersatz. Beide Dateien zu lesen ist wichtig, wenn bereits ein Ersatz ausgestellt ist, da das alte und das neue Zertifikat einen Namen teilen und sich in jedem anderen Feld unterscheiden können.

Halte fest, welcher Fingerabdruck wann blockiert wurde, damit ein späteres Audit eine abgeschlossene Änderung von einer beabsichtigten trennt. Beachte auch, was der Eintrag nicht tut: Er macht die signierende Autorität nicht ungültig und verhindert nicht, dass ein künftiges Zertifikat dieser Autorität akzeptiert wird. Ein Host-Zertifikat zu blockieren und eine kompromittierte Autorität zu ersetzen sind verschiedene Vorgänge mit verschiedenen Folgen.

nebula-cert print -path /etc/nebula/host.crt
pki:
  blocklist:
    - "a1b2c3d4e5f6"

Verteile sie wie jede andere Konfiguration

Behandle die Liste als Konfiguration mit einem Auslieferungsmechanismus und nicht als Datei, die jemand bearbeitet, wenn er daran denkt. Schiebe die ganze Liste statt eines Deltas, damit ein Host, der ein früheres Update verpasst hat, konvergiert, statt Lücken anzusammeln. Die Nebula-PKI-Dokumentation empfiehlt genau das, und der Rat ist wert, wörtlich befolgt zu werden, statt ihn in einen manuellen Prozess umzuformulieren.

Bestätige, dass der laufende Dienst den Inhalt neu geladen hat, nicht nur, dass sich die Datei auf der Platte geändert hat. Verfolge, welche Maschinen die Änderung angewendet haben, und halte die offene Liste sichtbar, bis sie leer ist. Ein Laptop, der eine Woche zugeklappt war, ist ein Peer, der die Entscheidung nie gelernt hat, und er kann sich aus einem Netz wieder verbinden, das niemand erwartet hat. Notiere die Auslieferungsmethode neben dem Fingerabdruck, weil der nächste Widerruf sie wiederverwendet und beim ersten der Prozess debuggt wird.

Blockliste oder Rotation der Autorität

Ein Blocklisteneintrag ist eng: Eine Identität funktioniert nicht mehr, und alles andere läuft weiter. Die signierende Autorität zu rotieren ist breit: Jedes von ihr ausgestellte Zertifikat wird nicht mehr vertraut, und jeder Host braucht einen neuen Nachweis und einen neuen Vertrauensanker. Das erste ist ein gezielter Widerruf, das zweite eine Migration, also brauchen sie unterschiedliche Genehmigungen und unterschiedliche Wartungsfenster. Die Tabelle stellt beide nebeneinander nach Reichweite, Aufwand und Umkehrbarkeit.

Ein verlorener Laptop verlangt die Blockliste, weil der Wirkungsradius eine Identität ist und die Änderung umkehrbar ist, wenn du den falschen Fingerabdruck blockiert hast. Ein abgeflossener Autoritätsschlüssel verlangt die Rotation, weil die Blockliste bei Zertifikaten nicht helfen kann, die noch nicht ausgestellt sind. Zwischen diesen Extremen fragst du, ob der offengelegte Nachweis etwas anderes hätte signieren können, denn eine Autorität ist mehr als ein Host.

Schreib die Entscheidung vor einem Vorfall auf, weil die Wahl unter Druck standardmäßig zur breiten Option neigt. Welchen Weg du auch wählst, der verbleibende Arbeitspunkt ist derselbe: zu beweisen, dass die Durchsetzung auf den Hosts geschah, auf die es ankommt. Den Fingerabdruck und das Datum in diesem Moment zu notieren ist das, was den Beweis später möglich macht.

Prüfe die Ablehnung und den Rest

Verbinde dich von der blockierten Identität und bestätige den Fehlschlag, dann verbinde dich von einem autorisierten Peer und bestätige, dass er weiterhin erreicht, was er braucht. Eine Änderung, die alle bricht, ist kein erfolgreicher Widerruf. Tu beides aus frischen Sitzungen, weil zwischengespeicherter Zustand das Ergebnis verbergen kann.

Prüfe, ob eine bestehende Sitzung nach der Änderung endet, und notiere das Verhalten für deine Version und Konfiguration, statt anzunehmen, dass das Bearbeiten einer Datei irgendetwas beendet. Die Option disconnect_invalid deckt Clients ab, deren Zertifikate abgelaufen oder ungültig sind, also bestätige, wie sie in deinem Fall gilt, bevor du dich darauf verlässt. Wenn sofortige Beendigung eine Anforderung ist, teste das gezielt und notiere, was du beobachtet hast. Wiederhole den Test dann nach einem Neustart, weil ein Host, der die Liste nur bis zum nächsten Neustart durchsetzt, ein Auslieferungsproblem hat, das der erste Test verdeckt hat. Ein gesunder Leuchtturm sagt dir, dass die Entdeckung funktioniert, nicht dass irgendein Peer eine Richtlinie angewendet hat.