Ko patiesībā aizsargā VPN privātās atslēgas pieejas frāze
Tā aizslēdz failu diskā, nevis strādājošo tuneli vai jūsu konta pieteikšanos. Uzziniet, ko aptver uzvedne, ko ne, un ko darīt, ja tā noplūst.
Uzvedni, kas parādās, kad tiek palaists VPN klients, ir viegli pārprast. Tā nav VPN konta parole, tā nav tuneļa parole, un tās ievadīšana nepierāda, ka savienojums ir drošs. Tā atslēdz vienu saglabātu privātās atslēgas attēlojumu, lai klients varētu nolasīt atslēgas materiālu un izmantot to autentifikācijai. Viss, kas notiek pēc tam, ir cits jautājums.
Praksē atbilde sabrūk malās: cilvēki pieņem, ka frāze aizsargā strādājošo tuneli, vai ka tās maiņa atsauc jau noplūdušas atslēgas kopiju. Abi pieņēmumi neizdodas, un abi neizdodas tā, ka akreditācijas dati paliek atklāti, kamēr operators uzskata, ka jautājums ir atrisināts.
Viens dialogs, vairāki dažādi noslēpumi
Privātās atslēgas pieejas frāze atšifrē failu. Konta parole autentificē jūs pakalpojumā. PKCS#12 importa parole atšifrē pakotni, kurā ir atslēga un tās sertifikāts, un tā var nebūt tā pati virkne kā pašas atslēgas frāze. Šīs uzvednes var izskatīties gandrīz identiskas, un minēšana, kurš noslēpums kur nonāk, ir veids, kā atslēgas nonāk nepareizajā laukā.
Paša tuneļa šifrēšana ir ceturtā lieta. Datu kanāls izmanto sesijas atslēgas, kas sarunātas rokas paspiešanas laikā; privātās atslēgas frāzei nav nekādas lomas atsevišķu pakešu aizsardzībā. Ja kāds var nolasīt atslēgas failu, viņš var mēģināt uzminēt frāzi bezsaistē, bet, ja viņš var nolasīt paketes, frāzei nav nozīmes.
Ko aptver šifrēšana diskā
Šifrētai PEM atslēgai ir divas formas, un galvene pasaka, kura jums ir. Modernā PKCS#8 forma sākas ar -----BEGIN ENCRYPTED PRIVATE KEY-----; vecā PEM forma, kas joprojām bieži sastopama vecākos OpenVPN iestatījumos, sākas ar -----BEGIN RSA PRIVATE KEY----- un satur Proc-Type: 4,ENCRYPTED un DEK-Info rindu tieši zem tās. Fails glabā privāto atslēgu šifrētu ar atslēgu, kas atvasināta no jūsu frāzes, parasti ar paroles balstītu KDF ar norādītu iterāciju skaitu vai darba koeficientu. OpenSSL pkey dokumentācija aptver formātus un frāzes opcijas, kas piemērojamas lasīšanas laikā.
No tā izriet divas sekas. Vāju frāzi var uzlauzt bezsaistē ar ātrumu, ko pieļauj KDF, tāpēc faila atļaujas un piekļuve dublējumiem joprojām ir svarīgas arī tad, ja fails ir šifrēts. Un uzbrucējam, kurš iegūst tikai failu bez frāzes, ir jāmin; tam, kurš iegūst failu un frāzi, ir atslēga, gluži kā tā nekad nebūtu šifrēta.
head -3 vpn.key
openssl pkey -in vpn.key -noout -pubout
openssl pkcs12 -in bundle.p12 -info -noout
head -3 parāda galveni un vecā failā rindas Proc-Type un DEK-Info, kas pierāda šifrēšanu; viena rinda pati par sevi nav pierādījums nevienā virzienā. Rinda pkey prasa frāzi un izdrukā tikai publisko pusi, kas pierāda, ka fails un frāze darbojas neatklājot privāto atslēgu. Neizmantojiet -text šai pārbaudei: tā izdrukā privātās komponentes, privateExponent, prime1, prime2 un pārējo, un šo izvadi nekad nedrīkst nekur ielīmēt, ne biļetē, ne tērzēšanā, ne žurnālā. PKCS#12 komanda arī pasaka, vai pakotnei ir atsevišķa MAC vai šifrēšanas parole, ko ir vērts zināt pirms nodošanas kolēģim.
Ko tā pārstāj aizsargāt pēc atslēgas ielādes
Atslēgšana šim procesam ir vienvirziena notikums. Klients pieprasa atslēgu no KDF, atšifrē failu un tur privāto atslēgu atmiņā tik ilgi, cik nepieciešams. No tā brīža frāze neko neaizsargā strādājošajā sesijā: ne procesa atmiņu, ne kodola izdruku, ne atkļūdošanas sesiju, kas pievienota klientam, ne mašīnas dublējumu, kas veikts atslēgas lietošanas laikā.
Šī ir tā pati robeža kā SSH atslēgai ar frāzi vai atslēgtai paroļu pārvaldnieka glabātuvei. Tā paaugstina faila zādzības miera stāvoklī izmaksas un neko nedara pret ļaunprogrammatūru, kas darbojas kā jūsu lietotājs, autorizētu lietojumprogrammu, kas lūdz klientu parakstīt, vai administratoru, kurš var lasīt atmiņu. Uztveriet to kā vienu slāni, nevis kā kontroli, kas padara atslēgu drošu atstāšanai apkārt.
Kāpēc uzvedne atgriežas atkal un atkal
Klients, kas katrā atkārtotā savienojumā jautā no jauna, nav obligāti bojāts. Daži klienti kešo frāzi sesijai, citi to glabā OS atslēgu saišķī, un vēl citus var novirzīt uz palīgu, kas to piegādā, tāpēc uzvedība ir atkarīga no klienta un tā konfigurācijas, nevis no atslēgas faila.
Ja atkārtotā uzvedne ir īstā sūdzība, pirms šifrēšanas noņemšanas no atslēgas pārbaudiet klienta kešošanas un autentifikācijas opcijas. Frāzes noņemšana pārvērš aizsargātu failu vienkārša teksta atslēgā, un atkārtotais savienojums kļūst kluss uz vienīgās miera stāvokļa kontroles rēķina. Labāka atbilde parasti ir atbalstīta akreditācijas datu glabātuve ar tām pašām faila atļaujām, kuras jūs tik un tā izmantotu.
Zaudējums un atklāšana nav viens un tas pats remonts
Zaudētu frāzi nevar atgūt no sertifikāta. Sertifikāts ir publisks materiāls, kas saista vārdu ar atslēgu; tajā nav ceļa atpakaļ uz privāto atslēgu un nav mājiena par frāzi. Praktiskās iespējas ir autorizēts atslēgas dublējums vai jauna identitāte, kas izsniegta operatora parastajā procesā. Ikviens, kas piedāvā frāzi 'atgūt', piedāvā to uzminēt.
Atklāšana prasa citu reakciju. Tās pašas atslēgas atkārtota šifrēšana ar jaunu frāzi atstāj atslēgas materiālu nemainītu, tāpēc kopija, kas jau atslēgta citur, joprojām darbojas. Remonts ir akreditācijas datu atsaukšana vai aizstāšana: izsniegt jaunu atslēgu un sertifikātu, izplatīt tos un atstādināt veco partnera pusē. Līdz tam faila paroles maiņa ir mājsaimniecība, nevis ierobežošana. Turiet veco failu ārpus dublējumiem tikai pēc tam, kad jaunā identitāte ir apstiprināta kā funkcionējoša, un pierakstiet, kurš sērijas numurs vai pirksta nospiedums to aizstāja.