tls-auth gegen tls-crypt: Was jede Option in OpenVPN schützt

Beide Optionen verwenden eine gemeinsame Schlüsseldatei und beide machen Handshake-Verkehr schwerer fälschbar, weshalb sie als zwei Namen für dieselbe Funktion gelten. Das sind sie nicht. Die eine signiert Steuerungspakete, die andere verschlüsselt sie zusätzlich, und keine von beiden hat etwas mit der Verschlüsselung zu tun, die Ihre Nutzdaten schützt.

Dieser Unterschied zählt, wenn ein Profil keine Verbindung aufbaut, wenn eine Sicherheitsprüfung fragt, was der Schlüssel schützt, und wenn jemand annimmt, die zusätzliche Datei mache den Tunnel auf irgendeine unbestimmte Weise verschlüsselt.

Was der gemeinsame Schlüssel tatsächlich schützt

Der Schlüssel, den diese Optionen verwenden, gehört zum Steuerungskanal: dem Austausch, der Parameter aushandelt, Identitäten nachweist und die Datenschlüssel ableitet. Er ist ein vorab geteiltes Geheimnis, das beide Endpunkte besitzen müssen, bevor der Handshake weiterlaufen kann. Weil er vor den Identitätsprüfungen steht, beendet ein falscher Schlüssel das Gespräch früher, als es ein falsches Passwort täte. Diese Reihenfolge erklärt, warum das Fehlerbild so still ist.

tls-auth nutzt dieses Geheimnis, um einen HMAC über Steuerungspakete zu berechnen. Ein Paket ohne gültige Signatur wird verworfen, bevor es die teurere TLS-Verarbeitung erreicht, weshalb die Option oft als erster Filter und nicht als Ersatz für TLS beschrieben wird.

tls-crypt geht weiter, indem es den geschützten Steuerungsverkehr nicht nur authentifiziert, sondern auch verschlüsselt. Zertifikatsinhalte, ausgehandelte Verschlüsselungsnamen und weitere Handshake-Details sind im Netz nicht mehr sichtbar, und ein Beobachter ohne den Schlüssel kann nicht einmal sehen, welche TLS-Version versucht wird. Für ein Deployment, das fürchtet, seinen VPN-Fingerabdruck zu verraten, ist diese Eigenschaft der Hauptgrund, es zu wählen. Es bleibt ein Gruppengeheimnis, keine Berechtigung pro Benutzer.

Keiner der Mechanismen stellt Identitäten aus. Der gemeinsame Schlüssel ist ein Gruppengeheimnis, und jeder, der ihn besitzt, erfüllt diese Prüfschicht.

Worin sich die beiden Optionen unterscheiden

Der beobachtbare Unterschied ist, was ein Beobachter sieht. Mit tls-auth ist der Handshake sichtbar, aber ohne den Schlüssel nicht überprüfbar. Mit tls-crypt ist der Handshake für jeden undurchsichtig, der den Schlüssel nicht besitzt.

Auch die Konfiguration unterscheidet sich. tls-auth wird mit einem Richtungswert verwendet, sodass eine Seite die eine Hälfte des Schlüsselmaterials nutzt und die andere Seite die andere Hälfte. tls-crypt verwendet einen einzigen Schlüssel in beiden Richtungen, daher gehört die Richtungsanweisung nicht zu seinem Aufbau.

In modernen Versionen schließen sich die beiden Optionen gegenseitig aus. Ein Profil sollte eine von ihnen tragen, nicht beide, und Server und Client müssen sich auf dieselbe einigen, mit passendem Schlüsselmaterial. Eine alte Anweisung neben einer neuen zu behalten, ist ein häufiger Migrationsrest. Entfernen Sie die inaktive, damit der nächste Leser weiß, welche Schicht tatsächlich gilt.

Eine neuere Variante, tls-crypt-v2, bindet jeden Client an seinen eigenen eingewickelten Schlüssel, sodass das Widerrufen eines Clients nicht das Neuausstellen des Gruppenschlüssels erfordert. Es lohnt sich, davon zu wissen, aber es ist eine andere Option und kein Synonym für eine der beiden hier.

Warum eine Abweichung aussieht, als passiere nichts

Wenn das gemeinsame Material nicht übereinstimmt, verwirft die Gegenseite die Pakete, ohne dem Absender zu sagen, warum. Es gibt keinen Authentifizierungsfehler zu lesen, weil das Paket nie die Schicht erreichte, die einen erzeugen würde.

Der Client versucht es erneut, der Server sagt nichts, und das Symptom sieht nach einem Netzwerkproblem aus. Dann starten Leute den Dienst neu, tippen das Kontopasswort erneut ein oder entfernen die Schutzanweisung, um sie zu «testen», was das Deployment verändert, statt es zu diagnostizieren.

Lesen Sie im Serverprotokoll die erste Beschwerde auf Paketebene statt der letzten Wiederholungszeile. Bestätigen Sie, dass beide Seiten dieselbe Option mit identischem Schlüsselmaterial tragen und dass die Schlüsseldatei nicht nur auf einer Seite neu erzeugt wurde.

Die Anweisung zu entfernen ist keine sichere Reparatur. Sie deaktiviert eine Schutzschicht für jeden Client, und ein danach funktionierender Tunnel beweist nur, dass diese Schicht die Abweichung war.

Was weiterhin getrennt konfiguriert werden muss

Diese Optionen prüfen nicht, wer die Gegenseite ist. Zertifikatsprüfung, Vertrauensanker und der erwartete Servername bleiben getrennte Anforderungen, und keine davon wird optional, weil ein gemeinsamer Schlüssel vorhanden ist.

Sie wählen auch nicht die Datenverschlüsselung. Das ist eine getrennte Aushandlung, die von den Einstellungen des Datenkanals auf beiden Seiten gesteuert wird, und ein mit tls-crypt geschützter Tunnel kann trotzdem eine Verschlüsselung verwenden, die Sie nicht beabsichtigt haben.

Schließlich braucht der gemeinsame Schlüssel selbst Behandlung. Behandeln Sie ihn als Geheimnis, verteilen Sie ihn über einen genehmigten Kanal und ersetzen Sie ihn, wenn jemand, der ihn hatte, das Team verlässt. Weil er geteilt wird, ist seine Offenlegung die Offenlegung jedes Endpunkts, der ihn nutzt.