Ongeldige TLS-versie bij AnyConnect op Linux: bepaal eerst de omvang van de oplossing

Deze fout verschijnt vóór de wachtwoordprompt, en dat is het nuttige deel: er is nog niets geauthenticeerd, dus de inloggegevens zijn het probleem niet. Op Linux kan dezelfde AnyConnect-dialoog komen van een oude protocolversie, een 1024-bits sleuteluitwisselingsgroep of een ciphersuite die het cryptobeleid van het systeem weigert. Ik heb hem op drie machines op drie verschillende manieren verholpen, en wat die oplossingen onderscheidt is de impact, niet de slimheid. Elk is verdedigbaar op de juiste plek en een slechte standaard overal elders.

Lees de melding voordat u het beleid aanraakt

Bewaar de exacte tekenreeks uit de dialoog. Een versieklacht wijst op de protocollaag, een certificaatklacht op vertrouwen of naamgeving, en een mislukte login op de inloggegevens. Een gateway die TLS 1.0 biedt met een 1024-bits DHE-groep, AES-256-CBC en een SHA-1-handtekening kan een volstrekt geldig certificaat hebben en toch door een modern beleid worden geweigerd voordat uw gegevens ooit worden verzonden.

Onderzoek het eindpunt met de OpenSSL van het systeem, met de echte hostnaam en de poort die de client gebruikt.

Als openssl s_client -connect vpn.example.com:443 -servername vpn.example.com faalt terwijl -tls1 -cipher DEFAULT@SECLEVEL=0 slaagt, ligt de grens bij versie en sleutelgrootte samen. Meldt de eerste opdracht een kleine DH-sleutel in plaats van een protocolwaarschuwing, dan is de versie in orde en vraagt alleen de groep aandacht. Stop nooit een privésleutel of wachtwoord in de controle.

Optie 1: de hele host versoepelen met het cryptobeleid

Op Fedora en RHEL 8 en 9 verlaagt update-crypto-policies --set LEGACY het systeembeleid van OpenSSL, en update-crypto-policies --show bevestigt wat actief is. Dat herstelt meestal de tunnel, maar het beleid wordt gelezen wanneer een proces start, dus herstart de client en elke helper die hij heeft gestart voordat u opnieuw test. Het staat ook oudere protocollen en zwakkere groepen toe voor elke TLS-client op de machine, van de browser in het volgende venster tot de pakketbeheerder die de kernel bijwerkt.

Die breedte is het hele doel en het hele probleem. LEGACY geldt voor de hele host, is blijvend en makkelijk te vergeten, dus het hoort een diagnostische stap of een gedocumenteerde uitzondering op een beheerde build te zijn, nooit de ruststand van een werkstation. Ik heb er een gezien die twee jaar op LEGACY bleef omdat één intern portaal het nodig had, en niemand kon zeggen wanneer het begon.

Debian en Ubuntu hebben hier geen enkele schakelaar voor. Het equivalent is een aanpassing van /etc/ssl/openssl.cnf die een lagere MinProtocol en CipherString = DEFAULT@SECLEVEL=0 instelt in de sectie met systeemstandaarden. Zelfde impact, ander bestand, iets makkelijker uit het oog te verliezen bij een release-upgrade.

Optie 2: één configuratiebestand voor één client

Een OpenSSL-configuratie per proces houdt de wijziging binnen één procesboom, maar alleen als het bestand is bedraad zoals de bibliotheek verwacht. Een sectie ssl_conf benoemen is niet genoeg: OpenSSL leest de sleutel openssl_conf op het hoogste niveau, volgt die naar een initsectie en bereikt pas daarna de SSL-standaarden.

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

Wijs OPENSSL_CONF naar dat bestand en start de VPN-client via een wrapper die het exporteert. Al het andere op de host behoudt het standaardbeleid, en dat is de eigenschap die telt wanneer de compliance-vraag komt. Bevestig dat het bestand echt van kracht is voordat u de gateway de schuld geeft: OPENSSL_CONF=/path/to/file openssl ciphers -s -tls1 hoort TLS 1.0-ciphers op te sommen, en een leeg resultaat betekent dat de keten gebroken is en de client stilletjes de systeemstandaarden heeft behouden.

Het bestand is versiegevoelig. OpenSSL 1.1.1 en 3.x accepteren dezelfde sectienamen, maar de afhandeling van richtlijnen rond providers veranderde in 3.x, dus verifieer met het log van de client zelf en een testhandshake in plaats van aan te nemen dat het bestand is gelezen. Een typefout in de sectienaam faalt open, en de client gebruikt stil de systeemstandaarden.

De beperking is dekking. Alles wat tegen GnuTLS of NSS is gelinkt, negeert OPENSSL_CONF, en dat geldt ook voor elk helperproces dat de client start zonder de omgeving te erven. Controleer met ldd tegen welke TLS-bibliotheek het binary echt is gelinkt voordat u de wrapper bouwt, want het antwoord bepaalt of deze optie überhaupt bestaat.

Optie 3: een wegwerp-VM of container

Voor een contractor die twee weken lang één oude gateway aanvalt, is een aparte VM met het versoepelde beleid een schonere grens dan het werkstation. Het oude oppervlak en het dagelijkse browserprofiel delen geen kernelbeleid meer, en afdanken is een verwijdering, geen auditbevinding.

Het blijft een machine op het netwerk, dus beperk de toegang en houd hem buiten algemeen browsen. De onderhoudskosten zijn nog een image om te patchen, wat reëel maar begrensd en zichtbaar is, anders dan een vergeten LEGACY-vlag op een laptop.

Wat de vergelijking u laat

Kies op drie vragen: wie heeft het oude protocol nodig, hoe lang, en wie merkt het als de uitzondering haar reden overleeft. Eén app, één persoon, een paar dagen wijzen op de configuratie per proces. Een hele vloot achter één apparaat wijst op de gateway zelf. Alles wat een permanent LEGACY-hostbeleid nodig heeft, is een inkoopbeslissing in technisch kostuum.

De duurzame oplossing hoort op het apparaat: TLS 1.2 of nieuwer, een groep van minstens 2048 bits, een AEAD-cipher en een certificaat met een moderne handtekening. Vraag die wijziging aan de eigenaar van het apparaat en bevestig daarna de onderhandelde versie en cipher in het log van de client. Schrijf de uitzondering op met de host, de gateway, het onderhandelde protocol, de goedkeurder en een vervaldatum, want die notitie is wat voorkomt dat een tijdelijke omweg de standaard wordt.