Sledování řídicích paketů OpenVPN: tls-auth před TLS

Selhání tls-auth se obvykle hlásí jako problém handshake, i když jím nikdy nebylo. HMAC se kontroluje na řídicím paketu dřív, než proběhne jakékoli zpracování TLS, takže neshodný klíč nebo směr vyvolá selhání, které vypadá jako problém s certifikátem a rozhoduje se o dvě vrstvy dřív. Když obálku bereme jako samostatný objekt, je diagnóza krátká: přečtěte pole, potvrďte, že kontrola proběhne brzy, a pak porovnejte tři věci, na kterých se oba konce musí shodnout.

Čtěte obálku v pořadí, v jakém se skládá

Řídicí paket nese identifikátor relace, volitelný HMAC tls-auth, informace o opakování a potvrzení a spolehlivý identifikátor zprávy, za tím následuje datová část typu zprávy. Když je zpráva zprávou handshake, je datovou částí TLS šifrovaný text. To je celý vztah: materiál TLS putuje uvnitř zprávy, kterou obálka už chrání. Prohlédněte si referenci síťového protokolu OpenVPN která vypisuje pole řídicího kanálu v tomto pořadí.

Vrstvu spolehlivosti je snadné zaměnit za kryptografii. Potvrzení, opakovaný přenos a identifikátor zprávy existují proto, aby řídicí zprávy dorazily jednou a v pořadí po nespolehlivém přenosu. Nejsou to autentizace a správný identifikátor zprávy nic nedokazuje o tom, kdo paket poslal.

Berte toto seskupení jako pojem. Není to diagram pořadí bajtů a nestačí k výpočtu značky, protože pole, která vstupují do HMAC, závisí na implementaci, verzi a režimu.

Ukažte, že kontrola proběhne před handshake

Příjemce, který má sdílený klíč, může HMAC ověřit a padělaný paket okamžitě zahodit, aniž by přiděloval stav handshake nebo dělal práci s veřejným klíčem. Ochrana pokrývá i počáteční pakety handshake, a právě proto se špatný klíč projeví jako neúspěšné připojení, a ne jako pozdní chyba autentizace.

Zvyšte podrobnost démona a sledujte řídicí kanál, ne zařízení tun:

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

Hledáte selhání ověření HMAC řídicího kanálu hlášené na úrovni paketu, před jakýmkoli upozorněním TLS. Upozornění TLS v protokolu znamená, že obálka byla přijata a selhání se přesunulo dovnitř, což je jiné vyšetřování s jiným řešením.

Správa směru je také tady. Když se se statickým souborem klíče používá tls-auth, oba konce zaujmou opačné směry klíče a protokol toto rozdělení využívá, aby zachycený paket nešlo odrazit zpět k odesílateli. Obrácený směr udrží klíč stejný a přesto selže každý paket. Měňte jeden konec po druhém, pak restartujte oba démony, aby se dvojice načetla společně.

Slaďte klíč, směr a digest na obou koncích

Tři hodnoty musí souhlasit a jen jedna z nich je soubor. Obsah statického klíče musí být na obou koncích shodný, směr musí být opačný a digest použitý pro HMAC musí odpovídat. Zkontrolujte konfiguraci, než sáhnete na klíčový materiál, protože jeden obrácený směr vysvětlí víc selhání než poškozený soubor:

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

Generujte sdílené tajemství nástrojem, ne editorem, a držte oprávnění těsná:

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

Starší verze přijímaly mírně odlišné pořadí voleb pro generování klíče a profily psané pro tyto verze stále kolují. Vygenerovaný soubor je v obou případech stejný druh objektu, takže kontrola spočívá v tom, zda oba konce drží shodné bajty, ne v tom, který pravopis je vytvořil.

Nezaměňujte tls-auth s tls-crypt. Obě chrání řídicí kanál, ale tls-crypt ho také šifruje a skrývá handshake před pozorovateli, a nahrazuje rozdělení směrů vlastním zacházením s klíči. Profil s jedním nebude spolupracovat s protějškem nakonfigurovaným pro druhé a žádné ladění digestu tuto mezeru nezavře.

Reprodukujte značku jen ze skutečného formátu

Reprodukce přesná na bajt je jiný úkol než provozovat VPN a funguje jen se skutečnými vstupy: implementací a verzí, které paket sestavily, zvoleným digestem, směrem a skutečnými bajty včetně identifikátoru relace a pole potvrzení. Textový výpis seznamu polí nejsou tyto bajty.

Délka značky vyplývá z digestu, takže předpoklad pevné délky se zlomí ve chvíli, kdy ji někdo změní. Hašujte paket tak, jak to dělá implementace, ne jak ho představuje tabulka v blogovém příspěvku, a porovnávejte se záznamem pořízeným od stejného protějšku, ne s očekáváním odvozeným ručně.

Držte toto cvičení mimo produkční profily. Nic na reprodukci značky neříká, zda má nasazení ochranu zapnout.

Vraťte neshodu bez odstranění ochrany

Lákavý test je smazat tls-auth, vidět, že spojení uspěje, a usoudit, že klíč byl špatný. Taková odpověď vás stojí ochranu a nic nenaučí o tom, která ze tří hodnot nesouhlasila. Místo toho si vezměte schválenou odpovídající konfiguraci ze strany serveru a porovnejte s ní.

Připravte změnu tak, aby byla vratná. Ponechte předchozí konfiguraci serveru a soubor klíče, použijte opravenou dvojici, ověřte, že klient dokončí handshake, a teprve potom odstraňte zálohu. Pokud klienti po změně selhávají, obnovte předchozí soubory, místo abyste během výpadku improvizovali třetí variantu. Obnova by měla být jeden příkaz, který už znáte, než začnete.

Nakonec si pamatujte, co znamená prošlá kontrola. Dokazuje, že protějšek má sdílený klíč, ne že jeho certifikát nebo účet je autorizovaný, a nic neříká o vyjednané šifře datového kanálu. Autorizace a ochrana dat se ustavují později, takže čistá kontrola obálky je výchozí bod, ne verdikt.