Miért nem tudja az openssl rand létrehozni a tls-crypt által kért kulcsot

Az OpenSSL már telepítve van, a gazdagépnek van entrópiája, és kulcsot generálni vele a kézenfekvő rövidítésnek tűnik. A kimenet véletlenszerű és titkos és teljesen használhatatlan lesz, a hiba pedig vezérlőcsatorna-hibaként érkezik, nem pedig valamiként, ami kulcsformátumot említ. Ez a félrevezetés a drága rész, mert embereket küld a titkosításaik vizsgálatára. Amit a VPN olvas, az egy meghatározott fájlszerkezet, nem egy tetszőleges bájtblokk, és a funkció egyik változata egyáltalán nem állítható elő a kiszolgálón kívül.

Milyennek kell lennie valójában a lemezen lévő fájlnak

Az OpenVPN statikus kulcsfájlja szöveg. Egy megjegyzéssorral kezdődik, amely kijelenti, mi az, hexadecimális adatokat hordoz rögzített szélességű sorokban, és összesen 256 bájt kulcsanyagot tartalmaz. Az OpenVPN a vezérlőcsatorna megosztott titkaként olvassa, nem tanúsítványként, nem jelmondatként és nem olyasmiként, amit egy TLS-könyvtár felismerne.

Ugyanaz az objektumtípus szolgálja a vezérlőcsatorna mindkét funkcióját. A tls-auth esetében minden társnak irányra is szüksége van, hogy az egyik oldal csomagjai ne tükröződhessenek vissza rá. A tls-crypt esetében egyetlen megosztott titok titkosítja és hitelesíti a vezérlőcsatornát mindkét irányban, ami elrejti a kézfogást és egyben védi is.

Ebből semmi sem titkos tudás, és a formátum nem a lényeg. A lényeg az, hogy a fájlnak pontosan meg kell felelnie annak, amit az olvasó vár: fejléc, sorszélesség, záró újsor és teljes hossz. Az egy sorral eltérő fájl szemétként töltődik be, vagy egyáltalán nem sikerül. Ezért két társ bájtra történő összehasonlítása jogos első teszt, és gyorsabb, mint a két konfigurációs fájl bármelyikének elolvasása.

A támogatott módja annak, hogy egyet készítsünk

Generálja le az egyszerű statikus kulcsot azzal az eszközzel, amely használni fogja, majd hivatkozzon rá mindkét végponton:

openvpn --genkey secret /etc/openvpn/tc-shared.key
tls-crypt /etc/openvpn/tc-shared.key

Az opció írásmódja idővel megváltozott: a 2.4 korszakából származó régebbi telepítések a fájlnév előtt külön kapcsolóval rendelkező formát használtak, míg a jelenlegi buildek a rövidebbet fogadják el. Akárhogy is, az eredményül kapott fájl ugyanaz az objektumtípus, ezért az ellenőrzés az, hogy a két társ azonos bájtokkal rendelkezik-e.

A második generáció olyan szerkezetet ad hozzá, amelyet semmilyen külső generátor nem tud kitalálni. A kiszolgálókulcs egyszer jön létre, és minden ügyfél egy abból származtatott becsomagolt kulcsot kap:

openvpn --genkey tls-crypt-v2-server /etc/openvpn/tc-v2-server.key
openvpn --genkey tls-crypt-v2-client /etc/openvpn/laptop1.key --tls-crypt-v2 /etc/openvpn/tc-v2-server.key

Amit az ügyfél kap, az nem a kiszolgáló saját kulcsának másolata. Ez egy becsomagolt objektum, amely olyan metaadatokat hordoz, amelyeket csak a kiszolgáló tud kicsomagolni, és éppen ez a becsomagolás az oka annak, hogy egy eszközönkénti fájl visszavonható anélkül, hogy bármely más eszközt érintene. Tartsa a kiszolgálókulcsot a kiszolgálón, és kezelje úgy, mint az eszközönkénti bizalom gyökerét.

Ahol a kézzel készített bájtok összeomlanak

256 véletlen bájt hexadecimálisként való kinyomtatása egy helyes fejléc alatt elméletileg egy betölthető statikus kulcsfájlt eredményezne. Ez továbbra is rossz ötlet. Minden formázási részlet lehetőséggé válik arra, hogy olyan anyagot állítsunk elő, amely betöltéskor meghiúsul, vagy ami még rosszabb, két társat különböző értékekkel hagy, amelyek csak hitelesítési hibaként mutatkoznak meg.

A v2 változattal semmi egyenértékű nem lehetséges. A becsomagolt ügyfélkulcs csak a kiszolgáló kulcsfolyamatának kimeneteként létezik, és a kiszolgáló megtartja a kicsomagolásához szükséges anyagot. Egy véletlen blob elutasításra kerül, vagy egyszerűen nem sikerül visszafejteni, és egyik üzenet sem említi a véletlenszerűséget.

A verziókompatibilitás mindezek fölött áll. Az első generációhoz olyan kiadás kell, amely mindkét végén támogatja, a másodikhoz pedig ismét újabb kiadás kell. Egy, a funkció létezése előtt épített ügyfél nem tud kézfogást befejezni egy olyan kiszolgálóval, amely csak becsomagolt anyagot fogad el, és az általa jelentett hiba a vezérlőcsatornára mutat, nem a verzióra.

Forgatás anélkül, hogy mindenkit kizárnánk

Egyetlen megosztott titok forgatása koordinációs gyakorlat, nem technikai. Minden ügyfélnek kéznél kell lennie a cserefájlnak, mielőtt a kiszolgáló visszavonja az előzőt, és minden gép, amely még a régi értéket tartja, abban a pillanatban meghiúsul. Ne kezdje ezt a forgatást egy munkanap közepén.

A v2 elrendezéssel a forgatás eszközönként történik: adjon ki új becsomagolt kulcsot egy géphez, és csak ahhoz a géphez vonja vissza a régit. Ez a fő érv az átállás mellett, amint minden ügyfél olyan kiadáson van, amely támogatja.

A fájlengedélyek ugyanabba a beszélgetésbe tartoznak. A kulcsot csak a szolgáltatást futtató fiók olvashassa, és ne ugyanabban a tárolóban éljen, mint a védett profilok. Az OpenVPN 2.6 referenciája dokumentálja a generálási formákat és a kulcsanyag-szakaszokat, ami jobb forrás, mint egy fórumbejegyzésből másolt parancs.