Är den publicerade OpenVPN-nyckeln en CA, en partnernyckel eller tls-auth?

Någon rapporterar att VPN-nyckeln är offentlig, och den meningen döljer tre helt olika situationer. Det kan vara ett CA-certifikat som varje klient förväntas ha, en privat identitetsnyckel som aldrig borde ha lämnat en maskin, eller en delad hemlighet för kontrollkanalen som båda ändarna måste hålla. Reparationen, brådskan och skadans omfattning skiljer sig åt i varje fall, så den första uppgiften är klassificering och inte handling. Tar du fel kategori är varje senare steg bortkastat arbete.

Börja med direktivet, inte filnamnet

Läs den aktiva konfigurationen och ta reda på vilket direktiv som pekar på materialet. OpenVPN:s TLS-alternativ använder ca för betrott certifikatmaterial, cert för den lokala partnerns certifikat och key för den privata nyckeln som hör till.

Filnamn bevisar ingenting. En fil som heter key.pem kan innehålla ett certifikat, och ett inbäddat block i profilen kan innehålla exakt samma objekt som en separat fil på disken. Öppna filen och titta på dess huvud i stället för att lita på namnet. Den enda kontrollen tar bort det mesta av otydligheten i rapporten.

Om profilen är ett PKCS#12-paket, packa upp det på en kontrollerad plats för att se vad det faktiskt innehåller. Ett enda paket kan bära ett certifikat, dess kedja och en privat nyckel, vilket betyder att ett läckage av paketet är ett läckage av alla tre.

Skriv ner klassificeringen innan någon ändrar en fil: objekt, direktiv, vilka parter som har den och vem som kan läsa den. Den meningen är vad resten av svaret hänger på.

Ett CA-certifikat är gjort för att delas

Ett offentligt CA-certifikat är betrott material. Klienter behöver det för att verifiera servern, och att distribuera det är det normala fallet och inte en incident. Att publicera det publicerar inte CA:ns privata signeringsnyckel, och just det objektet skulle låta en angripare skapa nya identiteter.

Den skillnaden är värd att skriva uttryckligen i ärendet, eftersom de två ständigt blandas ihop. Frågan som ska besvaras är om den läckta filen är certifikatet eller signeringsnyckeln, och en snabb titt på filens innehåll avgör det. Ett certifikat bär en offentlig nyckel och en signatur; signeringsnyckeln förekommer inte alls i det.

Distributionen förtjänar ändå omsorg. Klienter bör hämta certifikatet via den godkända vägen för profilleverans, inte från en klistra-in-sajt, och ett certifikat som kommer via en ej betrodd väg kan bytas ut under vägen.

En partnernyckel och en tls-auth-hemlighet är inte

En partners privata nyckel är identitetsmaterial. När den har kopierats kan servern inte längre skilja den avsedda enheten från alla som har kopian, eftersom exklusivt innehav var den egenskap som demonstrerades. Fortsatt auktorisering och utbyte är beslut för VPN-ägaren, inte för den som hittade filen.

En tls-auth-hemlighet är en tredje sak. Den lägger till HMAC-autentisering runt kontrollkanalens paket så att felaktigt autentiserade paket kastas före ett TLS-utbyte, och den är varken partnerns privata nyckel eller nyckeln som krypterar applikationsdata.

Om den delade hemligheten är offentlig är barriären den gav borta för alla som har den. Det följer inte att varje innehavare klarar certifikat- och användarkontrollerna bakom den, och därför är klassificeringen viktigare än larmnivån. Säg vilken barriär som föll, och säg vilka som står kvar.

Reparera rollen som läckte, inte en grannes

En delad hemlighet kan inte göras privat igen genom att byta namn på filen eller dölja nedladdningslänken. Utbyte innebär att generera ett nytt värde och distribuera det till varje part i en koordinerad ändring, och att byta ut bara en sida förstör överenskommelsen för alla som fortfarande har det gamla värdet.

Om en partneridentitet har avslöjats, använd operatörens återkallnings- och nyregistreringsprocess för den identiteten. Att ändra lösenordet för ett orelaterat konto ogiltigförklarar inte ett kopierat certifikat, och det gör inte heller ett byte av tls-auth-filen.

Bekräfta vad den driftsatta servern faktiskt tillämpar innan du litar på något av detta. En återkallningslista som inte uppdateras, eller en rollkontroll som stängdes av under en störning, ändrar svaret helt. Läs den körande konfigurationen och inte kopian i arkivet.

Bedöm tidigare trafik på dess egna villkor

En avslöjad fil säger inte i sig om tidigare fångade sessioner kan dekrypteras. Det beror på nyckeluppsättningsmetoden, materialet som avslöjades och vilka loggar som finns, och både »all trafik är förlorad« och »ingenting hände« är gissningar utan dessa fakta.

Publicera inte ännu en kopia av inloggningsuppgifterna medan du frågar vilken kategori den tillhör. Dela i stället direktivnamn och icke-hemliga metadata via den godkända supportvägen.

Den användbara slutsatsen namnger objektet, dess roll, skyddet som gick förlorat och den koordinerade åtgärd som krävs. Allt kortare är en rubrik och inte en bedömning.