Illegale TLS-Version bei AnyConnect unter Linux: zuerst den Umfang der Korrektur bestimmen

Hostweite LEGACY-Policy, OpenSSL-Konfiguration pro Prozess und eine Wegwerf-VM im Vergleich, dazu die Gateway-Änderung, die den Fehler dauerhaft beseitigt.

Dieser Fehler kommt vor der Passwortabfrage, und das ist der nützliche Teil: Es wurde noch nichts authentifiziert, also sind die Zugangsdaten nicht das Problem. Unter Linux kann derselbe AnyConnect-Dialog von einer alten Protokollversion, einer 1024-Bit-Schlüsselaustauschgruppe oder einer Ciphersuite kommen, die die Krypto-Policy des Systems ablehnt. Ich habe ihn auf drei Maschinen auf drei verschiedene Arten beseitigt, und was diese Lösungen unterscheidet, ist die Reichweite, nicht die Cleverness. Jede ist am richtigen Ort vertretbar und überall sonst eine schlechte Voreinstellung.

Lesen Sie die Meldung, bevor Sie die Policy anfassen

Halten Sie die genaue Zeichenkette aus dem Dialog fest. Eine Versionsbeschwerde deutet auf die Protokollschicht, eine Zertifikatsbeschwerde auf Vertrauen oder Namensgebung, und ein fehlgeschlagener Login auf die Zugangsdaten. Ein Gateway, das TLS 1.0 mit einer 1024-Bit-DHE-Gruppe, AES-256-CBC und einer SHA-1-Signatur anbietet, kann ein völlig gültiges Zertifikat haben und trotzdem von einer modernen Policy abgelehnt werden, bevor Ihre Zugangsdaten überhaupt gesendet werden.

Prüfen Sie den Endpunkt mit dem OpenSSL des Systems, mit dem echten Hostnamen und dem Port, den der Client verwendet.

Wenn openssl s_client -connect vpn.example.com:443 -servername vpn.example.com fehlschlägt, während -tls1 -cipher DEFAULT@SECLEVEL=0 gelingt, liegt die Grenze bei Version und Schlüsselgröße zusammen. Meldet der erste Befehl einen kleinen DH-Schlüssel statt einer Protokollwarnung, ist die Version in Ordnung und nur die Gruppe braucht Aufmerksamkeit. Legen Sie niemals einen privaten Schlüssel oder ein Passwort in die Prüfung.

Option 1: den ganzen Host über die Krypto-Policy lockern

Unter Fedora und RHEL 8 und 9 senkt update-crypto-policies --set LEGACY die System-Policy von OpenSSL, und update-crypto-policies --show bestätigt, was aktiv ist. Das stellt den Tunnel meist wieder her, aber die Policy wird beim Start eines Prozesses gelesen, also starten Sie den Client und jeden von ihm erzeugten Helfer neu, bevor Sie erneut testen. Sie erlaubt außerdem ältere Protokolle und schwächere Gruppen für jeden TLS-Client der Maschine, vom Browser im nächsten Fenster bis zum Paketmanager, der den Kernel aktualisiert.

Diese Breite ist der ganze Sinn und das ganze Problem. LEGACY gilt hostweit, bleibt bestehen und ist leicht zu vergessen, also sollte es ein Diagnoseschritt oder eine dokumentierte Ausnahme auf einem verwalteten Build sein, niemals der Ruhezustand einer Workstation. Ich habe eine gesehen, die zwei Jahre auf LEGACY blieb, weil ein einziges internes Portal sie brauchte, und niemand konnte sagen, wann es begann.

Debian und Ubuntu haben keinen einzelnen Schalter dafür. Das Äquivalent ist eine Änderung an /etc/ssl/openssl.cnf, die ein niedrigeres MinProtocol und CipherString = DEFAULT@SECLEVEL=0 im Abschnitt für Systemstandards setzt. Gleiche Reichweite, andere Datei, etwas leichter aus den Augen zu verlieren bei einem Release-Upgrade.

Option 2: eine Konfigurationsdatei für einen Client

Eine OpenSSL-Konfiguration pro Prozess hält die Änderung in einem einzigen Prozessbaum, aber nur, wenn die Datei so verdrahtet ist, wie die Bibliothek es erwartet. Einen ssl_conf-Abschnitt zu benennen reicht nicht: OpenSSL liest den Schlüssel openssl_conf auf oberster Ebene, folgt ihm zu einem Init-Abschnitt und erreicht erst dann die SSL-Standards.

openssl_conf = openssl_init

[openssl_init]
ssl_conf = ssl_sect

[ssl_sect]
system_default = system_default_sect

[system_default_sect]
MinProtocol = TLSv1.0
CipherString = DEFAULT@SECLEVEL=0

Richten Sie OPENSSL_CONF auf diese Datei und starten Sie den VPN-Client über einen Wrapper, der sie exportiert. Alles andere auf dem Host behält die Standard-Policy, und das ist die Eigenschaft, auf die es ankommt, wenn die Compliance-Frage kommt. Bestätigen Sie, dass die Datei wirklich wirkt, bevor Sie das Gateway beschuldigen: OPENSSL_CONF=/path/to/file openssl ciphers -s -tls1 sollte TLS-1.0-Cipher auflisten, und ein leeres Ergebnis bedeutet, dass die Kette gebrochen ist und der Client still die Systemstandards behalten hat.

Die Datei ist versionsempfindlich. OpenSSL 1.1.1 und 3.x akzeptieren dieselben Abschnittsnamen, aber die Behandlung von Direktiven rund um Provider hat sich in 3.x geändert, also prüfen Sie mit dem Log des Clients und einem Test-Handshake, statt anzunehmen, die Datei sei gelesen worden. Ein Tippfehler im Abschnittsnamen schlägt offen fehl, und der Client nutzt still die Systemstandards.

Die Grenze ist die Abdeckung. Alles, was gegen GnuTLS oder NSS gelinkt ist, ignoriert OPENSSL_CONF, ebenso jeder Helferprozess, den der Client ohne geerbtes Environment startet. Prüfen Sie mit ldd, gegen welche TLS-Bibliothek die Binärdatei tatsächlich gelinkt ist, bevor Sie den Wrapper bauen, denn die Antwort entscheidet, ob diese Option überhaupt existiert.

Option 3: eine Wegwerf-VM oder ein Container

Für einen Auftragnehmer, der zwei Wochen lang ein altes Gateway anspricht, ist eine dedizierte VM mit der gelockerten Policy eine sauberere Grenze als die Workstation. Die Altlast-Oberfläche und das alltägliche Browserprofil teilen sich keine Kernel-Policy mehr, und die Entsorgung ist ein Löschen statt ein Audit-Befund.

Sie ist weiterhin eine vernetzte Maschine, also beschränken Sie ihren Zugang und halten Sie sie vom allgemeinen Surfen fern. Die Wartungskosten sind ein weiteres Image, das gepatcht werden muss, was real, aber begrenzt und sichtbar ist, anders als ein vergessenes LEGACY-Flag auf einem Laptop.

Was der Vergleich Ihnen lässt

Entscheiden Sie anhand von drei Fragen: Wer braucht das alte Protokoll, wie lange, und wer merkt es, wenn die Ausnahme ihren Grund überlebt. Eine App, eine Person, ein paar Tage deuten auf die Konfiguration pro Prozess. Eine ganze Flotte hinter einem Gerät deutet auf das Gateway selbst. Alles, was eine dauerhafte LEGACY-Host-Policy braucht, ist eine Beschaffungsentscheidung in technischem Kostüm.

Die dauerhafte Lösung gehört auf das Gerät: TLS 1.2 oder neuer, eine Gruppe von mindestens 2048 Bit, eine AEAD-Chiffre und ein Zertifikat mit moderner Signatur. Bitten Sie den Eigentümer des Geräts um diese Änderung und bestätigen Sie dann die ausgehandelte Version und Chiffre im Log des Clients. Schreiben Sie die Ausnahme mit Host, Gateway, ausgehandeltem Protokoll, Genehmiger und Ablaufdatum auf, denn die Notiz ist es, die verhindert, dass eine vorübergehende Umgehung zur Voreinstellung wird.

Ähnliche Artikel