Ulovlig TLS-version i AnyConnect på Linux: afgræns rettelsen først

Denne fejl kommer før adgangskodeprompten, og det er det nyttige: intet er autentificeret endnu, så legitimationsoplysningerne er ikke problemet. På Linux kan den samme AnyConnect-dialog komme fra en gammel protokolversion, en 1024-bit nøgleudvekslingsgruppe eller et ciphersuite, som systemets kryptopolitik afviser. Jeg har ryddet det på tre forskellige måder på tre maskiner, og det, der adskiller de rettelser, er radius, ikke snilde. Hver er forsvarlig det rigtige sted og et dårligt standardvalg alle andre steder.

Læs meddelelsen, før du rører politikken

Behold den præcise streng fra dialogen. En versionklage peger på protokolllaget, en certifikatklage peger på tillid eller navngivning, og et mislykket login peger på legitimationsoplysninger. En gateway, der tilbyder TLS 1.0 med en 1024-bit DHE-gruppe, AES-256-CBC og en SHA-1-signatur, kan have et fuldstændig gyldigt certifikat og alligevel blive afvist af en moderne politik, før dine oplysninger nogensinde sendes.

Undersøg endepunktet med systemets OpenSSL, med det rigtige værtsnavn og den port, klienten bruger.

At openssl s_client -connect vpn.example.com:443 -servername vpn.example.com fejler, mens -tls1 -cipher DEFAULT@SECLEVEL=0 lykkes, fortæller dig, at grænsen er version og nøglestørrelse sammen. Hvis den første kommando rapporterer en lille DH-nøgle i stedet for en protokoladvarsel, er versionen fin, og kun gruppen kræver opmærksomhed. Læg aldrig en privat nøgle eller en adgangskode i undersøgelsen.

Mulighed 1: slap hele værten med kryptopolitikken

På Fedora og RHEL 8 og 9 sænker update-crypto-policies --set LEGACY OpenSSLs systempolitik, og update-crypto-policies --show bekræfter, hvad der er aktivt. Det gendanner normalt tunnelen, men politikken læses, når en proces starter, så genstart klienten og enhver hjælper, den startede, før du tester igen. Den tillader også ældre protokoller og svagere grupper for hver TLS-klient på maskinen, fra browseren i nabovinduet til pakkehåndteringen, der opdaterer kernen.

Den bredde er hele pointen og hele problemet. LEGACY gælder hele værten, er vedvarende og let at glemme, så det bør være et diagnostisk skridt eller en dokumenteret undtagelse på et styret build, aldrig en arbejdsstations hviletilstand. Jeg har set en, der blev på LEGACY i to år, fordi en enkelt intern portal havde brug for det, og ingen kunne sige, hvornår det begyndte.

Debian og Ubuntu har ikke én kontakt til dette. Det tilsvarende er en ændring af /etc/ssl/openssl.cnf, der sætter en lavere MinProtocol og CipherString = DEFAULT@SECLEVEL=0 i sektionen for systemstandarder. Samme radius, anden fil, lidt lettere at miste overblikket over under en udgivelsesopgradering.

Mulighed 2: én konfigurationsfil til én klient

En OpenSSL-konfiguration pr. proces holder ændringen inde i et enkelt procestræ, men kun hvis filen er koblet, som biblioteket forventer. Det er ikke nok at navngive en ssl_conf-sektion: OpenSSL læser topniveau-nøglen openssl_conf, følger den til en init-sektion og når først derefter SSL-standarderne.

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

Peg OPENSSL_CONF mod den fil, og start VPN-klienten gennem en wrapper, der eksporterer den. Alt andet på værten beholder standardpolitikken, og det er den egenskab, der betyder noget, når compliance-spørgsmålet kommer. Bekræft, at filen faktisk er i kraft, før du bebrejder gatewayen: OPENSSL_CONF=/path/to/file openssl ciphers -s -tls1 bør vise TLS 1.0-ciphers, og et tomt resultat betyder, at kæden er brudt, og at klienten i stilhed har beholdt systemstandarderne.

Filen er versionsfølsom. OpenSSL 1.1.1 og 3.x accepterer de samme sektionsnavne, men håndteringen af direktiver omkring udbydere ændrede sig i 3.x, så verificér med klientens egen log og et testhåndtryk i stedet for at antage, at filen blev læst. En tastefejl i sektionsnavnet fejler åbent, og klienten bruger i stilhed systemstandarderne.

Begrænsningen er dækning. Alt, der er linket mod GnuTLS eller NSS, ignorerer OPENSSL_CONF, og det samme gør enhver hjælpeproces, som klienten starter uden at arve miljøet. Tjek med ldd, hvilket TLS-bibliotek binæren faktisk er linket mod, før du bygger wrapperen, for svaret afgør, om denne mulighed overhovedet findes.

Mulighed 3: en engangs-VM eller container

For en konsulent, der i fjorten dage rammer én gammel gateway, er en dedikeret VM med den slap politik en renere grænse end arbejdsstationen. Den gamle overflade og den daglige browserprofil holder op med at dele en kernepolitik, og bortskaffelse er en sletning frem for et revisionsfund.

Den er stadig en maskine på netværket, så begræns dens adgang og hold den væk fra almindelig browsing. Vedligeholdelsesomkostningen er endnu et image, der skal patches, hvilket er reelt, men afgrænset og synligt, i modsætning til et glemt LEGACY-flag på en bærbar computer.

Hvad sammenligningen efterlader dig med

Vælg ud fra tre spørgsmål: hvem har brug for den gamle protokol, hvor længe, og hvem bemærker, hvis undtagelsen overlever sin begrundelse. Én app, én person, få dage peger på konfigurationen pr. proces. En hel flåde bag én enhed peger på selve gatewayen. Alt, der kræver en permanent LEGACY-værtspolitik, er en indkøbsbeslutning i teknisk kostume.

Den holdbare rettelse hører på enheden: TLS 1.2 eller nyere, en gruppe på mindst 2048 bit, et AEAD-cipher og et certifikat med en moderne signatur. Bed enhedens ejer om den ændring, og bekræft derefter den forhandlede version og cipher i klientens log. Skriv undtagelsen ned med værten, gatewayen, den forhandlede protokol, godkenderen og en udløbsdato, for noten er det, der forhindrer en midlertidig løsning i at blive standarden.