Otillåten TLS-version i AnyConnect på Linux: avgränsa åtgärdens omfattning först

Det här felet kommer före lösenordsfrågan, och det är det användbara: ingenting har autentiserats ännu, så inloggningsuppgifterna är inte problemet. På Linux kan samma AnyConnect-dialog komma från en gammal protokollversion, en 1024-bitars nyckelutbytesgrupp eller en chifferuppsättning som systemets kryptoprincip avvisar. Jag har åtgärdat det på tre olika sätt på tre maskiner, och det som skiljer de lösningarna är omfattningen, inte fiffigheten. Var och en är försvarbar på rätt ställe och ett dåligt standardval överallt annars.

Läs meddelandet innan du rör principen

Spara den exakta strängen från dialogen. Ett versionsklagomål pekar på protokollagret, ett certifikatklagomål på förtroende eller namngivning, och en misslyckad inloggning på inloggningsuppgifterna. En gateway som erbjuder TLS 1.0 med en 1024-bitars DHE-grupp, AES-256-CBC och en SHA-1-signatur kan ha ett fullständigt giltigt certifikat och ändå avvisas av en modern princip innan dina uppgifter ens skickas.

Undersök slutpunkten med systemets OpenSSL, med det riktiga värdnamnet och den port som klienten använder.

Om openssl s_client -connect vpn.example.com:443 -servername vpn.example.com misslyckas medan -tls1 -cipher DEFAULT@SECLEVEL=0 lyckas är gränsen version och nyckelstorlek tillsammans. Om det första kommandot rapporterar en liten DH-nyckel i stället för en protokollvarning är versionen okej och bara gruppen behöver uppmärksamhet. Lägg aldrig en privat nyckel eller ett lösenord i kontrollen.

Alternativ 1: mjuka upp hela värden med kryptoprincipen

På Fedora och RHEL 8 och 9 sänker update-crypto-policies --set LEGACY systemprincipen för OpenSSL, och update-crypto-policies --show bekräftar vad som är aktivt. Det återställer oftast tunneln, men principen läses när en process startar, så starta om klienten och alla hjälpprocesser den skapat innan du testar igen. Den tillåter också äldre protokoll och svagare grupper för varje TLS-klient på maskinen, från webbläsaren i nästa fönster till pakethanteraren som uppdaterar kärnan.

Den bredden är hela poängen och hela problemet. LEGACY gäller hela värden, är bestående och lätt att glömma, så det bör vara ett diagnostiskt steg eller ett dokumenterat undantag på en hanterad installation, aldrig en arbetsstations viloläge. Jag har sett en som låg kvar på LEGACY i två år eftersom en enda intern portal behövde det, och ingen kunde säga när det började.

Debian och Ubuntu har ingen enda brytare för detta. Motsvarigheten är en ändring i /etc/ssl/openssl.cnf som sätter en lägre MinProtocol och CipherString = DEFAULT@SECLEVEL=0 i avsnittet för systemstandarder. Samma omfattning, annan fil, lite lättare att tappa bort vid en versionsuppgradering.

Alternativ 2: en konfigurationsfil för en klient

En OpenSSL-konfiguration per process håller ändringen inom ett enda processträd, men bara om filen är kopplad som biblioteket förväntar sig. Att namnge ett ssl_conf-avsnitt räcker inte: OpenSSL läser nyckeln openssl_conf på toppnivå, följer den till ett init-avsnitt och når först då SSL-standardvärdena.

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

Peka OPENSSL_CONF mot den filen och starta VPN-klienten via ett omslag som exporterar den. Allt annat på värden behåller standardprincipen, och det är egenskapen som spelar roll när efterlevnadsfrågan kommer. Bekräfta att filen verkligen gäller innan du skyller på gatewayen: OPENSSL_CONF=/path/to/file openssl ciphers -s -tls1 bör lista TLS 1.0-chiffer, och ett tomt resultat betyder att kedjan är bruten och att klienten tyst behållit systemets standardvärden.

Filen är versionskänslig. OpenSSL 1.1.1 och 3.x accepterar samma avsnittsnamn, men hanteringen av direktiv kring leverantörer ändrades i 3.x, så verifiera med klientens egen logg och ett testhandskakning i stället för att anta att filen lästes. Ett stavfel i avsnittsnamnet misslyckas öppet, och klienten använder tyst systemets standardvärden.

Begränsningen är täckningen. Allt som är länkat mot GnuTLS eller NSS ignorerar OPENSSL_CONF, och detsamma gäller varje hjälpprocess som klienten startar utan att ärva miljön. Kontrollera med ldd vilket TLS-bibliotek binären faktiskt är länkad mot innan du bygger omslaget, för svaret avgör om alternativet ens finns.

Alternativ 3: en engångs-VM eller container

För en konsult som i fjorton dagar träffar en gammal gateway är en dedikerad VM med den uppmjukade principen en renare gräns än arbetsstationen. Den gamla ytan och den dagliga webbläsarprofilen slutar dela en kärnprincip, och avvecklingen är en radering, inte ett revisionsfynd.

Den är fortfarande en maskin på nätet, så begränsa åtkomsten och håll den borta från allmänt surfande. Underhållskostnaden är en bild till att lappa, vilket är verkligt men avgränsat och synligt, till skillnad från en glömd LEGACY-flagga på en laptop.

Vad jämförelsen lämnar dig med

Välj utifrån tre frågor: vem behöver det gamla protokollet, hur länge, och vem märker det om undantaget överlever sitt skäl. En app, en person, några dagar pekar mot konfigurationen per process. En hel flotta bakom en enda enhet pekar mot själva gatewayen. Allt som kräver en permanent LEGACY-värdprincip är ett inköpsbeslut i teknisk kostym.

Den hållbara rättelsen hör på enheten: TLS 1.2 eller senare, en grupp på minst 2048 bitar, ett AEAD-chiffer och ett certifikat med modern signatur. Be enhetens ägare om den ändringen och bekräfta sedan den förhandlade versionen och chiffret i klientens logg. Skriv ned undantaget med värden, gatewayen, det förhandlade protokollet, godkännaren och ett utgångsdatum, för det är anteckningen som hindrar en tillfällig lösning från att bli standard.