Objaví sa jedno staré zariadenie, nedokáže sa pripojiť, a najrýchlejšie vyzerajúca oprava je oslabiť celého hostiteľa, kým sa spojenie nepodarí. Táto výmena je v okamihu neviditeľná a v praxi trvalá, pretože nikto neodstraňuje hranicu, ktorá napokon funguje. Tlak vytvárajú dve veľmi odlišné poruchy a iba jedna z nich je vôbec o šifrách. Najprv poruchu roztrieďte, potom umiestnite výnimku tam, odkiaľ sa nemôže rozšíriť.

Rozdeľte zlyhanie na dve časti, skôr než zmeníte direktívu

Riadok v logu servera o chýbajúcej spoločnej šifre alebo o nepodporovanej verzii protokolu prichádza z riadiaceho kanála: obe strany sa nedokázali dohodnúť, ako chrániť samotné vyjednávanie. Riadok klienta, že nie je zapnutá žiadna metóda overovania certifikátu servera, prichádza z úplne iného miesta, pretože ten klient vôbec nekontroluje, kto odpovedal. Zmena dátovej šifry nič nezmení v druhom prípade a pridanie kontroly roly nič nezmení v prvom.

Vezmite najskorší zlyhávajúci riadok z každej strany, nie posledný pred odpojením, pretože posledný je zvyčajne dôsledok. Potom zistite, ktorý súbor klient skutočne otvoril: importovaný profil často existuje dvakrát pod rôznymi zobrazovanými názvami a úprava kópie, ktorú nikto nečíta, vytvára presvedčivú neprítomnosť zmeny. Bežiaci proces si zachováva nastavenia, s ktorými začal, takže uložený súbor nie je načítaný súbor. Príkazy nižšie ukazujú vyjednávanie klienta vedľa pohľadu servera na ten istý 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 čestné miesto pre slabšiu spodnú hranicu

Keď sa zariadenie zastaví na TLS 1.0 s dátovým kanálom spred 2.5, server musí ponúknuť nižšiu hranicu riadiaceho kanála a dátovú šifru, ktorú starý klient rozpozná. Záložná direktíva existuje presne pre tohto peera, zatiaľ čo zoznam šifier drží moderných klientov na moderných sadách. Obe direktívy patria listeneru, nie používateľovi či spojeniu, a žiadna voľba pre jednotlivého klienta ich neskôr nezúži. Preto je jedno staré zariadenie na hlavnom porte rozhodnutím o každom peerovi, ktorý ten port zdieľa.

Kde to platforma dovoľuje, spustite starý listener ako samostatnú inštanciu na samostatnom porte, povoľte ten port iba z adresy zariadenia a hlavnú službu nechajte na pokoji. Zapíšte, prečo druhý listener existuje, do súboru, ktorý nesie jeho konfiguráciu, inak ho budúce čistenie prečíta ako zvyšok. Rozdelenie má zmysel len vtedy, ak sa slabšia hranica končí tam, kde sa končí zariadenie.

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

Čo starý certifikát poskytovateľa naozaj pokazí

Chyba overenia je chýbajúce prepojenie roly: bez neho klient prijme akýkoľvek certifikát, ktorý sa reťazí k dôveryhodnej CA, bez ohľadu na to, či bol vydaný pre server. Najprv prepojte certifikát s rolou servera a prepojenie berte ako požiadavku, nie ako ladiaci gombík. Iba profil, ktorý zlyhá aj po tomto kroku, má skutočný problém s certifikátom.

Starý certifikát poskytovateľa, ktorého veľkosť kľúča alebo podpisový algoritmus už nespĺňa predvolenú politiku OpenSSL, je prípadom obmedzenej zmeny bezpečnostnej úrovne na riadiacom kanáli. Zníženie úrovne tam nevypína overovanie a nikdy sa nesmie kombinovať s prázdnou CA, vypnutým overovaním či neovereným názvom hostiteľa. Držte riadok v jedinom profile, ktorý ho potrebuje; export uvoľnenej konfigurácie OpenSSL globálne by dal rovnaké uvoľnenie každému programu na stroji.

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

Čítajte vyjednané hodnoty, nie banner

Pri verbosity 4 obe strany vypíšu verziu TLS a šifru riadiaceho kanála, na ktorých sa dohodli, a dátovú šifru relácie. Čítajte tie riadky, nie inicializačný banner, ktorý hlási úspech, a nie jeho podmienky. Potom znova pripojte moderného klienta k hlavnému listeneru a potvrďte, že stále pristane na modernej sade, pretože výnimka, ktorá presiakla do zdieľanej konfigurácie, sa tu ukáže ako prvá. Hodnoty, ktoré si skopírujete, sa stanú základom ďalšej revízie.

Otestujte staré zariadenie samostatne: malo by sa pripojiť a malo by byť jedinou reláciou v logoch, ktorá ukazuje slabšie parametre. Ak aj druhý peer vyjednáva starú sadu, výnimka je širšia, než sa zamýšľalo, a rozdelenie listenerov sa naozaj nestalo. Zaznamenajte obe pozorovania, nielen záver.

Každá výnimka potrebuje vlastníka a dátum

Výnimka bez podmienky odstránenia sa ticho stane predvolenou, preto umiestnite zariadenie, vlastníka, dôvod a dátum, kedy zmizne, vedľa konfigurácie, ktorú ospravedlňuje. Bez tohto riadku slabšia hranica prežije hardvér, ktorý ju potreboval.

Nahradiť klienta alebo požiadať poskytovateľa o aktuálny profil je výsledok, o ktorý treba usilovať; výnimka je odklad, nie návrh. Keď zariadenie odchádza do dôchodku, odstráňte listener aj profil v tej istej zmene, aby žiadna polovica nebežala ďalej. Nič z toho nerobí staré parametre bezpečnými, len bráni tomu, aby sa limit jedného zariadenia stal základom všetkých.

Súvisiace články