Önaláírt VPN-tanúsítvány: mit jelent, és miben bízik

Itt két hit okozza a legtöbb kárt: hogy az önaláírt VPN-tanúsítvány azt jelenti, az alagút nincs titkosítva, és hogy az telepítése, amit a VPN-kliens kért, csak a VPN-re hat. Egyik sem éli túl a valódi bevezetéssel való érintkezést. Az önaláírt tanúsítvány aláírási viszonyt ír le, nem biztonsági ítéletet, és a hozzáadott bizalom hatóköre attól függ, melyik tárolóba kerül. Láttam, amint egy ügyfélszolgálat egy szolgáltatói gyökeret importált egy Windows-gépbe, hogy elhallgattasson egy figyelmeztetést, majd egy délutánt azzal töltött, hogy elmagyarázza, miért hagyta abba a böngésző a panaszt egy független portál miatt. A kérdés két fele együtt tartozik, ezért kezelje őket egyként.

A tanúsítvány nem bizalmi tároló

A kiszolgáló által bemutatott fájl nyilvános kulcsot, tárgynavat, kiállítónavat, érvényességi dátumokat és kiterjesztéseket hordoz. Az önaláírt azt jelenti, hogy a tárgy és a kiállító ugyanaz az entitás, és az aláírást a tanúsítvány saját kulcsa ellenőrzi. Semmi ebben a meghatározásban nem mondja, hogy a kapcsolat gyenge, és semmi nem mondja, hogy a kliens elfogadja.

Az elfogadás máshonnan jön: egy CA-fájlból, amelyre a klienst irányítja, egy ujjlenyomatból, amelyet kézzel hasonlít össze, vagy egy gyökérből, amely már egy olyan tárolóban van, amelyet a kliens olvas. Egy bevezetés tökéletesen egészséges lehet, miközben a tanúsítványa minden nyilvános teszten elbukna. A openssl verify a rendszercsomag ellen ismeretlen kiállítót jelent, és ez a jelentés helyes, nem hiba.

Az OpenVPN ca opciója az alkalmazáshoz kötött bizalom legvilágosabb esete. Ez a fájl megnevezi azokat a horgonyokat, amelyeket a kliens elfogad, és tartalmazhat egy privát CA-t vagy kis bevezetés esetén a kiszolgáló saját önaláírt tanúsítványát. A 2.6-os verzió a CA-fájl terjesztése helyett --peer-fingerprint-t is elfogad SHA-256 ujjlenyomat rögzítéséhez. A WireGuard még távolabb áll: egyáltalán nincsenek tanúsítványai, csak egy statikus nyilvános kulcs társanként, ezért az önaláírás kérdése nem vonatkozik rá.

A bizalom telepítési helye dönti el, ki örökli

Tegye ugyanazt a tanúsítványt három helyre, és három különböző robbanási sugarat kap. A csak a VPN-kliens által olvasott csomag azt a klienst érinti. A rendszer tárolójában lévő gyökér minden programot érint, amely ehhez a tárolóhoz fordul. Egy saját bizalmi adatbázissal rendelkező böngésző mindkettőt figyelmen kívül hagyhatja, ezért élhet túl egy figyelmeztetés egy működőnek tűnő importot.

Debianon vagy Ubuntun a fájl /usr/local/share/ca-certificates/-ba helyezése és a update-ca-certificates futtatása megváltoztatja a rendszerszintű csomagot. Windowson a certutil -addstore -f Root a gép tárolójába ír, és emelt parancssort igényel, míg a -user hozzáadása inkább az aktuális felhasználó tárolóját célozza; a kettő nem felcserélhető. A Firefox saját NSS-adatbázist tart, ezért az operációsrendszer-szintű import ott soha nem jelenhet meg.

A hatókör azért számít, amit egy hatóság tehet. Egy kiállító CA olyan nevekre írhat alá, amelyekhez semmi köze, ezért minden, ami abban a tárolóban bízik, elfogadja ezeket az aláírásokat. Egyetlen rögzített levél ezt nem teheti; pontosan egy társ-identitást hitelesít. Ha a cél egy VPN csatlakoztatása, egy alkalmazáshoz kötött CA vagy egy rögzített levél eléri ezt, míg a gép szintű gyökér sokkal nagyobb engedmény, mint amit a tünet megkíván.

Még mindig titkosít nyilvános CA nélkül

A TLS-kézfogás munkamenet-kulcsokat származtat, akár láncolódik a társ tanúsítványa valamihez, amiben már bízik, akár nem. Az önaláírt nem jelent nyílt szöveget, és nem jelenti, hogy a forgalom repülés közben olvasható. Azt jelenti, hogy a kliensnek nincs eleve oka hinni, hogy a kulcs ahhoz a kiszolgálóhoz tartozik, amelyet kért.

Ebben a résben élnek a valódi támadások. Egy kliens, amelyet bármely tanúsítvány elfogadására állítottak be, akár letiltott ellenőrzési beállítással, akár egy egyszer megnyomott és elfelejtett „bízzon meg mégis” gombbal, boldogan titkosít annak, aki válaszol. Az elfogás a hitelesítési lépésben történik, mielőtt az alkalmazásadatok elmozdulnának. Az identitásellenőrzés nélküli titkosítás kint tartja a passzív megfigyelőt, és kevés mást tesz.

A kiállítóban való bizalom nem hagyja ki a névellenőrzést

A láncérvényesítés, a név egyeztetése és a tanúsítvány célja külön döntések. A lánc érvényes lehet, miközben a név rossz, és a név egyezhet, miközben a tanúsítványt más szerepre állították ki. Az RFC 5280 definiálja az ezeket a korlátokat hordozó mezőket, és hogy egy kliens milyen szigorúan kényszeríti ki őket, az alkalmazásonkénti kérdés.

Az OpenVPN láthatóvá teszi a szétválasztást. A verify-x509-name a name, name-prefix vagy subject egyeztetésén keresztül rögzíti az elvárt tárgyat. A remote-cert-tls server megköveteli, hogy a társ tanúsítványa kiszolgálói tanúsítványként használható legyen, ami elutasítja a csak kliens tanúsítványt akkor is, ha a kiállító megbízható. Egyik beállítást sem helyettesíti CA-fájl küldése.

Vizsgálja meg a tanúsítványt, mielőtt bármit eldönt:

• openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName megmutatja, ki állította ki, mely nevekre és meddig.
• openssl verify -CAfile ca.crt server.crt ellenőrzi, hogy a küldeni kívánt lánc valóban érvényesíti-e a levelet.
• openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -CAfile ca.crt -verify_return_error TLS-végpontokhoz működik, például webes portálhoz; az OpenVPN protokoll az 1194-es porton nem sima TLS-folyam, ezért az a teszt ott nem alkalmazható.

A lejárt dátumú, a csatlakozási névhez subjectAltName nélküli vagy a serverAuth használatát nélkülöző tanúsítvány elbukik, függetlenül attól, milyen gondosan telepítették a horgonyt.

Öt ellenőrzés, mielőtt elfogad egyet

Hasonlítsa össze az ujjlenyomatot olyan csatornán, amely nem az a kapcsolat, amelyet javítani próbál: konzol, egy már meglévő telepítő, egy aláírt konfigurációs fájl. A kiszolgálón a openssl x509 -in server.crt -noout -fingerprint -sha256 és ugyanaz az érték a kliens naplójában elég ahhoz, hogy tudja, egyetlen objektumot néz.

Ezután döntse el, mit telepít: egy levelet vagy egy hatóságot, amely többet verhet. Aztán döntse el, hová kerül, és nevezze meg azokat az alkalmazásokat, amelyek azt a tárolót olvassák. Írja fel az eltávolítási útvonalat, amíg még emlékszik rá, mert a bízz-és-tovább így teszi állandóvá az ideiglenes importot.

Végül tervezze meg a változást. A rögzített tanúsítványt vagy ujjlenyomatot ugyanazon megbízható csatornán kell frissíteni, amikor a tanúsítvány cserélődik, és a privát CA-nak saját kiállítási és visszavonási életciklusa van. Ha a privát kulcs kiszivárog, ugyanazon tanúsítvány másolatában való újrabizalom semmit nem javít; az identitást le kell cserélni.

Ha egy figyelmeztetés túléli mind az öt ellenőrzést, a hasznos kérdés nem az, melyik gomb hallgattatja el, hanem hogy melyik tárolót olvassa a kliens valójában, és honnan jött az a gyökér. Válaszoljon erre, és a hamarosan végrehajtandó import döntéssé válik reflex helyett.