OpenVPN CA nélkül: hogyan ellenőrzi a peer-fingerprint a partnereket

Egy kis telepítés az ujjlenyomatokhoz nyúl, mert a tanúsítványhatóság olyan infrastruktúrának tűnik, amelyre senkinek nincs ideje. Az ösztön ésszerű, de a rövidítés, amelyet az emberek helyette választanak—egy adatcsatorna titkának átmásolása mindkét végre—nem az. A peer-fingerprint beállítás érintetlenül tartja a TLS szerkezetét: mindkét fél továbbra is a saját titkos kulcsát és tanúsítványát tartja, és mindkét fél továbbra is ellenőrzi a másikat. Ami változik, az az, hogy hol horgonyzódik az ellenőrzés: egy megbízható kibocsátótól a rögzített kivonatok rövid listájáig. Mivel a kivonat a teljes tanúsítványt fedi le, nem egy nevet, a megújítás olyan műveletté válik, amely valóban időt vesz igénybe.

Mihez is kötelezi magát az ujjlenyomat

A tanúsítvány ujjlenyomata a teljes DER-kódolt tanúsítvány kivonata, nem a nyilvános kulcsáé és nem az alanynevéé. Ezért két tanúsítványnak, amelynek azonos a neve és ugyanaz a kulcsa, de eltérő az érvényességi ideje, eltérő az ujjlenyomata. Ez teszi pontossá a rögzítést, és ez teszi zavaróvá a megújítást is. A rögzítés nem jelenthet általános bizalmat egy kulcsban, mert egyetlen tárgyat nevez meg annak élete egyetlen pillanatában. A kivonatot bárki ismerheti, és az ismerete önmagában semmit sem bizonyít.

openssl x509 -in server.crt -noout -fingerprint -sha256
openssl x509 -in client-07.crt -noout -fingerprint -sha256

A megfelelő titkos kulcs birtoklása bizonyítja, hogy a partner rendelkezik ezzel a tanúsítvánnyal, a kivonat pedig az, ahogyan a másik fél eldönti, egyáltalán számított-e erre a tanúsítványra. Ez a szétválasztás az oka annak, hogy ez a terv nem a régi közös titok elrendezése: a közös kulcs bárkit hitelesít, aki ismeri ugyanazokat a bájtokat, míg a rögzítés egyetlen tanúsítványt hitelesít. Egy másik eszköz a saját bejegyzését kapja, nem ugyanannak a titoknak a másolatát, ami kis különbség a fájlokban és nagy a kár kiterjedésében.

A térkép kölcsönös, nem szimmetrikus

Minden végpontnak két dologra van szüksége: a saját titkos kulcsára a tanúsítvánnyal, és egy nyilatkozatra arról, mely partner-tanúsítványokat fogadja el. Az ügyfélnél ez a nyilatkozat a szerver tanúsítványának kivonata; a szerveren a regisztrált ügyfél-kivonatok listája. Egy hivatalos példa kis beállításhoz a Community 2.6 számára bemutatja az elrendezést peer-fingerprint-gyel, és érdemes elolvasni, mielőtt ezt a bizalmi modellt valódi telepítéshez választaná. A két irány nem egy megfordított lista, és nem ugyanabban a pillanatban hibáznak.

Egy eszköz hozzáadása a szerver engedélyezési listáját szerkeszti, anélkül hogy egy meglévő ügyfél titkos anyagát másolná, és anélkül hogy a szerver kulcsát bárhová mozgatná. A két irány egymástól függetlenül is hibázik, ami diagnóziskor hasznos: amelyik fél bezárja a kézfogást, az az a fél, amelynek az elvárása nem teljesült. Ha az ügyfél elutasítja a szervert, a kivonat nem egyezik a bemutatott tanúsítvánnyal. Ha a szerver elutasítja az ügyfelet, annak az ügyfélnek a kivonata hiányzik a listáról, vagy az ügyfél nem a regisztrált tanúsítványt mutatja be.

Regisztráció: hogyan csatlakozik egy új eszköz

Az új eszköz kulcsát és tanúsítványát ott hozza létre, ahol a titkos kulcs élni fog, majd csak a nyilvános tárgyat mozgassa ahhoz a félhez, amelynek rögzítenie kell. Az elvárt kivonatot olyan csatornán vigye át, amelyben már bízik, és hasonlítsa össze a teljes tanúsítványt, ne egy ismerősnek tűnő nevet. A tanúsítvánnyal azonos, ellenőrizetlen letöltésből másolt kivonat csak azt bizonyítja, hogy a két fájl megfelel egymásnak. Ez konzisztencia-ellenőrzés, nem identitásellenőrzés, és ez a legcsendesebb módja annak, ahogy ez a terv meggyengül.

A szerveren a kivonat hozzáadása olyan konfigurációváltozás, amely a szokásos kezelőn megy keresztül, és újracsatlakozás követi. Erősítse meg, hogy az új eszköz csatlakozik, és hogy egy eszköz, amelynek a kivonatát eltávolították, már nem csatlakozik. Az a teszt, amely csak a pozitív esetet fedi le, ellenőrizetlenül hagyja az engedélyezési listát, és hat hónap múlva pontosan ebben az állapotban lesz.

A megújítás a drága pillanat

Minden tanúsítvány lejár, és az új tanúsítványnak új kivonata van akkor is, ha a kulcs és a nevek ugyanazok maradnak. Kibocsátó alatt a megújítás átlátható azoknak a partnereknek, amelyek bíznak abban a kibocsátóban; rögzítés alatt bejegyzési esemény minden partner számára, amely rögzíti a tanúsítványt.

Tervezze meg a sorrendet a lejárati dátum előtt, ne utána. Ossza szét az új kivonatot azoknak a feleknek, amelyek ellenőrzik, alkalmazza a változást, és csak azután cserélje ki a tanúsítványt a végponton. Ez a sorrend nem hagy olyan ablakot, amelyben a két fél nem ért egyet abban, melyik tanúsítvány a jelenlegi. Tartsa magát a listát is felülvizsgálat alatt, mert a rögzített lista hónapokkal korábban kivont eszközök bejegyzéseit halmozza fel. Minden elavult bejegyzés olyan identitás, amely még mindig hitelesít, ha a kulcsa túléli, ezért egy eltávolítása biztonsági művelet, nem takarítás.

Amit a bizalmi térkép nem dönt el

A hitelesítés egy réteg, és a rögzített térkép semmit sem mond a címkészletről, a tolt útvonalakról, az útvonal MTU-járól vagy a tűzfal-szabályzatról. Ezek külön konfigurációk maradnak, külön hiba módokkal. Az az alagút, amely hitelesít és nem enged át forgalmat, más vizsgálat, mint amelyik soha nem jön fel.

A térkép sem skálázódik a végtelenségig, és a nagyobb telepítések a kibocsátó-alapú PKI-nál kötnek ki. Ez a preferencia az üzemeltetésről szól, nem a kriptográfiáról, mert az identitások egy hatóságon keresztüli hozzáadása és kivonása olcsóbb, mint a lista szerkesztése minden partnernél, ahogy a flotta nő. Ahol az ügyfél-implementáció nem támogatja ezt az opciót, a válasz egy kompatibilis bizalmi modell, amelyet az az ügyfél dokumentál, vagy egy támogatott helyettesítő. Az ellenőrzési figyelmeztetés elnyomása nem adja hozzá ezt a támogatást, és a terv egész értéke az, hogy az ellenőrzés továbbra is megtörténik.