Neplatná verze TLS u AnyConnect na Linuxu: nejprve vymezte rozsah opravy
Politika LEGACY pro celý host, konfigurace OpenSSL pro jeden proces a jednorázový VM ve srovnání, plus změna na bráně, která chybu natrvalo odstraní.
Tato chyba přichází ještě před výzvou k zadání hesla, a to je ta užitečná část: nic se dosud neověřilo, takže problém není v přihlašovacích údajích. Na Linuxu může stejný dialog AnyConnect pocházet ze staré verze protokolu, ze 1024bitové skupiny pro výměnu klíčů nebo ze šifrové sady, kterou systémová krypto politika odmítá. Odstranil jsem ji třemi různými způsoby na třech strojích a tyto opravy odlišuje rozsah dopadu, ne důmyslnost. Každá je na správném místě obhajitelná a kdekoli jinde špatná výchozí volba.
Přečtěte si zprávu, než sáhnete na politiku
Zachovejte přesný řetězec z dialogu. Stížnost na verzi ukazuje na vrstvu protokolu, stížnost na certifikát na důvěru nebo pojmenování a neúspěšné přihlášení na přihlašovací údaje. Brána nabízející TLS 1.0 se 1024bitovou skupinou DHE, AES-256-CBC a podpisem SHA-1 může mít zcela platný certifikát a přesto být moderní politikou odmítnuta dřív, než se vaše údaje vůbec odešlou.
Otestujte koncový bod systémovým OpenSSL, se skutečným názvem hostitele a portem, který klient používá.
Když openssl s_client -connect vpn.example.com:443 -servername vpn.example.com selže, zatímco -tls1 -cipher DEFAULT@SECLEVEL=0 uspěje, znamená to, že hranicí je verze a velikost klíče zároveň. Pokud první příkaz hlásí malý DH klíč místo protokolového upozornění, verze je v pořádku a pozornost si žádá jen skupina. Nikdy nevkládejte do testu soukromý klíč ani heslo.
Možnost 1: uvolnit celý host pomocí krypto politiky
Na Fedoře a RHEL 8 a 9 update-crypto-policies --set LEGACY snižuje systémovou politiku OpenSSL a update-crypto-policies --show potvrzuje, co je aktivní. Obvykle to obnoví tunel, ale politika se čte při startu procesu, takže před dalším testem restartujte klienta i každý pomocný proces, který vytvořil. Umožňuje také starší protokoly a slabší skupiny každému TLS klientovi na stroji, od prohlížeče v sousedním okně po správce balíčků, který aktualizuje jádro.
Tato šíře je celý smysl i celý problém. LEGACY platí pro celý host, přetrvává a snadno se zapomene, takže by měl být diagnostickým krokem nebo dokumentovanou výjimkou na spravované sestavě, nikdy trvalým stavem pracovní stanice. Viděl jsem jednu, která zůstala na LEGACY dva roky, protože ji potřeboval jediný interní portál, a nikdo nedokázal říct, kdy to začalo.
Debian a Ubuntu na to nemají jediný přepínač. Ekvivalentem je úprava /etc/ssl/openssl.cnf, která v sekci systémových výchozích hodnot nastaví nižší MinProtocol a CipherString = DEFAULT@SECLEVEL=0. Stejný rozsah, jiný soubor, o něco snazší ztratit přehled při upgrade vydání.
Možnost 2: jeden konfigurační soubor pro jednoho klienta
Konfigurace OpenSSL pro jeden proces drží změnu uvnitř jednoho stromu procesů, ale jen pokud je soubor zapojen tak, jak knihovna očekává. Pojmenovat sekci ssl_conf nestačí: OpenSSL čte klíč nejvyšší úrovně openssl_conf, sleduje jej do inicializační sekce a teprve pak se dostane k výchozím hodnotám SSL.
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=0Nasměrujte OPENSSL_CONF na tento soubor a spusťte VPN klienta přes obal, který jej exportuje. Vše ostatní na hostu si ponechá výchozí politiku, a to je vlastnost, na které záleží, když přijde otázka souladu. Než obviníte bránu, ověřte, že soubor skutečně platí: OPENSSL_CONF=/path/to/file openssl ciphers -s -tls1 má vypsat šifry TLS 1.0, a prázdný výsledek znamená, že je řetěz přerušený a klient tiše použil systémové výchozí hodnoty.
Soubor je citlivý na verzi. OpenSSL 1.1.1 a 3.x přijímají stejné názvy sekcí, ale zpracování direktiv kolem poskytovatelů se ve 3.x změnilo, proto ověřujte logem klienta a zkušebním handshake, místo abyste předpokládali, že se soubor načetl. Překlep v názvu sekce selhává otevřeně a klient tiše použije systémové výchozí hodnoty.
Omezením je pokrytí. Cokoli linkované proti GnuTLS nebo NSS ignoruje OPENSSL_CONF, stejně jako každý pomocný proces, který klient spustí bez zděděného prostředí. Pomocí ldd zjistěte, proti které TLS knihovně je binárka skutečně linkovaná, než obal postavíte, protože odpověď rozhoduje o tom, zda tato možnost vůbec existuje.
Možnost 3: jednorázový VM nebo kontejner
Pro dodavatele, který dva týdny míří na jednu starou bránu, je vyhrazený VM s uvolněnou politikou čistší hranicí než pracovní stanice. Starý povrch a každodenní profil prohlížeče přestanou sdílet politiku jádra a likvidace je smazání, ne nález z auditu.
Pořád je to stroj v síti, takže omezte jeho přístup a držte jej mimo běžné prohlížení. Náklad na údržbu je další obraz k záplatování, což je reálné, ale omezené a viditelné, na rozdíl od zapomenutého příznaku LEGACY na notebooku.
Co vám srovnání nechá
Vybírejte podle tří otázek: kdo starý protokol potřebuje, jak dlouho a kdo si všimne, když výjimka přežije svůj důvod. Jedna aplikace, jeden člověk, několik dní ukazují na konfiguraci pro proces. Celá flotila za jedním zařízením ukazuje na bránu samotnou. Cokoli, co potřebuje trvalou politiku LEGACY na hostu, je nákupní rozhodnutí v technickém kostýmu.
Trvalá oprava patří na zařízení: TLS 1.2 nebo novější, skupina alespoň 2048 bitů, šifra AEAD a certifikát s moderním podpisem. Požádejte vlastníka zařízení o tuto změnu a pak potvrďte vyjednanou verzi a šifru v logu klienta. Zapište výjimku s hostem, branou, vyjednaným protokolem, schvalovatelem a datem vypršení, protože právě ten záznam brání tomu, aby se dočasné obejití stalo výchozím stavem.