Ulovlig TLS-versjon i AnyConnect på Linux: avgrens først omfanget av rettelsen

Denne feilen dukker opp før passordforespørselen, og det er den nyttige delen: ingenting er autentisert ennå, så påloggingsinformasjonen er ikke problemet. På Linux kan den samme AnyConnect-dialogen stamme fra en gammel protokollversjon, en 1024-bits nøkkelutvekslingsgruppe eller en chifferpakke som systemets kryptopolitikk avviser. Jeg har fjernet den på tre forskjellige måter på tre maskiner, og det som skiller disse rettelsene er hvor stort inngrepet er, ikke hvor smart det er. Hver av dem er forsvarlig på riktig sted og et dårlig standardvalg alle andre steder.

Les meldingen før du begynner å endre politikken

Ta vare på den nøyaktige teksten fra dialogen. En versjonsfeil peker på protokollaget, en sertifikatfeil peker på tillit eller navn, og en mislykket pålogging peker på påloggingsinformasjonen. En gateway som tilbyr TLS 1.0 med en 1024-bits DHE-gruppe, AES-256-CBC og en SHA-1-signatur kan ha et helt gyldig sertifikat og likevel bli avvist av en moderne politikk før opplysningene dine i det hele tatt sendes.

Undersøk endepunktet med systemets OpenSSL, med det virkelige vertsnavnet og den porten klienten bruker.

Når openssl s_client -connect vpn.example.com:443 -servername vpn.example.com mislykkes mens -tls1 -cipher DEFAULT@SECLEVEL=0 lykkes, betyr det at grensen er versjon og nøkkelstørrelse samlet. Rapporterer den første kommandoen en liten DH-nøkkel i stedet for en protokolladvarsel, er versjonen grei og bare gruppen trenger oppmerksomhet. Legg aldri en privat nøkkel eller et passord inn i undersøkelsen.

Alternativ 1: gjør hele verten ettergivende med kryptopolitikken

På Fedora og RHEL 8 og 9 senker update-crypto-policies --set LEGACY systempolitikken til OpenSSL, og update-crypto-policies --show bekrefter hva som er aktivt. Det gjenoppretter vanligvis tunnelen, men politikken leses når en prosess starter, så start klienten og alle hjelpeprosesser den har startet på nytt før du tester igjen. Den tillater også eldre protokoller og svakere grupper for hver TLS-klient på maskinen, fra nettleseren i nabovinduet til pakkebehandleren som oppdaterer kjernen.

Denne bredden er hele hensikten og hele problemet. LEGACY gjelder hele verten, varer ved og er lett å glemme, så det bør være et diagnostisk trinn eller et dokumentert unntak på en administrert installasjon, aldri hviletilstanden til en arbeidsstasjon. Jeg har sett en som ble stående på LEGACY i to år fordi én enkelt intern portal trengte det, og ingen kunne si når det startet.

Debian og Ubuntu har ingen enkel bryter for dette. Tilsvaret er en endring i /etc/ssl/openssl.cnf som setter en lavere MinProtocol og CipherString = DEFAULT@SECLEVEL=0 i avsnittet for systemstandarder. Samme omfang, annen fil, litt lettere å miste oversikten over under en versjonsoppgradering.

Alternativ 2: én konfigurasjonsfil for én klient

En OpenSSL-konfigurasjon per prosess holder endringen innenfor ett prosesstre, men bare hvis filen er koblet sammen slik biblioteket forventer. Det er ikke nok å navngi en ssl_conf-seksjon: OpenSSL leser nøkkelen openssl_conf på øverste nivå, følger den til en init-seksjon og når først da SSL-standardverdiene.

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

Pek OPENSSL_CONF mot den filen og start VPN-klienten gjennom en wrapper som eksporterer den. Alt annet på verten beholder standardpolitikken, og det er egenskapen som betyr noe når samsvarsspørsmålet kommer. Bekreft at filen faktisk er i kraft før du klandrer gatewayen: OPENSSL_CONF=/path/to/file openssl ciphers -s -tls1 skal liste opp TLS 1.0-chiffere, og et tomt resultat betyr at kjeden er brutt og at klienten i stillhet har beholdt systemstandardverdiene.

Filen er følsom for versjoner. OpenSSL 1.1.1 og 3.x godtar de samme seksjonsnavnene, men behandlingen av direktiver rundt leverandører endret seg i 3.x, så verifiser med klientens egen logg og et testhåndtrykk i stedet for å anta at filen ble lest. En skrivefeil i seksjonsnavnet feiler åpent, og klienten bruker i stillhet systemstandardverdiene.

Begrensningen er dekning. Alt som er lenket mot GnuTLS eller NSS, ignorerer OPENSSL_CONF, og det samme gjør enhver hjelpeprosess klienten starter uten å arve miljøet. Sjekk med ldd hvilket TLS-bibliotek binærfila faktisk er lenket mot før du bygger wrapperen, fordi svaret avgjør om dette alternativet i det hele tatt finnes.

Alternativ 3: en engangs-VM eller container

For en innleid konsulent som i fjorten dager treffer én gammel gateway, er en egen VM med den ettergivende politikken en renere grense enn arbeidsstasjonen. Den gamle flaten og den daglige nettleserprofilen slutter å dele en kjernepolitikk, og avhending er en sletting, ikke et revisjonsfunn.

Den er fortsatt en maskin på nettverket, så begrens tilgangen og hold den unna vanlig surfing. Vedlikeholdskostnaden er ett bilde til som må lappes, noe som er reelt men avgrenset og synlig, i motsetning til et glemt LEGACY-flagg på en bærbar PC.

Hva sammenligningen etterlater deg med

Velg ut fra tre spørsmål: hvem trenger den gamle protokollen, hvor lenge, og hvem vil merke det hvis unntaket overlever grunnen sin. Én app, én person, noen få dager peker mot konfigurasjonen per prosess. En hel flåte bak én enhet peker mot selve gatewayen. Alt som krever en permanent LEGACY-vertspolitikk, er en innkjøpsbeslutning i teknisk kostyme.

Den varige rettelsen hører hjemme på enheten: TLS 1.2 eller nyere, en gruppe på minst 2048 bit, en AEAD-chiffer og et sertifikat med moderne signatur. Be eieren av enheten om den endringen, og bekreft deretter den forhandlede versjonen og chifferen i klientens logg. Skriv ned unntaket med verten, gatewayen, den forhandlede protokollen, godkjenneren og en utløpsdato, fordi notatet er det som hindrer en midlertidig løsning i å bli standarden.