Šta 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 sačuvani prikaz privatnog ključa kako bi klijent mogao pročitati materijal ključa i upotrijebiti ga za autentifikaciju. Sve što se dogodi nakon toga je drugo 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 pretpostavke su pogrešne, i to na način koji ostavlja vjerodajnicu izloženom dok operator vjeruje da je stvar riješena.

Jedan dijalog, nekoliko različitih tajni

Lozinka privatnog ključa dešifruje datoteku. Lozinka računa vas autentifikuje kod usluge. Lozinka za uvoz PKCS#12 dešifruje 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 je put da ključevi završe zalijepljeni u pogrešno polje.

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

Šta šifrovanje na disku pokriva

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

Slijede dvije posljedice. Slaba lozinka može se napasti van mreže brzinom koju KDF dopušta, pa su dozvole datoteke i pristup sigurnosnim kopijama i dalje važni čak i kada je datoteka šifrovana. 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 šifrovan.

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 šifrovanje; 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. Komanda PKCS#12 takođe vam kaže ima li paket zasebnu MAC ili šifracionu lozinku, što je vrijedno znati prije nego ga predate kolegi.

Šta 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šifruje 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 jezgra, ni sesiju za otklanjanje grešaka priključenu klijentu, ni sigurnosnu kopiju mašine 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 ponovo pita pri svakom ponovnom povezivanju nije nužno pokvaren. Neki klijenti keširaju lozinku za sesiju, neki je čuvaju u ključnom prstenu 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 šifrovanje 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 je obično 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 izdat kroz uobičajeni proces operatora. Svako ko nudi da 'oporavi' lozinku nudi da je pogodi.

Izlaganje zahtijeva drugačiji odgovor. Ponovno šifrovanje istog ključa novom lozinkom ostavlja materijal ključa nepromijenjen, pa kopija koja je već bila otključana negdje drugdje još radi. Popravka 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.