Ein alter Peer erzwingt TLS 1.0: die Ausnahme begrenzen, nicht den Host

Ein altes Gerät taucht auf, kann sich nicht verbinden, und die am schnellsten aussehende Reparatur ist, den ganzen Host zu schwächen, bis die Verbindung gelingt. Dieser Tausch ist im Moment unsichtbar und in der Praxis dauerhaft, weil niemand eine Untergrenze entfernt, die endlich funktioniert. Zwei sehr verschiedene Fehler erzeugen den Druck, und nur einer davon hat überhaupt mit Chiffren zu tun. Sortieren Sie zuerst den Fehler, und legen Sie die Ausnahme dann dorthin, wo sie sich nicht ausbreiten kann.

Teilen Sie den Fehler in zwei, bevor Sie eine Direktive bearbeiten

Eine Serverlogzeile über keine gemeinsame Chiffre oder über eine nicht unterstützte Protokollversion stammt vom Steuerkanal: Die beiden Enden konnten sich nicht darauf einigen, wie die Aushandlung selbst geschützt werden soll. Eine Clientzeile, dass keine Methode zur Prüfung des Serverzertifikats aktiviert ist, stammt von ganz woanders, weil dieser Client gar nicht prüft, wer geantwortet hat. Eine Datenchiffre zu ändern bewirkt im zweiten Fall nichts, und eine Rollenprüfung hinzuzufügen bewirkt im ersten nichts.

Nehmen Sie die früheste fehlschlagende Zeile von jeder Seite statt der letzten Zeile vor der Trennung, denn die letzte ist meist eine Folge. Stellen Sie dann fest, welche Datei der Client tatsächlich geöffnet hat: Ein importiertes Profil existiert oft zweimal unter verschiedenen Anzeigenamen, und die Kopie zu bearbeiten, die niemand liest, erzeugt eine überzeugende Nicht-Änderung. Ein laufender Prozess behält die Einstellungen, mit denen er gestartet ist, eine gespeicherte Datei ist also keine geladene Datei. Die Befehle unten zeigen die Aushandlung des Clients neben der Sicht des Servers auf denselben Versuch.

openvpn --config <profile>.ovpn --verb 4 2>&1 | head -n 40
journalctl -u [email protected] --since '-10 min' | grep -iE 'cipher|tls|verify'

Ein zweiter Listener ist der ehrliche Ort für eine schwächere Untergrenze

Wenn das Gerät bei TLS 1.0 mit einem Datenkanal vor 2.5 endet, muss der Server eine niedrigere Untergrenze für den Steuerkanal und eine Datenchiffre anbieten, die der alte Client kennt. Die Fallback-Direktive existiert genau für diesen Peer, während die Chiffreliste moderne Clients auf modernen Suiten hält. Beide Direktiven gehören zum Listener und nicht zu einem Benutzer oder einer Verbindung, und keine Option pro Client verengt sie danach. Deshalb ist ein Altgerät am Hauptport eine Entscheidung über jeden Peer, der ihn teilt.

Wo die Plattform es zulässt, betreiben Sie den alten Listener als eigene Instanz auf einem separaten Port, erlauben Sie diesen Port nur von der Adresse des Geräts, und lassen Sie den Hauptdienst in Ruhe. Schreiben Sie auf, warum der zweite Listener existiert, und zwar in der Datei, die seine Konfiguration trägt, weil eine spätere Aufräumaktion ihn sonst als Überbleibsel liest. Die Trennung lohnt sich nur, wenn die schwächere Untergrenze dort endet, wo das Gerät endet.

tls-version-min 1.0
data-ciphers AES-128-GCM:AES-256-GCM:AES-256-CBC
data-ciphers-fallback AES-256-CBC

Was ein altes Anbieterzertifikat tatsächlich kaputt macht

Der Prüffehler ist eine fehlende Rollenbindung: Ohne sie akzeptiert der Client jedes Zertifikat, das zu einer vertrauenswürdigen CA führt, unabhängig davon, ob es für einen Server ausgestellt wurde. Binden Sie das Zertifikat zuerst an die Serverrolle, und behandeln Sie die Bindung als Anforderung statt als Stellschraube. Nur ein Profil, das danach immer noch scheitert, hat ein echtes Zertifikatsproblem.

Ein altes Anbieterzertifikat, dessen Schlüsselgröße oder Signaturalgorithmus die Standardrichtlinie von OpenSSL nicht mehr erfüllt, ist der Fall für eine begrenzte Änderung der Sicherheitsstufe auf dem Steuerkanal. Die Stufe dort zu senken schaltet die Prüfung nicht ab, und sie darf niemals mit einer leeren CA, einer deaktivierten Prüfeinstellung oder einem ungeprüften Hostnamen kombiniert werden. Halten Sie die Zeile in dem einen Profil, das sie braucht; eine gelockerte OpenSSL-Konfiguration global zu exportieren würde dieselbe Lockerung jedem Programm auf der Maschine geben.

remote-cert-tls server
tls-cipher "DEFAULT:@SECLEVEL=0"

Lesen Sie die ausgehandelten Werte, nicht das Banner

Bei Ausführlichkeit 4 geben beide Seiten die TLS-Version und Chiffre des Steuerkanals aus, auf die sie sich geeinigt haben, sowie die Datenchiffre der Sitzung. Lesen Sie diese Zeilen statt des Initialisierungsbanners, das Erfolg meldet und nicht dessen Bedingungen. Verbinden Sie dann einen modernen Client erneut mit dem Hauptlistener und bestätigen Sie, dass er weiterhin auf einer modernen Suite landet, denn eine Ausnahme, die in die gemeinsame Konfiguration gelangt ist, zeigt sich hier zuerst. Die Werte, die Sie herauskopieren, werden zur Grundlinie für die nächste Überprüfung.

Testen Sie das alte Gerät allein: Es sollte sich verbinden, und es sollte die einzige Sitzung in den Protokollen sein, die die schwächeren Parameter zeigt. Wenn ein zweiter Peer ebenfalls die alte Suite aushandelt, ist die Ausnahme breiter als beabsichtigt und die Listener-Trennung ist nicht wirklich erfolgt. Halten Sie beide Beobachtungen fest statt nur die Schlussfolgerung.

Jede Ausnahme braucht einen Eigentümer und ein Datum

Eine Ausnahme ohne Entfernungsbedingung wird stillschweigend zum Standard, also notieren Sie Gerät, Eigentümer, Grund und das Datum, an dem sie verschwindet, neben der Konfiguration, die sie rechtfertigt. Ohne diese Zeile überlebt die schwächere Untergrenze die Hardware, die sie brauchte.

Den Client zu ersetzen oder den Anbieter um ein aktuelles Profil zu bitten, ist das anzustrebende Ergebnis; die Ausnahme ist eine Verzögerung und kein Entwurf. Wenn das Gerät ausgemustert wird, entfernen Sie Listener und Profil in derselben Änderung, damit keine Hälfte weiterläuft. Nichts davon macht die alten Parameter sicher, es verhindert nur, dass die Grenze eines Geräts zur Grundlinie aller wird.