Što zapravo štiti lozinka na privatnom ključu VPN-a

Upit koji se pojavi kada se VPN klijent pokrene lako je pogrešno pročitati. To nije lozinka VPN računa, nije lozinka za tunel, a njeno unošenje ne dokazuje da je veza sigurna. On otključava jedan spremljeni prikaz privatnog ključa kako bi klijent mogao pročitati materijal ključa i upotrijebiti ga za autentifikaciju. Sve što se dogodi nakon toga drugo je pitanje.

U praksi odgovor pada na rubovima: ljudi pretpostavljaju da lozinka štiti aktivni tunel ili da njena promjena opoziva kopiju ključa koja je već procurila. Obje su pretpostavke pogrešne, i to na način koji ostavlja vjerodajnicu izloženom dok operater vjeruje da je stvar riješena.

Jedan dijalog, nekoliko različitih tajni

Lozinka privatnog ključa dešifrira datoteku. Lozinka računa autentificira vas kod usluge. Lozinka za uvoz PKCS#12 dešifrira paket koji sadrži ključ i njegov certifikat i možda nije isti niz kao vlastita lozinka ključa. Ovi upiti mogu izgledati gotovo identično, a nagađanje koja tajna ide gdje put je da ključevi završe zalijepljeni u pogrešno polje.

Samo šifriranje tunela četvrta je stvar. Podatkovni kanal koristi sesijske ključeve dogovorene tijekom rukovanja; lozinka privatnog ključa nema nikakvu ulogu u zaštiti pojedinačnih paketa. Ako netko može pročitati datoteku ključa, može pokušati pogoditi lozinku izvan mreže, ali ako može čitati pakete, lozinka je nebitna.

Što šifriranje na disku pokriva

Šifrirani PEM ključ dolazi u dva oblika, a zaglavlje vam kaže koji imate. Moderni PKCS#8 oblik počinje s -----BEGIN ENCRYPTED PRIVATE KEY-----; naslijeđeni PEM oblik, još uobičajen u starijim OpenVPN postavkama, počinje s -----BEGIN RSA PRIVATE KEY----- i nosi Proc-Type: 4,ENCRYPTED i red DEK-Info odmah ispod. Datoteka drži privatni ključ šifriran ključem izvedenim iz vaše lozinke, obično kroz KDF zasnovan na lozinki s navedenim brojem iteracija ili faktorom rada. OpenSSL pkey dokumentacija pokriva formate i opcije lozinke koje vrijede pri čitanju.

Slijede dvije posljedice. Slaba lozinka može se napasti izvan mreže brzinom koju KDF dopušta, pa su dozvole datoteke i pristup sigurnosnim kopijama i dalje važni čak i kada je datoteka šifrirana. A napadač koji dobije samo datoteku bez lozinke mora nagađati; onaj koji dobije datoteku i lozinku ima ključ, baš kao da nikada nije bio šifriran.

head -3 vpn.key
openssl pkey -in vpn.key -noout -pubout
openssl pkcs12 -in bundle.p12 -info -noout

head -3 prikazuje zaglavlje, a na naslijeđenoj datoteci redove Proc-Type i DEK-Info koji dokazuju šifriranje; jedan red sam po sebi nije dokaz ni u jednom smjeru. Red pkey traži lozinku i ispisuje samo javnu polovinu, što dokazuje da datoteka i lozinka rade bez otkrivanja privatnog ključa. Ne koristite -text za tu provjeru: on ispisuje privatne komponente, privateExponent, prime1, prime2 i ostalo, a taj se izlaz nikada ne smije zalijepiti bilo gdje, ni u tiket, ni u chat, ni u dnevnik. Naredba PKCS#12 također vam kaže ima li paket zasebnu MAC ili šifriranu lozinku, što je vrijedno znati prije nego ga predate kolegi.

Što prestaje štititi nakon što se ključ učita

Otključavanje je jednosmjerni događaj za taj proces. Klijent traži ključ od KDF-a, dešifrira datoteku i drži privatni ključ u memoriji koliko mu god treba. Od tog trenutka lozinka ne štiti ništa u aktivnoj sesiji: ni memoriju procesa, ni dump jezgre, ni sesiju za otklanjanje pogrešaka priključenu klijentu, ni sigurnosnu kopiju stroja napravljenu dok je ključ bio u upotrebi.

To je ista granica kao kod SSH ključa s lozinkom ili otključanog trezora upravitelja lozinkama. Podiže cijenu krađe datoteke u mirovanju i ne čini ništa protiv zlonamjernog softvera koji radi kao vaš korisnik, ovlaštene aplikacije koja traži od klijenta da potpiše, ili administratora koji može čitati memoriju. Tretirajte to kao jedan sloj, a ne kao kontrolu koja ključ čini sigurnim za ostavljanje unaokolo.

Zašto se upit stalno vraća

Klijent koji ponovno pita pri svakom ponovnom povezivanju nije nužno pokvaren. Neki klijenti keširaju lozinku za sesiju, neki je čuvaju u privjesku ključeva OS-a, a neki se mogu usmjeriti na pomoćnika koji je dostavlja, pa koje ponašanje dobijete zavisi od klijenta i njegove konfiguracije, a ne od datoteke ključa.

Ako je ponovljeni upit stvarna žalba, pregledajte opcije keširanja i autentifikacije klijenta prije nego uklonite šifriranje s ključa. Uklanjanje lozinke pretvara zaštićenu datoteku u ključ otvorenog teksta, a ponovno povezivanje postaje tiho po cijeni jedine kontrole u mirovanju koju ste imali. Bolji odgovor obično je podržano spremište vjerodajnica s istim dozvolama datoteke koje biste ionako koristili.

Gubitak i izlaganje nisu ista popravka

Izgubljena lozinka ne može se oporaviti iz certifikata. Certifikat je javni materijal koji veže ime za ključ; ne sadrži put natrag do privatnog ključa ni nagovještaj o lozinci. Praktične opcije su ovlaštena sigurnosna kopija ključa ili novi identitet izdan kroz uobičajeni proces operatera. Svatko ko nudi da 'oporavi' lozinku nudi da je pogodi.

Izlaganje zahtijeva drugačiji odgovor. Ponovno šifriranje istog ključa novom lozinkom ostavlja materijal ključa nepromijenjen, pa kopija koja je već bila otključana negdje drugdje još radi. Popravak je opozvati ili zamijeniti vjerodajnicu: izdati novi ključ i certifikat, distribuirati ih i povući stari kod partnera. Dok se to ne dogodi, promjena lozinke datoteke je kućno održavanje, a ne obuzdavanje. Držite staru datoteku izvan sigurnosnih kopija tek nakon što se potvrdi da novi identitet radi, i zabilježite koji je serijski broj ili otisak zamijenio.