Er den publiserte OpenVPN-nøkkelen en CA, en partnernøkkel eller tls-auth?

Noen melder at VPN-nøkkelen er offentlig, og den setningen skjuler tre helt forskjellige situasjoner. Det kan være et CA-sertifikat som hver klient skal ha, en privat identitetsnøkkel som aldri skulle ha forlatt én maskin, eller en delt kontrollkanalhemmelighet som begge ender må holde. Reparasjonen, hastverket og skadeomfanget er forskjellig i hvert tilfelle, så den første oppgaven er klassifisering og ikke handling. Tar du feil kategori, er hvert senere steg bortkastet arbeid.

Start med direktivet, ikke filnavnet

Les den aktive konfigurasjonen og finn ut hvilket direktiv som peker på materialet. OpenVPN sine TLS-innstillinger bruker ca for klarert sertifikatmateriale, cert for sertifikatet til den lokale partneren og key for den private nøkkelen som hører til.

Filnavn beviser ingenting. En fil som heter key.pem kan inneholde et sertifikat, og en innebygd blokk i profilen kan inneholde nøyaktig samme objekt som en separat fil på disken. Åpne filen og se på headeren i stedet for å stole på navnet. Den ene kontrollen fjerner det meste av uklarheten i rapporten.

Hvis profilen er en PKCS#12-pakke, pakk den ut på et kontrollert sted for å se hva den faktisk inneholder. Én pakke kan bære et sertifikat, kjeden og en privat nøkkel, noe som betyr at en lekkasje av pakken er en lekkasje av alle tre.

Skriv ned klassifiseringen før noen endrer en fil: objekt, direktiv, hvilke parter som har den og hvem som kan lese den. Den setningen er det resten av svaret avhenger av.

Et CA-sertifikat er ment å deles

Et offentlig CA-sertifikat er klarert materiale. Klienter trenger det for å verifisere serveren, og å distribuere det er det normale tilfellet og ikke en hendelse. Å publisere det publiserer ikke CA-ens private signeringsnøkkel, og nettopp det objektet ville la en angriper lage nye identiteter.

Den forskjellen er verdt å skrive eksplisitt i saken, fordi de to stadig blandes sammen. Spørsmålet som skal besvares, er om den lekkede filen er sertifikatet eller signeringsnøkkelen, og et raskt blikk på filinnholdet avgjør det. Et sertifikat bærer en offentlig nøkkel og en signatur; signeringsnøkkelen forekommer ikke i det i det hele tatt.

Distribusjon fortjener likevel omhu. Klienter bør hente sertifikatet via den godkjente veien for profillevering, ikke fra et lim-inn-nettsted, og et sertifikat som kommer via en uklarert rute kan bli byttet ut underveis.

En partnernøkkel og en tls-auth-hemmelighet er ikke

En partners private nøkkel er identitetsmateriale. Når den er kopiert, kan serveren ikke lenger skille den tiltenkte enheten fra alle som har kopien, fordi eksklusiv besittelse var egenskapen som ble demonstrert. Fortsatt autorisasjon og utskifting er beslutninger for VPN-eieren, ikke for den som fant filen.

En tls-auth-hemmelighet er en tredje ting. Den legger til HMAC-autentisering rundt kontrollkanalpakker slik at feil autentiserte pakker forkastes før en TLS-utveksling, og den er verken partnerens private nøkkel eller nøkkelen som krypterer applikasjonsdata.

Hvis den delte hemmeligheten er offentlig, er barrieren den ga borte for alle som har den. Det følger ikke at enhver innehaver består sertifikat- og brukerkontrollene bak den, og derfor er klassifiseringen viktigere enn alarmnivået. Si hvilken barriere som falt, og si hvilke som står igjen.

Reparer rollen som lakk, ikke en nabos

En delt hemmelighet kan ikke gjøres privat igjen ved å gi filen nytt navn eller skjule nedlastingslenken. Utskifting betyr å generere en ny verdi og distribuere den til hver part i en koordinert endring, og å skifte ut bare én side ødelegger ordningen for alle som fortsatt har den gamle verdien.

Hvis en partneridentitet ble avdekket, bruk operatørens tilbakekallings- og nyregistreringsprosess for den identiteten. Å endre passordet til en urelatert konto gjør ikke et kopiert sertifikat ugyldig, og det gjør heller ikke utskifting av tls-auth-filen.

Bekreft hva den utrullede serveren faktisk håndhever før du stoler på noe av dette. En tilbakekallingsliste som ikke oppdateres, eller en rollekontroll som ble slått av under en driftsforstyrrelse, endrer svaret fullstendig. Les den kjørende konfigurasjonen, ikke kopien i repositoriet.

Vurder tidligere trafikk på egne vilkår

En avdekket fil sier ikke i seg selv om tidligere fangede sesjoner kan dekrypteres. Det avhenger av nøkkeloppsettmetoden, materialet som ble avdekket og hvilke logger som finnes, og både «all trafikk er tapt» og «ingenting skjedde» er gjetninger uten disse faktaene.

Ikke legg ut enda en kopi av påloggingsinformasjonen mens du spør hvilken kategori den hører til. Del i stedet direktivnavn og ikke-hemmelige metadata via den godkjente støtteveien.

Den nyttige konklusjonen navngir objektet, rollen, beskyttelsen som gikk tapt og den koordinerte handlingen som kreves. Alt kortere er en overskrift og ikke en vurdering.