Er den offentliggjorte OpenVPN-nøgle en CA, en partnernøgle eller tls-auth?

Nogen rapporterer, at VPN-nøglen er offentlig, og den sætning skjuler tre helt forskellige situationer. Det kan være et CA-certifikat, som hver klient forventes at have, en privat identitetsnøgle, der aldrig burde have forladt én maskine, eller en delt kontrolkanalhemmelighed, som begge ender skal have. Reparationen, hastigheden og skadesomfanget er forskellige i hvert tilfælde, så den første opgave er klassificering frem for handling. Tager du fejl af kategorien, er hvert efterfølgende skridt spildt arbejde.

Start med direktivet, ikke filnavnet

Læs den aktive konfiguration, og find ud af, hvilket direktiv der peger på materialet. OpenVPN’s TLS-indstillinger bruger ca til betroet certifikatmateriale, cert til den lokale partners certifikat og key til den private nøgle, der hører til.

Filnavne beviser intet. En fil med navnet key.pem kan indeholde et certifikat, og en indlejret blok i profilen kan indeholde præcis samme objekt som en separat fil på disken. Åbn filen, og se på dens header i stedet for at stole på navnet. Den ene kontrol fjerner det meste af uklarheden i rapporten.

Hvis profilen er en PKCS#12-pakke, skal du pakke den ud på et kontrolleret sted for at se, hvad den faktisk indeholder. En enkelt pakke kan bære et certifikat, dets kæde og en privat nøgle, hvilket betyder, at en lækage af pakken er en lækage af alle tre.

Skriv klassificeringen ned, før nogen ændrer en fil: objekt, direktiv, hvilke parter der har den, og hvem der kan læse den. Den sætning er det, resten af svaret afhænger af.

Et CA-certifikat er beregnet til at blive delt

Et offentligt CA-certifikat er betroet materiale. Klienter har brug for det til at verificere serveren, og distribution af det er det normale tilfælde frem for en hændelse. At offentliggøre det offentliggør ikke CA’ens private signeringsnøgle, som er det objekt, der ville give en angriber mulighed for at skabe nye identiteter.

Den forskel er værd at skrive eksplicit i sagen, fordi de to konstant blandes sammen. Spørgsmålet, der skal besvares, er, om den lækkede fil er certifikatet eller signeringsnøglen, og et hurtigt kig på filens indhold afgør det. Et certifikat bærer en offentlig nøgle og en signatur; signeringsnøglen optræder slet ikke i det.

Distribution fortjener stadig omhu. Klienter bør hente certifikatet via den godkendte profiludleveringsvej, ikke fra et paste-site, og et certifikat, der ankommer ad en utroværdig vej, kan blive udskiftet undervejs.

En partnernøgle og en tls-auth-hemmelighed er ikke

En partners private nøgle er identitetsmateriale. Når den er kopieret, kan serveren ikke længere skelne den tilsigtede enhed fra enhver, der har kopien, fordi eksklusiv besiddelse var den egenskab, der blev demonstreret. Fortsat autorisation og udskiftning er beslutninger for VPN-ejeren, ikke for den, der fandt filen.

En tls-auth-hemmelighed er en tredje ting. Den tilføjer HMAC-autentificering omkring kontrolkanalpakker, så forkert autentificerede pakker kasseres før en TLS-udveksling, og den er hverken partnerens private nøgle eller den nøgle, der krypterer applikationsdata.

Hvis den delte hemmelighed er offentlig, er den barriere, den udgjorde, væk for alle, der har den. Det følger ikke, at enhver indehaver består certifikat- og brugerkontrollerne bag den, og derfor er klassificeringen vigtigere end alarmniveauet. Sig, hvilken barriere der faldt, og sig, hvilke der er tilbage.

Reparer den rolle, der lækkede, ikke en nabos

En delt hemmelighed kan ikke gøres privat igen ved at omdøbe filen eller skjule downloadlinket. Udskiftning betyder at generere en ny værdi og distribuere den til hver part i en koordineret ændring, og at udskifte kun den ene side ødelægger ordningen for alle, der stadig har den gamle værdi.

Hvis en partneridentitet er blevet afsløret, skal du bruge operatørens tilbagekaldelses- og genregistreringsproces for den identitet. At ændre en ikke-relateret kontoadgangskode ugyldiggør ikke et kopieret certifikat, og det gør udskiftning af tls-auth-filen heller ikke.

Bekræft, hvad den udrullede server faktisk håndhæver, før du stoler på noget af det. En tilbagekaldelsesliste, der ikke opdateres, eller en rolekontrol, der blev deaktiveret under en driftsforstyrrelse, ændrer svaret fuldstændigt. Læs den kørende konfiguration i stedet for kopien i repositoriet.

Bedøm tidligere trafik på dens egne vilkår

En afsløret fil fortæller ikke i sig selv, om tidligere opfangede sessioner kan dekrypteres. Det afhænger af nøgleetableringsmetoden, det afslørede materiale og hvilke logfiler der findes, og både »al trafik er tabt« og »der skete ingenting« er gæt uden de fakta.

Læg ikke endnu en kopi af legitimationsoplysningerne ud, mens du spørger, hvilken kategori den hører til. Del i stedet direktivnavne og ikke-hemmelige metadata ad den godkendte supportvej.

Den nyttige konklusion navngiver objektet, dets rolle, den beskyttelse, der gik tabt, og den koordinerede handling, der kræves. Alt kortere er en overskrift frem for en vurdering.