Megosztható a VPN nyilvános kulcs? Három dolgot érdemes ellenőrizni

Odaadhatod a VPN nyilvános kulcsodat egy partnernek, egy szolgáltatónak vagy egy fórumnak, és az alagút továbbra is működik. A privát kulcsot viszont nem adhatod át, még az ügyfélszolgálatnak sem, anélkül, hogy átadnád azt az identitást, amelyet az a kulcs igazol. A döntés ritkán marad ilyen egyszerű, mert az emberek összekeverik, hogy a pár melyik felét nézik, és mert egyes telepítések a nyilvános értéket névként kezelik. Három ellenőrzés dönti el: melyik feled van meg, mihez köti a telepítés, és mennyibe kerül a csere.

Első ellenőrzés: a pár melyik fele van a vágólapodon

Az aszimmetrikus kulcsok párban jönnek, és a levezetés iránya az egész lényeg. A WireGuardban a privát kulcs 32 véletlen bájt, a nyilvános kulcsot pedig ebből számítják ki; visszafelé nem lehet. wg genkey írja a privát értéket, wg pubkey származtatja a nyilvánosat, és csak a második való egy partnernek küldött üzenetbe.

wg genkey | tee private.key | wg pubkey > public.key
chmod 600 private.key
openssl x509 -noout -pubkey -in server.crt

A tanúsítványok világa ugyanezt a kettősséget használja, több mozgó alkatrésszel. Egy szervertanúsítvány nyilvános kulcsot és neveket tartalmaz, és egy olyan CA privát kulcs írja alá, amely soha nem hagyja el a CA-t. Az a kliens, amelyik ellenőrzi a szervert, a CA tanúsítványát igényli, ami nyilvános, és semmire sem használja a CA privát aláíró kulcsát.

Ha bizonytalan vagy, melyik értéket tartod a kezedben, a jelölőt nézd, ne a fájlnevet. A -----BEGIN PRIVATE KEY----- jelöléssel kezdődő PEM blokk vagy a régebbi BEGIN RSA PRIVATE KEY forma a titkos fél. Az az érték, amelyet e jelölő nélkül be tudsz illeszteni, megosztásra alkalmas jelölt, a következő két ellenőrzés függvényében.

Második ellenőrzés: mihez köti a telepítés azt a nyilvános értéket

A kriptográfiai biztonság és az anonimitás különböző tulajdonságok. Egy WireGuard partner nyilvános kulcsa stabil azonosító a telepítésen belül: a szerver konfigurációja felsorolja, a kézfogás megnevezi, és a naplókat olvasó adminisztrátor minden alkalommal ugyanazt a karakterláncot látja, amikor az a partner csatlakozik. Ha a kulcsot a beállításodra vonatkozó kérdés mellé teszed ki, ezt a karakterláncot összekapcsoltad minden mással, ami a bejegyzésben van.

A tanúsítványok tervezésüknél fogva felfedik az identitást. A subject és a subject alternative name mezők olvashatók, a nyilvánosan megbízható TLS-tanúsítványok esetében pedig maga a tanúsítvány bekerül a Certificate Transparency naplókba, amelyek kereshetők. Mindez nem tár fel privát kulcsot, viszont feltár egy kapcsolatot.

Itt térnek el a telepítések, és ez dönti el a választ. Egy laboratóriumi szerver eldobható teszt-partnere más objektum, mint egy vállalat telephelyek közötti végpontját azonosító kulcs, még ha a bájtok ugyanúgy is néznek ki.

Harmadik ellenőrzés: mit lehet visszavonni, és milyen gyorsan

A harmadik ellenőrzés teljesen szétválasztja a két felet. Egy nyilvános kulcs, amelyet közzétettek, ütemezésed szerint cserélhető. Egy privát kulcs, amelyet közzétettek, nem hívható vissza: a saját példányod törlése nem érinti a már megszerzett példányokat, és minden partner, amely megbízott benne, most olyanban bízik, ami egy kívülállónál van.

A visszavonás konfigurációs művelet, nem kriptográfiai. A WireGuard nem szállít visszavonási listát, ezért eltávolítod a partnert:

wg set wg0 peer <peer-public-key> remove
# then delete the [Peer] block from the config so it does not return on restart

OpenVPN tanúsítványokra épülő telepítései visszavonják a tanúsítványt, és közzétesznek egy CRL-t, amelyet a szerver ténylegesen ellenőriz a crl-verify direktíván keresztül. E direktíva nélkül a visszavonási lista csak díszlet. Mindkét esetben a sorrend ugyanaz: adj ki cserét, oszd szét a támogatott csatornán, majd vond vissza a régi identitást.

A hibák, amelyek a három ellenőrzés összemosásából származnak

A legtöbb valódi szivárgás nem abból fakad, hogy valaki úgy dönt, közzéteszi a privát kulcsot. Hanem abból, hogy egy egész profil kerül be egy fórumba: egy WireGuard .conf, amelyben PrivateKey sor van, egy .ovpn csomag beágyazott kulcsblokkal, vagy egy kliensablak képernyőképe, amely véletlenül tartalmazza a kulcsmezőt. A nyilvános érték valószínűleg rendben volt; azzal a résszel utazott, amelyik nem.

Az ügyfélszolgálati folyamatok a második forrás. Egyetlen legitim ellenőrzési lépésnek sincs szüksége a privát kulcsodra, mert a másik fél a nyilvános félből vezeti le, amire szüksége van. Amikor egy űrlap vagy egy személy a privát értéket kéri, a helyes válasz a nyilvános érték plusz a helyi parancs, amely előállítja.

A naplók és a képernyőképek ugyanebbe a kategóriába tartoznak. A diagnosztikai kimenet kulcsanyagot, munkamenet-azonosítókat és belső címeket hordozhat, és ha mindezt közzéteszed egyetlen kérdés megválaszolásáért, kis kényelmet cserélsz nagyobb kitettségre.

Miután egy privát érték kiszivárgott, vonulj vissza az identitást

Ha egy privát érték mégis kijutott, tekintsd azt az identitást visszavonultnak. Hozz létre egy új párt, telepítsd a nyilvános felét oda, ahol a partnerek várják, távolítsd el a régi partnert vagy vond vissza a régi tanúsítványt, és ellenőrizd azokat a helyeket, ahol közzétetted. A nem általad ellenőrzött példányokat nem tudod törölni, így az eltávolítás a jövőről szól, nem a múltról.

Aztán írd le a terjesztést: melyik kulcs melyik eszközhöz tartozik, kinél van példány, hogyan jut el a csere, és ki távolítja el a visszavonult partnert. Ezeket szokták elfelejteni, és ezek döntik el, meddig marad hasznos egy szivárgás.