Mida VPN-i privaatvõtme paroolfraas tegelikult kaitseb
See lukustab faili kettal, mitte töötava tunnelit ega teie konto sisselogimist. Uurige, mida viip katab, mida mitte, ja mida teha, kui see lekib.
VPN-i kliendi käivitamisel ilmuvat viipa on lihtne valesti lugeda. See ei ole VPN-i konto parool, see ei ole tunneli parool, ja selle sisestamine ei tõesta, et ühendus on turvaline. See avab ühe salvestatud privaatvõtme esituse, et klient saaks võtmematerjali lugeda ja seda autentimiseks kasutada. Kõik, mis pärast seda juhtub, on teine küsimus.
Praktikas läheb vastus valesti äärtes: inimesed eeldavad, et paroolfraas kaitseb töötavat tunnelit, või et selle muutmine tühistab juba lekkima hakanud võtme koopia. Mõlemad eeldused ebaõnnestuvad ja mõlemad ebaõnnestuvad nii, et volitus jääb paljastatuks, samal ajal kui operaator usub, et see on käsitletud.
Üks dialoog, mitu erinevat saladust
Privaatvõtme paroolfraas dekrüpteerib faili. Konto parool autendib teid teenuses. PKCS#12 impordi parool dekrüpteerib paketi, mis sisaldab võtit ja selle sertifikaati, ja see ei pruugi olla sama string kui võtme enda paroolfraas. Need viibad võivad tunduda peaaegu identsed, ja arvamine, milline saladus kuhu kuulub, viib selleni, et võtmed kleebitakse valesse välja.
Tunneli enda krüpteerimine on neljas asi. Andmekanal kasutab kätlemise ajal kokku lepitud sessioonivõtmeid; privaatvõtme paroolfraasil ei ole üksikute pakettide kaitsmisel mingit rolli. Kui keegi saab võtmefaili lugeda, võib ta paroolfraasi võrguühenduseta ära arvata, kuid kui ta saab pakette lugeda, on paroolfraas ebaoluline.
Mida kettal olev krüpteerimine katab
Krüpteeritud PEM-võti on kahes vormis ja päis ütleb, milline teil on. Kaasaegne PKCS#8 vorm algab -----BEGIN ENCRYPTED PRIVATE KEY-----; vanem PEM-vorm, mis on endiselt levinud vanemates OpenVPN-i seadistustes, algab -----BEGIN RSA PRIVATE KEY----- ning sisaldab Proc-Type: 4,ENCRYPTED ja vahetult selle all rida DEK-Info. Fail hoiab privaatvõtit krüpteeritult teie paroolfraasist tuletatud võtme all, tavaliselt paroolipõhise KDF-i kaudu, millel on märgitud iteratsioonide arv või töötegur. OpenSSL pkey dokumentatsioon katab vormingud ja paroolfraasi valikud, mis kehtivad lugemisel.
Sellest tuleneb kaks tagajärge. Nõrka paroolfraasi saab võrguühenduseta rünnata KDF-i lubatud kiirusel, seega failiõigused ja juurdepääs varukoopiatele on olulised ka siis, kui fail on krüpteeritud. Ja ründaja, kes saab ainult faili ilma paroolfraasita, peab arvama; see, kes saab faili ja paroolfraasi, omab võtit, täpselt nagu poleks seda kunagi krüpteeritud.
head -3 vpn.key
openssl pkey -in vpn.key -noout -pubout
openssl pkcs12 -in bundle.p12 -info -noout
head -3 näitab päist ja vanemal failil ridu Proc-Type ja DEK-Info, mis tõestavad krüpteerimist; üks rida üksi ei ole tõend kummaski suunas. Rida pkey küsib paroolfraasi ja prindib ainult avaliku poole, mis tõestab, et fail ja paroolfraas töötavad privaatvõtit paljastamata. Ärge kasutage selleks kontrolliks -text: see prindib privaatsed komponendid, privateExponent, prime1, prime2 ja ülejäänu, ning seda väljundit ei tohi kunagi kuhugi kleepida, ei piletisse, vestlusesse ega logisse. PKCS#12 käsk ütleb teile ka, kas paketil on eraldi MAC- või krüpteerimisparool, mida tasub teada enne, kui annate selle kolleegile.
Mida see lakkab kaitsmast, kui võti on laaditud
Avamine on selle protsessi jaoks ühesuunaline sündmus. Klient küsib KDF-ilt võtit, dekrüpteerib faili ja hoiab privaatvõtit mälus nii kaua, kui seda vajab. Sellest hetkest ei kaitse paroolfraas töötava sessiooni juures mitte midagi: ei protsessi mälu, ei tuuma dumpi, ei kliendiga ühendatud silumissessiooni ega masina varukoopiat, mis tehti võtme kasutamise ajal.
See on sama piir nagu paroolfraasiga SSH-võtmel või paroolihalduri avatud hoidlal. See tõstab kettal oleva faili varguse hinda ega tee midagi teie kasutajana jooksva pahavara, kliendilt allkirjastamist paluva volitatud rakenduse ega mälu lugeda suutva administraatori vastu. Käsitlege seda ühe kihina, mitte kontrollina, mis muudab võtme ohutuks selle vedelema jätmiseks.
Miks viip üha tagasi tuleb
Klient, kes küsib igal taasühendusel uuesti, ei ole tingimata katki. Mõned kliendid vahemällu salvestavad paroolfraasi sessiooni jaoks, mõned hoiavad seda OS-i võtmehoidlas ja mõnda saab suunata abilisele, mis selle edastab, seega sõltub käitumine kliendist ja selle konfiguratsioonist, mitte võtmefailist.
Kui korduv viip on tegelik kaebus, uurige kliendi vahemälu- ja autentimisvalikuid enne, kui eemaldate võtmelt krüpteerimise. Paroolfraasi eemaldamine muudab kaitstud faili lihttekstiliseks võtmeks ja taasühendus muutub vaikseks teie ainsa kettal oleva kontrolli arvelt. Parem vastus on tavaliselt toetatud volituste hoidla samade failiõigustega, mida te muidu kasutaksite.
Kaotus ja paljastumine ei ole sama parandus
Kaotatud paroolfraasi ei saa sertifikaadist taastada. Sertifikaat on avalik materjal, mis seob nime võtmega; see ei sisalda teed tagasi privaatvõtme juurde ega vihjet paroolfraasi kohta. Praktilised valikud on võtme volitatud varukoopia või operaatori tavapärase protsessi kaudu välja antud uus identiteet. Igaüks, kes pakub paroolfraasi 'taastamist', pakub selle äraarvamist.
Paljastumine nõuab teistsugust vastust. Sama võtme uuesti krüpteerimine uue paroolfraasiga jätab võtmematerjali muutumatuks, seega mujal juba avatud koopia töötab endiselt. Parandus on volituse tühistamine või asendamine: andke välja uus võti ja sertifikaat, levitage neid ja võtke vana partneri juures kasutusest välja. Kuni see juhtub, on faili parooli muutmine majapidamine, mitte tõkestamine. Hoidke vana fail varukoopiatest väljas alles pärast seda, kui uus identiteet on kinnitatud töötavana, ja kirjutage üles, milline seerianumber või sõrmejälg selle asendas.