Wat in wachtwurd op in VPN-privekaai eins beskermet

De prompt dy't ferskynt as in VPN-klant starts is maklik ferkeard te lêzen. It is net it wachtwurd fan it VPN-account, it is net it wachtwurd foar de tunnel, en it ynfieren derfan bewiist net dat de ferbining feilich is. It ûntslút ien bewarre foarstelling fan in privekaai, sadat de klant it kaaimateriaal lêze kin en it foar autentikaasje brûke kin. Alles wat dêrnei bart is in oare fraach.

Yn 'e praktyk giet it antwurd oan 'e rânen mis: minsken nimme oan dat it wachtwurd de rinnende tunnel beskermet, of dat it feroarjen derfan in kopy fan 'e kaai weromlûkt dy't al lekke is. Beide oannames mislearje, en se mislearje op in manier dy't in bewijs fan identiteit bleatleit wylst de operator tinkt dat it regele is.

Ien dialooch, ferskate geheimen

In wachtwurd foar in privekaai ûntsiferet in bestân. In accountwachtwurd autentisearret dy by in tsjinst. In PKCS#12-ymportwachtwurd ûntsiferet in bondel mei in kaai en syn sertifikaat, en it is miskien net deselde string as it eigen wachtwurd fan 'e kaai. Dizze prompts kinne hast identyk lykje, en riede hokker geheim wêr heart is hoe't kaaien yn it ferkearde fjild belande.

De eigen fersifering fan 'e tunnel is in fjirde ding. It datakaniel brûkt sesjekaaien dy't by de hânskutling ôfpraat wurde; it wachtwurd fan 'e privekaai spilet gjin rol by it beskermjen fan yndividuele pakketten. As immen it kaaibestân lêze kin, kin dy it wachtwurd offline besykje te rieden, mar as dy pakketten lêze kin, is it wachtwurd net relevant.

Wat de fersifering op skiif beslacht

In fersifere PEM-kaai komt yn twa foarmen, en de kop fertelt hokker jo hawwe. De moderne PKCS#8-foarm begjint mei -----BEGIN ENCRYPTED PRIVATE KEY-----; de âldere PEM-foarm, noch gewoan yn âldere OpenVPN-ynstellingen, begjint mei -----BEGIN RSA PRIVATE KEY----- en hat Proc-Type: 4,ENCRYPTED en in DEK-Info-rigel direkt dêrûnder. It bestân hâldt de privekaai fersifere ûnder in kaai dy't fan jo wachtwurd ôflaat is, meastentiids fia in wachtwurd-basearre KDF mei in oanjûn oantal iteraasjes of wurkfaktor. De OpenSSL pkey-dokumintaasje beslacht de formaten en de wachtwurdopsjes dy't jilde by it lêzen.

Dêr folgje twa gefolgen út. In swak wachtwurd is offline oan te fallen tsjin it tempo dat de KDF tastiet, dus bestânsrjochten en tagong ta back-ups bliuwe wichtich sels as it bestân fersifere is. En in oanfaller dy't allinnich it bestân sûnder it wachtwurd krijt moat riede; ien dy't it bestân en it wachtwurd krijt hat de kaai, krekt as wie it nea fersifere.

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

head -3 lit de kop sjen en, op in âlder bestân, de rigels Proc-Type en DEK-Info dy't fersifering bewize; ien rigel allinnich is gjin bewiis yn ien fan beide rjochtingen. De pkey-rigel freget om it wachtwurd en printsje allinnich de iepenbiere helte, wat bewize dat it bestân en it wachtwurd wurkje sûnder de privekaai bleat te lizzen. Brûk -text net foar dy kontrôle: it printsje de privee komponinten, privateExponent, prime1, prime2 en de rest, en dy útfier mei nea earne plakt wurde, net yn in ticket, in chat of in log. It PKCS#12-kommando fertelt jo ek of de bondel in apart MAC- of fersiferingswachtwurd hat, wat witten wurdich is foardat jo it oan in kollega jouwe.

Wat it ophâldt te beskermjen as de kaai laden is

Untsluten is in ienrjochting-evenemint foar dat proses. De klant freget de KDF om 'e kaai, ûntsiferet it bestân en hâldt de privekaai yn it ûnthâld sa lang as it dy nedich hat. Fan dat momint ôf beskermet it wachtwurd neat oan 'e rinnende sesje: net it prosesûnthâld, net in kearndump, net in debugsesje oan 'e klant, en net in back-up fan 'e masine makke wylst de kaai yn gebrûk wie.

Dit is deselde grins as in SSH-kaai mei wachtwurd, of in iepene kluis fan in wachtwurdbehearder. It ferheget de kosten fan it stellen fan it bestân yn rêst en docht neat tsjin malware dy't as jo brûker draait, in autorisearre applikaasje dy't de klant freget te ûndertekenjen, of in behearder dy't ûnthâld lêze kin. Behannelje it as ien laach, net as de kontrôle dy't in kaai feilich makket om gewoan te litten lizzen.

Wêrom't de prompt hieltyd weromkomt

In klant dy't by elke opnij ferbining wer freget is net needsaaklik stikken. Guon klanten cache-it wachtwurd foar de sesje, guon bewarje it yn 'e OS-kaaibondel, en guon kinne nei in helper wiisd wurde dy't it leveret, dus hokker gedrach jo krije hinget fan 'e klant en syn konfiguraasje ôf, net fan it kaaibestân.

As de werhelle prompt de echte klacht is, besjoch dan de cache- en autentikaasjeopsjes fan 'e klant foardat jo fersifering fan 'e kaai helje. It wachtwurd fuorthelje makket fan in beskerme bestân in iepen-tekstkaai, en de opnij ferbining wurdt stil tsjin de kosten fan 'e iennichste rêstkontrôle dy't jo hienen. In better antwurd is meastentiids in stipe bewiisopslach mei deselde bestânsrjochten dy't jo dochs brûke soene.

Ferlies en bleatstelling binne net deselde reparaasje

In ferlern wachtwurd kin net út it sertifikaat werombrocht wurde. It sertifikaat is iepenbier materiaal dat in namme oan in kaai ferbynt; it befettet gjin paad werom nei de privekaai en gjin oanwizing oer it wachtwurd. De praktyske opsjes binne in autorisearre back-up fan 'e kaai, of in nije identiteit útjûn fia it normale proses fan 'e operator. Elkenien dy't oanbiedt it wachtwurd te 'werombringen', biedt oan it te rieden.

Bleatstelling freget in oare reaksje. Deselde kaai opnij fersiferje mei in nij wachtwurd lit it kaaimateriaal ûnferoare, dus in kopy dy't earne oars al iepene is wurket noch. De reparaasje is it bewiis fan identiteit ynlûke of ferfange: jou in nije kaai en sertifikaat út, ferspried se, en set de âlde by de peer út. Oant dat bart is it feroarjen fan it bestânswachtwurd húshâlding, net beheining. Hâld it âlde bestân bûten back-ups pas neidat de nije identiteit befêstige wurket, en skriuw op hokker searjenûmer of fingerprint it ferfong.