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

Denne feilen kommer før passordforespørselen, og det er den nyttige delen: ingenting er autentisert ennå, så legitimasjonen er ikke problemet. På Linux kan den samme AnyConnect-dialogen komme fra en gammel protokollversjon, en 1024-bits nøkkelutvekslingsgruppe eller en chifferpakke som systemets kryptopolitikk avviser. Jeg har ryddet den på tre forskjellige måter på tre maskiner, og det som skiller disse rettelsene er rekkevidden, ikke snarrådigheten. Hver er forsvarlig på rett sted og et dårlig standardvalg alle andre steder.

Les meldingen før du rører policyen

Ta vare på den nøyaktige strengen fra dialogen. En versjonsklage peker på protokollaget, en sertifikatklage peker på tillit eller navngiving, og en mislykket innlogging peker på legitimasjonen. En gateway som tilbyr TLS 1.0 med en 1024-bits DHE-gruppe, AES-256-CBC og en SHA-1-signatur kan ha et fullstendig gyldig sertifikat og likevel bli avvist av en moderne policy før legitimasjonen din i det hele tatt sendes.

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

At openssl s_client -connect vpn.example.com:443 -servername vpn.example.com feiler mens -tls1 -cipher DEFAULT@SECLEVEL=0 lykkes, forteller at grensen er versjon og nøkkelstørrelse sammen. Hvis den første kommandoen rapporterer 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 i undersøkelsen.

Alternativ 1: slakk hele verten med kryptopolitikken

På Fedora og RHEL 8 og 9 senker update-crypto-policies --set LEGACY systempolicyen til OpenSSL, og update-crypto-policies --show bekrefter hva som er aktivt. Det gjenoppretter vanligvis tunnelen, men policyen leses når en prosess starter, så start klienten og enhver hjelper den 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.

Den bredden er hele poenget og hele problemet. LEGACY gjelder hele verten, er vedvarende og lett å glemme, så det bør være et diagnostisk trinn eller et dokumentert unntak på et administrert bygg, aldri en arbeidsstasjons hviletilstand. 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 begynte.

Debian og Ubuntu har ingen enkelt bryter for dette. Ekvivalenten er en endring av /etc/ssl/openssl.cnf som setter en lavere MinProtocol og CipherString = DEFAULT@SECLEVEL=0 i seksjonen for systemstandarder. Samme rekkevidde, annen fil, litt lettere å miste oversikten over under en utgivelsesoppgradering.

Alternativ 2: én konfigurasjonsfil for én klient

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

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 standardpolicyen, og det er egenskapen som betyr noe når samsvars spørsmålet kommer. Bekreft at filen faktisk er i kraft før du klandrer gatewayen: OPENSSL_CONF=/path/to/file openssl ciphers -s -tls1 bør liste TLS 1.0-chiffere, og et tomt resultat betyr at kjeden er brutt og at klienten i stillhet har beholdt systemstandardene.

Filen er versjonsfølsom. 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 systemstandardene.

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æren faktisk er lenket mot før du bygger wrapperen, for svaret avgjør om dette alternativet i det hele tatt finnes.

Alternativ 3: en engangs-VM eller container

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

Den er fortsatt en maskin på nettverket, så begrens tilgangen og hold den unna generell surfing. Vedlikeholdskostnaden er ett bilde til som må patcheres, 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 trenger en permanent LEGACY-vertspolicy, er en innkjøpsbeslutning i teknisk kostyme.

Den varige rettelsen hører på enheten: TLS 1.2 eller nyere, en gruppe på minst 2048 bit, en AEAD-chiffer og et sertifikat med moderne signatur. Be enhetens eier 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, for notatet er det som hindrer en midlertidig løsning i å bli standarden.