Ulovleg TLS-versjon i AnyConnect på Linux: avgrens omfanget av rettinga først

Denne feilen kjem før passordforespurnaden, og det er den nyttige delen: ingenting er autentisert enno, so legitimasjonen er ikkje problemet. På Linux kan den same AnyConnect-dialogen kome frå ein gammal protokollversjon, ei 1024-bits nøkkelutvekslingsgruppe eller ein chifferpakke som kryptopolitikken til systemet avviser. Eg har rydda han på tre ulike måtar på tre maskiner, og det som skil desse rettingane er omfanget, ikkje snarrådigheita. Kvar av dei er forsvarleg på rett stad og eit dårleg standardval alle andre stader.

Les meldinga før du rører politikken

Ta vare på den nøyaktige strengen frå dialogen. Ei versjonsklage peikar på protokollaget, ei sertifikatklage peikar på tillit eller namngiving, og ein mislukka innlogging peikar på legitimasjonen. Ein gateway som tilbyr TLS 1.0 med ei 1024-bits DHE-gruppe, AES-256-CBC og ein SHA-1-signatur kan ha eit fullstendig gyldig sertifikat og likevel bli avvist av ein moderne politikk før legitimasjonen din i det heile blir send.

Undersøk endepunktet med OpenSSL frå systemet, med det verkelege vertsnamnet og porten klienten brukar.

At openssl s_client -connect vpn.example.com:443 -servername vpn.example.com feilar medan -tls1 -cipher DEFAULT@SECLEVEL=0 lukkast, fortel at grensa er versjon og nøkkelstorleik saman. Viss den første kommandoen rapporterer ein liten DH-nøkkel i staden for ei protokollåtvaring, er versjonen grei og berre gruppa treng merksemd. Legg aldri ein privat nøkkel eller eit passord i undersøkinga.

Alternativ 1: slakke heile verten med kryptopolitikken

På Fedora og RHEL 8 og 9 senkar update-crypto-policies --set LEGACY systempolitikken til OpenSSL, og update-crypto-policies --show stadfestar kva som er aktivt. Det gjev vanlegvis tunnelen attende, men politikken blir lesen når ein prosess startar, so start klienten og kvar hjelpar han har starta på nytt før du testar igjen. Han tillèt òg eldre protokollar og svakare grupper for kvar TLS-klient på maskinen, frå nettlesaren i nabovindauget til pakkehandsamaren som oppdaterer kjernen.

Den breidda er heile poenget og heile problemet. LEGACY gjeld heile verten, er varig og lett å gløyme, so det bør vere eit diagnostisk steg eller eit dokumentert unntak på eit styrt bygg, aldri kvilestoda til ein arbeidsstasjon. Eg har sett ein som vart ståande på LEGACY i to år fordi ein einaste intern portal trong det, og ingen kunne seie når det byrja.

Debian og Ubuntu har ingen einbrytar for dette. Motstykket er ei endring av /etc/ssl/openssl.cnf som set ein lågare MinProtocol og CipherString = DEFAULT@SECLEVEL=0 i seksjonen for systemstandardar. Same omfang, annan fil, litt lettare å miste oversynet over under ein utgivingsopgradering.

Alternativ 2: éin konfigurasjonsfil for éin klient

Ein OpenSSL-konfigurasjon per prosess held endringa innanfor eitt prosesstre, men berre viss fila er kopla slik biblioteket ventar. Å namngje ein ssl_conf-seksjon er ikkje nok: OpenSSL les nøkkelen openssl_conf på øvste nivå, følgjer han til ein initseksjon og når først då SSL-standardane.

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

Peik OPENSSL_CONF mot den fila og start VPN-klienten gjennom ein wrapper som eksporterer ho. Alt anna på verten held på standardpolitikken, og det er eigenskapen som tel når samsvorsspurnaden kjem. Stadfest at fila faktisk er i kraft før du lastar gatewayen: OPENSSL_CONF=/path/to/file openssl ciphers -s -tls1 bør liste TLS 1.0-chiffers, og eit tomt resultat tyder på at kjeda er broten og at klienten i det stille har halde på systemstandardane.

Fila er versjonsøm. OpenSSL 1.1.1 og 3.x godtek dei same seksjonsnamna, men handsaminga av direktiv rundt leverandørar endra seg i 3.x, so stadfest med loggen til klienten sjølv og eit prøvehandtrykk i staden for å gå ut frå at fila vart lesen. Ein skrivefeil i seksjonsnamnet feilar ope, og klienten brukar i det stille systemstandardane.

Avgrensinga er dekning. Alt som er lenkja mot GnuTLS eller NSS, overser OPENSSL_CONF, og det same gjer kvar hjelpeprosess klienten startar utan å arve miljøet. Sjekk med ldd kva TLS-bibliotek binærfila faktisk er lenkja mot før du byggjer wrapperen, for svaret avgjer om dette alternativet i det heile finst.

Alternativ 3: ein eingongs-VM eller container

For ein konsulent som i fjorten dagar treffer ein gammal gateway, er ein eigen VM med den slakka politikken ei reinare grense enn arbeidsstasjonen. Den gamle flata og den daglege nettlesarprofilen sluttar å dele ein kjernepolitikk, og avhending er ei sletting, ikkje eit revisjonsfunn.

Han er framleis ein maskin på nettet, so avgrens tilgangen og hald han unna vanleg surfing. Vedlikehaldskostnaden er eitt bilete til som må patchast, noko som er reelt men avgrensa og synleg, i motsetnad til eit gløymt LEGACY-flagg på ein berbar PC.

Kva samanlikninga let deg sitje att med

Vel ut frå tre spørsmål: kven treng den gamle protokollen, kor lenge, og kven vil merke det om unntaket overlever grunnen sin. Éin app, éin person, nokre få dagar peikar mot konfigurasjonen per prosess. Ein heil flåte bak éi eining peikar mot sjølve gatewayen. Alt som treng ein permanent LEGACY-vertspolitikk, er ei innkjøpsavgjerd i teknisk kostyme.

Den varige rettinga høyrer på eininga: TLS 1.2 eller nyare, ei gruppe på minst 2048 bit, eit AEAD-chiffer og eit sertifikat med moderne signatur. Be eigaren av eininga om den endringa, og stadfest deretter den forhandla versjonen og chifferet i loggen til klienten. Skriv ned unntaket med verten, gatewayen, den forhandla protokollen, godkjenaren og ein utløpsdato, for notatet er det som hindrar at ei mellombels løysing blir standarden.