OpenVPN-TLS-Chiffrefehler: zuerst beide Gegenstellen vergleichen

Ein Fehler „keine gemeinsame Chiffre“ klingt nach einer Einstellung, die man ändern muss, und die Einstellung, die die meisten ändern, ist die falsche. OpenVPN führt getrennte Richtlinien für den Kontrollkanal, der den TLS-Handshake ausführt, und für den Datenkanal, der Pakete im Tunnel trägt, und der Fehler nennt den ersten, während die Leute den zweiten bearbeiten. Vergleicht man, was jede Gegenstelle zulässt, in der richtigen Reihenfolge, wird aus dem Raten zwei oder drei Entscheidungen: Version, dann Suite-Liste, dann Anmeldedaten.

Vertauscht man diese Reihenfolge, kann man eine Stunde damit verbringen, einen AES-Namen zu einer Liste hinzuzufügen, die nie gelesen wurde.

Zwei Chiffrelisten, und nur eine bricht den Handshake

Der Kontrollkanal handelt eine TLS-Sitzung aus, und seine Richtlinie wird mit tls-cipher für TLS 1.2 und tls-ciphersuites für TLS 1.3 geschrieben. Der Datenkanal wird getrennt mit data-ciphers konfiguriert, wo eine Abweichung eine Verbindung erzeugt, die aufgebaut wird und dann keinen Verkehr durchlässt. Beide erzeugen Fehler, die Chiffren erwähnen, deshalb werden sie verwechselt. Ein Handshake, der nie abgeschlossen wird, deutet auf den Kontrollkanal, während ein aufgebauter Tunnel, der Pakete verwirft, auf den Datenkanal deutet.

Lesen Sie die ganze Meldung statt der ersten Zeile. Eine Versionsabweichung, eine fehlende Suite, ein Signaturalgorithmus des Zertifikats, den die Gegenstelle ablehnt, und ein Fehlschlag der Hostnamenprüfung enden alle in einem TLS-Fehler, und nur einer davon betrifft Ihre Suite-Liste. Diese Kategorien auseinanderzuhalten ist der größere Teil der Diagnose.

Vergleichen Sie Versionen, bevor Sie Suiten vergleichen

Eine auf TLS 1.2 beschränkte Gegenstelle und eine Gegenstelle, die 1.3 verlangt, teilen keine Version, und keine Chiffre-Zeichenkette überbrückt das. Notieren Sie tls-version-min und tls-version-max auf beiden Seiten oder die Standardwerte der verwendeten Builds, denn die OpenSSL-Richtlinie einer Distribution kann die Untergrenze anheben, ohne dass eine OpenVPN-Option das sagt. Ist eine Seite ein Gerät oder ein Client eines Drittanbieters, ist ihr Fenster das, was ihre Firmware zulässt. Erst wenn sich die Fenster überlappen, bedeutet ein Suite-Vergleich etwas.

Diese Aufzeichnungen sollten auch die tatsächlichen Binärdateien nennen. Ein Kommandozeilen-openvpn auf Ihrem Laptop ist nicht unbedingt der Client, der ein importiertes Profil verarbeitet.

TLS-1.2- und TLS-1.3-Listen mischen sich nicht

Suite-Namen für TLS 1.2 sehen so aus wie ECDHE-RSA-AES256-GCM-SHA384 und gehören in tls-cipher, das eine OpenSSL-Chiffre-Zeichenkette annimmt. TLS-1.3-Suiten heißen wie TLS_AES_256_GCM_SHA384 und gehören in tls-ciphersuites; eine davon in die 1.2-Zeichenkette zu setzen konfiguriert nicht die 1.3-Liste, und der Parser kann den Text annehmen, ohne ihn je zu treffen. Ein Filter, der für eine Version korrekt ist, sagt nichts über die andere. Schreiben Sie auf, für welche Version welche Liste gedacht ist.

openvpn --show-tls gibt aus, was der lokale Build unterstützt, und das ist eine Bestandsaufnahme, kein Versprechen: die entfernte Gegenstelle erlaubt diese Suiten vielleicht nicht, und das aktive Profil aktiviert sie vielleicht nicht. Nutzen Sie es, um einen Build auszuschließen, der überhaupt keine Suite anbieten kann, und vergleichen Sie dann die konfigurierten Listen.

Belegen Sie die Aushandlung an einer frischen Verbindung

Ein erfolgreicher Handshake ist der einzige Beweis, der zählt, und er muss vom echten Client mit dem echten Profil kommen. Erhöhen Sie die Ausführlichkeit des Servers, verbinden Sie sich einmal und lesen Sie die ausgehandelte Protokollversion und Suite aus dem Protokoll, statt anzunehmen, der erste angebotene Wert habe gewonnen. Bestätigen Sie dann den Datenkanal getrennt mit Verkehr durch den Tunnel, denn ein funktionierender Handshake und ein versagender Datenkanal sind verschiedene Reparaturen. Wiederholen Sie das nach jeder Konfigurationsänderung, denn ein veraltetes Clientprofil ist eine häufige falsch-negative Ursache.

Gibt es keine freigegebene gemeinsame Konfiguration, ist die Antwort ein Upgrade oder ein Migrationsplan, keine abgeschwächte Richtlinie. tls-version-min zu senken, die Prüfung abzuschalten oder jede alte Suite zu aktivieren beseitigt die Ablehnung, ohne die Sicherheitsanforderung zu erfüllen, die sie erzeugt hat.

Notieren Sie die ausgehandelte Version, die Suite und die Datenchiffre im Änderungsticket. Die nächste Person, die auf einen TLS-Fehler stößt, beginnt bei dieser Aufzeichnung und nicht bei einer Chiffre-Zeichenkette aus einem Forumsbeitrag.