OpenVPN-vezérlőcsomagok nyomkövetése: tls-auth a TLS előtt

A tls-auth hibát általában kézfogási problémaként jelentik, pedig soha nem volt az. A HMAC-ot a vezérlőcsomagon ellenőrzik, mielőtt bármilyen TLS-feldolgozás történne, ezért a nem megfelelő kulcs vagy irány olyan hibát okoz, amely tanúsítványproblémának látszik, és két réteggel korábban dől el. A boríték külön objektumként kezelése lerövidíti a diagnózist: olvassa el a mezőket, erősítse meg, hogy az ellenőrzés korán lefut, majd hasonlítsa össze azt a három dolgot, amelyben mindkét félnek meg kell egyeznie.

A borítékot abban a sorrendben olvassa, ahogy felépül

A vezérlőcsomag munkamenet-azonosítót, az opcionális tls-auth HMAC-ot, ismétlési és nyugtázási információt, valamint megbízható üzenetazonosítót hordoz, és utána következik az üzenettípus hasznos terhe. Ha az üzenet kézfogási üzenet, a hasznos teher éppen TLS-titkosított szöveg. Ez a teljes kapcsolat: a TLS-anyag egy olyan üzeneten belül utazik, amelyet a boríték már véd. A OpenVPN hálózati protokoll-referencia felsorolja a vezérlőcsatorna mezőit ebben a sorrendben.

A megbízhatósági réteget könnyű összetéveszteni a kriptográfiával. A nyugtázások, az újraküldés és az üzenetazonosító azért léteznek, hogy a vezérlőüzenetek megbízhatatlan átvitelen keresztül egyszer és sorrendben érkezzenek meg. Ezek nem hitelesítés, és a helyes üzenetazonosító semmit nem bizonyít arról, ki küldte a csomagot.

Tartsa ezt a csoportosítást fogalminak. Ez nem bájtsorrend-diagram, és nem elég egy címke kiszámításához, mert a HMAC-ba kerülő mezők a megvalósítástól, a verziótól és a módtól függenek.

Mutassa meg, hogy az ellenőrzés a kézfogás előtt fut le

A megosztott kulccsal rendelkező fogadó ellenőrizheti a HMAC-ot, és azonnal eldobhatja a hamisított csomagot, anélkül hogy kézfogási állapotot foglalna le vagy nyilvános kulcsú munkát végezne. A védelem a kezdeti kézfogási csomagokat is lefedi, és éppen ezért jelenik meg a rossz kulcs sikertelen kapcsolatként, nem pedig késői hitelesítési hibaként.

Növelje a daemon részletességét, és a tun-eszköz helyett a vezérlőcsatornát figyelje:

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

Amit keres, az a vezérlőcsatorna HMAC-ellenőrzésének csomagszinten jelentett hibája, minden TLS-riasztás előtt. A naplóban megjelenő TLS-riasztás azt jelenti, hogy a borítékot elfogadták, és a hiba befelé mozdult, ami más vizsgálat és más javítás.

Az iránykezelés is itt van. Amikor statikus kulcsfájlt használnak a tls-auth-tal, a két vég ellentétes kulcsirányt vesz fel, és a protokoll ezt a felosztást használja, hogy egy elfogott csomag ne tükröződhessen vissza a küldőjéhez. Az irány megfordítása ugyanazt a kulcsot hagyja, és mégis minden csomag meghiúsul. Egyszerre egy véget változtasson, majd indítsa újra mindkét daemont, hogy a pár együtt töltődjön be.

Hangolja össze a kulcsot, az irányt és a digestet mindkét végén

Három értéknek egyeznie kell, és csak az egyik közülük a fájl. A statikus kulcs tartalmának mindkét végén azonosnak kell lennie, az iránynak ellentétesnek kell lennie, és a HMAC-hoz használt digestnek egyeznie kell. A kulcsanyag megérintése előtt ellenőrizze a konfigurációt, mert egyetlen fordított irány több hibát magyaráz, mint egy sérült fájl:

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

A közös titkot az eszközzel hozza létre, ne szerkesztővel, és tartsa szigorúan a jogosultságokat:

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

A régebbi kiadások kissé eltérő beállítási sorrendet fogadtak el a kulcsgeneráláshoz, és az ezekhez a kiadásokhoz írt profilok még mindig forgalomban vannak. A létrehozott fájl mindkét esetben ugyanolyan típusú objektum, tehát az ellenőrzés az, hogy mindkét vég azonos bájtokat tart-e, nem pedig az, hogy melyik írásmód hozta létre őket.

Ne keverje össze a tls-auth-ot a tls-crypttel. Mindkettő védi a vezérlőcsatornát, de a tls-crypt titkosítja is, és elrejti a kézfogást a megfigyelők elől, és saját kulcskezeléssel váltja fel az irányfelosztást. Az egyiket használó profil nem működik együtt a másikra beállított partnerrel, és semmilyen digest-hangolás nem zárja be ezt a rést.

Csak a valódi formátumból reprodukáljon címkét

A bájtpontos reprodukció külön feladat a VPN üzemeltetésétől, és csak a valódi bemenetekkel működik: a csomagot építő megvalósítással és verzióval, a kiválasztott digesttel, az iránnyal és a tényleges bájtokkal, beleértve a munkamenet-azonosítót és a nyugtázási tömböt. A mezőlista szöveges megjelenítése nem ezek a bájtok.

A címke hossza a digestből következik, ezért a fix hosszúság feltételezése abban a pillanatban megdől, amikor valaki megváltoztatja. A csomagot úgy hashelje, ahogy a megvalósítás teszi, nem úgy, ahogy egy blogbejegyzés táblázata bemutatja, és a saját kezűleg levezetett elvárás helyett az ugyanattól a partnertől vett rögzítéshez hasonlítsa.

Tartsa ezt a gyakorlatot távol az éles profiloktól. A címke reprodukálása semmit nem mond arról, hogy egy telepítésnek engedélyeznie kell-e a védelmet.

Vonja vissza az eltérést a védelem eltávolítása nélkül

A csábító teszt a tls-auth törlése, a kapcsolat sikerének megfigyelése és annak megállapítása, hogy a kulcs rossz volt. Ez a válasz a védelembe kerül, és semmit nem tanít arról, melyik három érték tért el. Ehelyett kérje el a jóváhagyott megfelelő konfigurációt a kiszolgáló oldaláról, és ahhoz hasonlítson.

Készítse elő a változtatást visszafordíthatóan. Őrizze meg az előző kiszolgálókonfigurációt és kulcsfájlt, alkalmazza a javított párt, ellenőrizze, hogy egy kliens befejezi a kézfogást, és csak ezután távolítsa el a biztonsági mentést. Ha a kliensek a változtatás után meghiúsulnak, állítsa vissza az előző fájlokat, ne pedig egy harmadik változatot rögtönözzön kiesés közben. A visszaállításnak egyetlen parancsnak kell lennie, amelyet már ismer a kezdés előtt.

Végül emlékezzen arra, mit jelent egy sikeres ellenőrzés. Azt bizonyítja, hogy a partner rendelkezik a megosztott kulccsal, nem pedig azt, hogy a tanúsítványa vagy fiókja engedélyezett, és semmit nem mond a megtárgyalt adatcsatorna-titkosításról. Az engedélyezés és az adatvédelem később jön létre, ezért a tiszta borítékellenőrzés kiindulópont, nem ítélet.