Sledovanie riadiacich paketov OpenVPN: tls-auth pred TLS

Zlyhanie tls-auth sa zvyčajne hlási ako problém handshake, hoci ním nikdy nebolo. HMAC sa kontroluje na riadiacom pakete skôr, než prebehne akékoľvek spracovanie TLS, takže nezodpovedajúci kľúč alebo smer vyvolá zlyhanie, ktoré vyzerá ako problém s certifikátom a rozhoduje sa o dve vrstvy skôr. Keď obálku berieme ako samostatný objekt, diagnóza je krátka: prečítajte polia, potvrďte, že kontrola prebehne skoro, a potom porovnajte tri veci, na ktorých sa oba konce musia zhodnúť.

Čítajte obálku v poradí, v akom sa skladá

Riadiaci paket nesie identifikátor relácie, voliteľný HMAC tls-auth, informácie o opakovaní a potvrdení a spoľahlivý identifikátor správy, za tým nasleduje dátová časť typu správy. Keď je správa správou handshake, dátovou časťou je TLS šifrovaný text. To je celý vzťah: materiál TLS putuje vnútri správy, ktorú obálka už chráni. Pozrite si referenciu sieťového protokolu OpenVPN ktorá vypisuje polia riadiaceho kanála v tomto poradí.

Vrstvu spoľahlivosti je ľahké zameniť za kryptografiu. Potvrdenia, opakovaný prenos a identifikátor správy existujú preto, aby riadiace správy dorazili raz a v poradí cez nespoľahlivý prenos. Nie sú to autentifikácia a správny identifikátor správy nič nedokazuje o tom, kto paket poslal.

Berte toto zoskupenie ako pojem. Nie je to diagram poradia bajtov a nestačí na výpočet značky, pretože polia, ktoré vstupujú do HMAC, závisia od implementácie, verzie a režimu.

Ukážte, že kontrola prebehne pred handshake

Príjemca, ktorý má zdieľaný kľúč, môže HMAC overiť a podvrhnutý paket okamžite zahodiť, bez prideľovania stavu handshake alebo práce s verejným kľúčom. Ochrana pokrýva aj počiatočné pakety handshake, a práve preto sa zlý kľúč prejaví ako neúspešné pripojenie a nie ako neskorá chyba autentifikácie.

Zvýšte podrobnosti démona a sledujte riadiaci kanál, nie zariadenie tun:

openvpn --config /etc/openvpn/server.conf --verb 6

Hľadáte zlyhanie overenia HMAC riadiaceho kanála hlásené na úrovni paketu, pred akýmkoľvek upozornením TLS. Upozornenie TLS v protokole znamená, že obálka bola prijatá a zlyhanie sa presunulo dovnútra, čo je iné vyšetrovanie s iným riešením.

Správa smeru je tiež tu. Keď sa so statickým súborom kľúča používa tls-auth, oba konce zaujmú opačné smery kľúča a protokol využíva toto rozdelenie, aby zachytený paket nebolo možné odraziť späť k jeho odosielateľovi. Obrátený smer udrží kľúč rovnaký a napriek tomu zlyhá každý paket. Meňte jeden koniec po druhom, potom reštartujte oba démonov, aby sa dvojica načítala spolu.

Zlaďte kľúč, smer a digest na oboch koncoch

Tri hodnoty musia súhlasiť a iba jedna z nich je súbor. Obsah statického kľúča musí byť na oboch koncoch rovnaký, smer musí byť opačný a digest použitý pre HMAC musí sedieť. Skontrolujte konfiguráciu, kým sa dotknete kľúčového materiálu, pretože jeden obrátený smer vysvetlí viac zlyhaní než poškodený súbor:

grep -E 'tls-auth|tls-crypt|key-direction|auth ' /etc/openvpn/server.conf

Generujte zdieľané tajomstvo nástrojom, nie editorom, a držte práva tesné:

openvpn --genkey secret /etc/openvpn/ta.key
chmod 600 /etc/openvpn/ta.key

Staršie vydania prijímali mierne odlišné poradie volieb na generovanie kľúčov a profily napísané pre tieto vydania stále kolujú. Vygenerovaný súbor je v oboch prípadoch rovnaký druh objektu, takže kontrola spočíva v tom, či oba konce držia rovnaké bajty, nie v tom, ktorý pravopis ich vytvoril.

Nezamieňajte tls-auth s tls-crypt. Oba chránia riadiaci kanál, ale tls-crypt ho aj šifruje a skrýva handshake pred pozorovateľmi, a nahrádza rozdelenie smerov vlastným zaobchádzaním s kľúčmi. Profil s jedným nebude spolupracovať s partnerom nakonfigurovaným pre druhé a žiadne ladenie digestu túto medzeru neuzavrie.

Reprodukujte značku len zo skutočného formátu

Reprodukcia presná na bajt je iná úloha než prevádzkovať VPN a funguje len so skutočnými vstupmi: implementáciou a verziou, ktoré paket zostavili, zvoleným digestom, smerom a skutočnými bajtmi vrátane identifikátora relácie a poľa potvrdení. Textový výpis zoznamu polí nie sú tieto bajty.

Dĺžka značky vyplýva z digestu, takže predpoklad pevnej dĺžky sa zlomí vo chvíli, keď ju niekto zmení. Hašujte paket tak, ako to robí implementácia, nie ako ho predstavuje tabuľka v blogovom príspevku, a porovnávajte so záznamom získaným od toho istého partnera, nie s očakávaním odvodeným ručne.

Držte toto cvičenie mimo produkčných profilov. Nič na reprodukcii značky nehovorí, či má nasadenie ochranu zapnúť.

Vráťte nezhodu bez odstránenia ochrany

Lákavý test je zmazať tls-auth, vidieť, že spojenie uspeje, a usúdiť, že kľúč bol zlý. Taká odpoveď vás stojí ochranu a nič nenaučí o tom, ktorá z troch hodnôt nesúhlasila. Namiesto toho si vezmite schválenú zodpovedajúcu konfiguráciu zo strany servera a porovnajte s ňou.

Pripravte zmenu tak, aby bola vratná. Ponechajte predchádzajúcu konfiguráciu servera a súbor kľúča, použite opravenú dvojicu, overte, že klient dokončí handshake, a až potom odstráňte zálohu. Ak klienti po zmene zlyhávajú, obnovte predchádzajúce súbory, namiesto toho, aby ste počas výpadku improvizovali tretí variant. Obnova by mala byť jeden príkaz, ktorý už poznáte pred začiatkom.

Na záver si pamätajte, čo znamená prejdená kontrola. Dokazuje, že partner má zdieľaný kľúč, nie že jeho certifikát alebo účet je autorizovaný, a nič nehovorí o vyjednanej šifre dátového kanála. Autorizácia a ochrana údajov sa ustanovujú neskôr, takže čistá kontrola obálky je východiskový bod, nie verdikt.