DH-fájl vagy tls-auth kulcs? Két OpenVPN-fájl megkülönböztetése

Két fájl, két direktíva és az a szokás, hogy mindkettőt arról nevezzük el, amit beállítanak. Így kerül a dh.pem egy tls-auth sorba, és a kliens egy váratlan kulcsformátumról szóló üzenettel hiúsul meg. A döntés előtted nem az, melyik fájl erősebb. Hanem az, milyen szerepre van a telepítésnek valóban szüksége, és három feltétel dönti el: milyen kulcscserét fog egyeztetni a TLS-veremed, akarsz-e egyáltalán vezérlőcsatorna-hitelesítést, és titokban kell-e maradnia az anyagnak.

Válaszolj rájuk sorrendben, és a fájlkérdés magától megválaszolódik. Ha kihagyod őket, a direktívanevek kezdenek felcserélhetőnek tűnni, és pontosan ez az az állapot, amiből a hiba származik.

A címkét olvasd el a fájlnév előtt

A fájl első sora többet mond a nevénél, mert a név emberi konvenció, a címkét pedig az eszköz állítja elő. A Diffie-Hellman paraméterek PEM-címkéje BEGIN DH PARAMETERS. Az OpenVPN statikus kulcsa teljesen más szerkezet, saját fejléccel és hexadecimális teherrel.

Az átnevezés semmit nem alakít át. Egy ta.key nevű paraméterfájl továbbra is paraméterek, és egy dh.pem nevű statikus kulcs továbbra is statikus kulcs; az elemző olvassa a tartalmat, és elutasítja az eltérést. Ellenőrizd, mielőtt szerkeszted a profilt:

head -n 1 dh.pem
head -n 1 ta.key

Három feltétel, amely eldönti, melyik fájlra van szükséged

Az első feltétel a csere. A véges mezős Diffie-Hellman kézfogásnak csoportra van szüksége, és a dh direktíva az a hely, ahol a szerver megnevezi hozzá a paramétereket. Az elliptikus görbés kézfogásnak egyáltalán nincs szüksége arra a fájlra, mert a görbe maga a paraméterhalmaz. Ha a szervered csak ECDHE-csomagokat egyeztet, akkor a DH-fájl holt teher, nem pedig extra erő.

A második feltétel a vezérlőcsatorna hitelesítése, amely külön funkció saját anyaggal. A tls-auth fájl egy megosztott statikus kulcs, amelyet mindkét fél tart, és amelyet a vezérlőcsatorna csomagjainak aláírására használnak, hogy egy nem hitelesített fél még a kézfogást se tudja befejezni. Akár használsz véges mezős DH-t, akár nem, létezik, és semmi köze a csoportparaméterekhez.

A harmadik feltétel a titkosság és a terjesztés. A DH-paraméterek közzétehetők a munkamenet gyengítése nélkül, mert a titkos értékek kézfogásonként generálódnak, és soha nem hagyják el a feleket. A statikus kulcsot nem szabad közzétenni: ugyanazok a bájtok mindkét végén, magától nem cserélődik, és aki birtokolja, érvényes vezérlőcsatorna-aláírásokat tud előállítani. Ez a két válasz teljesen eltérő kezelési szabályokra mutat, ezért az egyik fájl állhat egy tárolóban, a másik nem.

Állítsd elő a megfelelő anyagot minden szerephez

Azt az eszközt használd, amely a direktíva által várt formátumot állítja elő, ahelyett hogy közöttük alakítanál át. Az OpenVPN 2.6 megosztott kulcsához a generátor típusos formája kifejezetten megnevezi a célt.

openvpn --genkey tls-auth ta.key

Ez a parancs új titkos anyagot hoz létre; nem javít és nem vizsgál meglévő kulcsot, és újrafuttatva más kulcsot kapsz, amivel a többi fél nem rendelkezik. Másold a keletkezett fájlt azokhoz a felekhez, akiknek kell, olyan csatornán, amit bármely megosztott titokhoz használnál, és tartsd következetesen az iránykonvenciót: a tls-auth esetén az egyik oldal key-direction 0, a másik key-direction 1 beállítást használ.

A DH-paraméterek, amikor kellenek, paramétergenerálásból származnak, nem kulcsgenerátorból, és az eredetük akkor is számít, ha a kimenet nyilvános. Egy ismeretlen forrásból vett csoport nem válik megbízhatóvá attól, hogy nyilvános; továbbra is olyan csoportnak kell lennie, amiben a felek megegyeznek, és amelyet nem gyengít a mérete vagy a szerkezete.

Mit tesz a dh none, és mit nem

dh none valódi direktíva szűk jelentéssel: nem töltődik be véges mezős paraméterfájl, mert a kézfogás elliptikus görbés Diffie-Hellmant használ. Nem a „hagyd ki a DH-lépést” rövidítése abban az értelemben, hogy bármit gyengítene, és biztosan nem mondja azt az OpenVPN-nek, hogy fogadjon el más fájlt helyettesítőként.

Két hiba következik a félreolvasásából. Az első az a feltevés, hogy a dh none megszünteti a tls-auth iránti igényt, holott a kettő különböző dolgokat vezérel. A második az, hogy egy elavult dh sort tartunk egy csak-görbés konfiguráció mellett, majd azon tűnődünk, melyik fájlt használja valójában a szerver; ha a direktíva jelen van, a fájl beolvasódik, és egy ott elromlott útvonal az indulást olyan okból hiúsítja meg, amelynek semmi köze az egyeztetendő cseréhez.

Ha a rossz fájl már telepítve van

Állítsd vissza a szándékolt titkot a profil tulajdonosától, és közben ne nyúlj a tanúsítvány-ellenőrzéshez. A hiba formátumeltérés, nem bizalmi hiba, és az ellenőrzés kikapcsolása a hiba megkerüléséhez egy indítási problémát csendes problémára cserél.

Aztán válaszd szét a két eseményt, amelyeket az emberek hajlamosak összemosni. Egy DH-paraméterfájl közzététele szinte ártalmatlan, mert a paraméterek tervezésüknél fogva nyilvánosak voltak. A tls-auth kulcs felfedése más esemény: a kulcs minden őt tartó fél számára hitelesíti a vezérlőcsatorna csomagjait, ezért a cserét az egész telepítésre kiterjedően kell összehangolni, nem egyetlen hoszton alkalmazni.

Egy ötperces ellenőrzés eldönti, melyik esetben vagy: olvasd el minden fájl első sorát, igazold a rá hivatkozó direktívát, és igazold, hogy a fájl terjesztése megfelel annak, amit az anyag megkövetel. Ez kisebb munka, mint egy működő PKI újragenerálása, és erre mutattak a három feltételek végig.