Egy OpenVPN-profil három tanúsítványblokkot tartalmaz: melyik titkos?

Megnyit egy .ovpn-fájlt, hogy egy sort módosítson, és három base64-blokkot talál, amelyek mind hitelesítő adatoknak tűnnek. Az egyiket biztonságos közzétenni, a másik olyan érzékeny, mint egy jelszó, a harmadik pedig nyilvános kulcs, amely semmit nem jelent, ha valami más nem írt alá a párjával. Az emberek az egész fájlt beillesztik egy támogatási szálba, mert a blokkok felcserélhetőnek tűnnek, és így kerül egy ügyfélkulcs nyilvános archívumba. Annak tisztázása, melyik blokk mit tesz, megmagyarázza a profilok körüli zavar nagy részét, és megmondja azt is, mely hibákat kell Önnek javítania.

Egy fájl, három blokk, különböző feladatok

Egy tipikus profil ca-blokkot, cert-blokkot és key-blokkot ágyaz be a BEGIN és END jelölők közé, vagy ugyanarra a háromra külön fájlként hivatkozik. Egyes profilok negyedik blokkot adnak hozzá tls-auth vagy tls-crypt kulcshoz, amely megosztott titok, nem tanúsítvány. Az ügyfél minden blokkot az azt megnevező direktíva szerint olvas, ezért a címkék fontosabbak, mint a megjelenési sorrend.

Kezelje az összeállított profilot érzékenyként, amíg valóban bele nem nézett. Egy nyilvános tanúsítvány és egy privát kulcs néhány sor távolságra lehet ugyanabban a fájlban, és egy fejlécet is tartalmazó képernyőkép mindkettőt tartalmazhatja. A látható base64 kézi kitakarása sem megbízható, mert egy részleges blokk is kiszivárogtatja a telepítését megnevező tanúsítvány-metaadatokat. A három direktíva értékek nélküli átmásolása általában elég egy hasznos kérdéshez.

A blokkok körüli direktívák döntik el, hogyan használják őket. Módosítsa a ca-t, és az ügyfél más hatóságban bízik; módosítsa a cert-et a key változtatása nélkül, és a kézfogás olyan eltéréssel hiúsul meg, amelynek semmi köze a bizalomhoz.

A CA-blokk nyilvános, a CA-kulcs soha

Egy tanúsítványhatóság olyan tanúsítványokat ír alá, amelyek nyilvános kulcsot kötnek identitáshoz, saját tanúsítványa pedig az a horgony, amely alapján az ügyfél eldönti, hogy egy lánc megbízható-e. Ez a tanúsítvány tervezésénél fogva nyilvános: minden profilba belepakolni normális, és éppen ezért működhet egy önaláírt telepítés kereskedelmi hatóság nélkül.

Ami soha nem jelenhet meg ügyfélprofilban, az a hatóság privát aláírókulcsa. Az ügyfélnek semmi ellenőrzéshez nincs rá szüksége, jelenléte pedig azt jelenti, hogy a profil birtokosa új identitásokat verhet az egész telepítés számára.

A hatóságba vetett bizalom is szűkebb, mint amilyennek hangzik. Az az ügyfél, amely elfogad bármilyen CA által aláírt tanúsítványt, továbbra is elfogad egy ugyanazon CA-n más szolgáltatásnak kiállított tanúsítványt. A várt kiszolgálószerepet vagy -nevet rögzítő beállítások bezárják ezt a rést, és a TLS-beállítások referenciája felsorolja azokat az ellenőrző direktívákat, amelyek ezt teszik.

A kiszolgáló- és az ügyféltanúsítvány ellentétes irányba mutat

A kiszolgáló tanúsítványa az, amit az ügyfél megvizsgál, hogy megbizonyosodjon a helyes végpont eléréséről. Az Ön ügyféltanúsítványa fordítva működik: a kiszolgáló azt használja annak eldöntésére, hogy ez az eszköz vagy felhasználó az általa felvett. Ugyanaz a formátum, ellentétes bizalmi irány.

A cím nem identitás. A helyes IP elérése semmit nem bizonyít arról, ki válaszolt, ezért a hosztnév vagy a tanúsítványnév ellenőrzése továbbra is a profilhoz tartozik. A fiókjelszó sem váltja fel csendben az előírt ügyféltanúsítványt, mert a kettőt különböző szakaszban ellenőrzik, és egy telepítés mindkettőt megkövetelheti.

Az ügyfél privát kulcsa az a rész, amelynek privátnak kell maradnia. Ha kiderülhetett, a fájl törlése a laptopjáról semmit nem változtat a kiszolgálón, amely továbbra is elfogadja a megfelelő tanúsítványt, amíg az üzemeltető vissza nem vonja. Az üzemeltető megkérése ezen identitás cseréjére vagy visszavonására az egyetlen megoldás, amely Önnel utazik.

Két kérés, amely azonosnak látszik és nem az

A titkosított formában tárolt kulcs jelmondatot kér, mielőtt az ügyfél használhatná. A VPN-szolgáltatás külön kérhet fiókjelszót, és a két kérés másodpercek különbséggel, szinte ugyanazzal a szöveggel jelenhet meg. A jelmondat egy fájlt véd a lemezen; a jelszó egy fiókot igazol egy kiszolgáló felé. Összekeverésük olyan jelszó-visszaállításokhoz küldi az embereket, amelyek semmiképpen nem segíthetnek.

Olvassa el a kérést, mielőtt bármit visszaállítana. A fiókjelszó visszaállítása semmit nem tesz egy elfelejtett kulcs-jelmondatért, egy visszavont vagy lejárt tanúsítványért, és a jelszó visszaállítása akkor, amikor a hiba tanúsítvány-ellenőrzés, kétperces javításból támogatási esetet csinál. Ha a panasz érvényességi dátumokat említ, először az eszköz óráját ellenőrizze, aztán a megnevezett tanúsítvány saját ablakát.

Amikor a tanúsítvány valóban lejárt, a cserének attól kell jönnie, aki kiállította. Egy másvalakihez tartozó kulcs nem megújítási út, és egy működő profil kölcsönzése egy kollégától sem az.

Mit bizonyít egy tiszta kézfogás és mit nem

Egy befejezett TLS-kézfogás elérése azt jelenti, hogy a beállított identitáskapcsolat tartott: a kiszolgáló tanúsítványa az Ön CA-jához láncolódott, és a tanúsítványát elfogadták. Ez semmit nem mond az üzemeltető naplózási politikájáról, és arról sem, hogy az alkalmazásai működni fognak-e, amikor az alagút feláll.

Az útvonalak és a DNS a kapcsolat későbbi szakaszai, ezért egy sikeres bejelentkezés után elérhetetlen intranet-gazdagép kapcsolódási probléma, nem tanúsítványprobléma. Ezen a rétegen dolgozzon a hitelesítő adatok cseréje helyett, és tartsa együtt a profil eredetét, privát anyagát és identitásellenőrzéseit, amikor átadja valakinek.