Jeden starý peer vynucuje TLS 1.0: ohraničte výjimku, ne hostitele

Objeví se jedno staré zařízení, nedokáže se připojit a nejrychlejší zdánlivá oprava je oslabit celého hostitele, dokud spojení neuspěje. Tato výměna je v dané chvíli neviditelná a v praxi trvalá, protože nikdo neodstraňuje minimum, které konečně funguje. Tlak vytvářejí dvě velmi odlišné závady a jen jedna z nich se vůbec týká šifer. Nejprve závadu roztřiďte, potom výjimku umístěte tam, odkud se nemůže šířit.

Rozdělte selhání na dvě části, než upravíte direktivu

Řádek v logu serveru o chybějící společné šifře nebo o nepodporované verzi protokolu pochází z řídicího kanálu: obě strany se nedohodly, jak chránit samotné vyjednávání. Naproti tomu řádek klienta, že není zapnutá žádná metoda ověření certifikátu serveru, pochází úplně odjinud, protože ten klient vůbec nekontroluje, kdo odpověděl. Změna datové šifry nic neřeší v druhém případě a přidání kontroly role nic neřeší v prvním.

Vezměte nejranější chybový řádek z každé strany, ne poslední řádek před odpojením, protože poslední bývá důsledek. Potom zjistěte, který soubor klient skutečně otevřel: importovaný profil často existuje dvakrát pod různými zobrazovanými názvy a úprava kopie, kterou nikdo nečte, vytvoří přesvědčivou žádnou změnu. Běžící proces si drží nastavení, se kterým se spustil, takže uložený soubor není načtený soubor. Příkazy níže ukazují vyjednávání klienta vedle pohledu serveru na stejný pokus.

openvpn --config <profile>.ovpn --verb 4 2>&1 | head -n 40
journalctl -u [email protected] --since '-10 min' | grep -iE 'cipher|tls|verify'

Druhý listener je poctivé místo pro slabší minimum

Když zařízení skončí na TLS 1.0 s datovým kanálem před 2.5, musí server nabídnout nižší minimum řídicího kanálu a datovou šifru, kterou starý klient rozpozná. Zálohová direktiva existuje právě pro takového partnera, zatímco seznam šifer drží moderní klienty na moderních sadách. Obě direktivy patří listeneru, ne uživateli nebo spojení, a žádná volba pro jednotlivého klienta je dodatečně nezužuje. Proto je jedno staré zařízení na hlavním portu rozhodnutím o každém partnerovi, který ho sdílí.

Kde to platforma dovolí, spusťte starý listener jako jeho vlastní instanci na samostatném portu, povolte ten port jen z adresy zařízení a hlavní službu nechte být. Zapište, proč druhý listener existuje, do souboru, který nese jeho konfiguraci, protože budoucí úklid ho jinak přečte jako pozůstatek. Rozdělení má smysl jen tehdy, když slabší minimum končí tam, kde končí zařízení.

tls-version-min 1.0
data-ciphers AES-128-GCM:AES-256-GCM:AES-256-CBC
data-ciphers-fallback AES-256-CBC

Co starý certifikát poskytovatele skutečně rozbíjí

Chyba ověření je chybějící vazba na roli: bez ní klient přijme jakýkoli certifikát, který se řetězí k důvěryhodné CA, ať už byl vydán pro server, nebo ne. Nejprve svažte certifikát s rolí serveru a vazbu berte jako požadavek, ne jako seřizovací knoflík. Skutečný problém s certifikátem má jen profil, který po tomto kroku stále selhává.

Starý certifikát poskytovatele, jehož velikost klíče nebo podpisový algoritmus už nevyhovuje výchozí politice OpenSSL, je případem pro omezenou změnu úrovně zabezpečení na řídicím kanálu. Snížení úrovně tam ověřování nevypíná a nikdy se nesmí kombinovat s prázdnou CA, vypnutým nastavením ověřování nebo nezkontrolovaným názvem hostitele. Držte řádek uvnitř jediného profilu, který ho potřebuje; globální export uvolněné konfigurace OpenSSL by stejné uvolnění dal každému programu na stroji.

remote-cert-tls server
tls-cipher "DEFAULT:@SECLEVEL=0"

Čtěte vyjednané hodnoty, ne banner

Při podrobnosti 4 obě strany vypíšou verzi TLS a šifru řídicího kanálu, na kterých se shodly, a datovou šifru relace. Čtěte tyto řádky, ne inicializační banner, který hlásí úspěch, a ne jeho podmínky. Potom znovu připojte moderního klienta k hlavnímu listeneru a ověřte, že stále končí na moderní sadě, protože výjimka, která unikla do sdílené konfigurace, se ukáže nejdřív tady. Hodnoty, které si opíšete, se stanou výchozí linií pro příští revizi.

Otestujte staré zařízení samostatně: mělo by se připojit a mělo by být jedinou relací v logech, která ukazuje slabší parametry. Pokud i druhý partner vyjedná starou sadu, výjimka je širší, než bylo zamýšleno, a rozdělení listeneru se skutečně nestalo. Zapište obě pozorování, ne jen závěr.

Každá výjimka potřebuje vlastníka a datum

Výjimka bez podmínky odstranění se tiše stane výchozí, proto dejte zařízení, vlastníka, důvod a datum, kdy zmizí, vedle konfigurace, kterou ospravedlňuje. Bez toho řádku slabší minimum přežije hardware, který ho potřeboval.

Výměna klienta nebo žádost poskytovatele o aktuální profil je cílový výsledek; výjimka je odklad, ne návrh. Když zařízení skončí, odstraňte listener i profil v jedné změně, aby nezůstala běžet ani jedna polovina. Nic z toho staré parametry nečiní bezpečnými, jen brání tomu, aby se limit jednoho zařízení stal základem pro všechny.