Byta ut en läckt VPN-nyckel: vad servern måste göra

En bärbar dator med en klientnyckel försvann, och det första steget är oftast att radera den lokala kopian. Det ändrar ingenting på servern, som fortfarande har ett tillstånd som accepterar nyckeln tills någon tar bort det. Utbytet är två operationer, och bara den andra gäller den gamla inloggningsuppgiften.

Den lokala kopian är inte auktoriteten

En VPN-uppgift accepteras för att konfigurationen på serversidan säger det. För certifikat betyder det att certifikatet kedjas till en betrodd utfärdare och inte finns på en återkallningslista som gatewayen kontrollerar. För WireGuard betyder det att peerens publika nyckel finns i gränssnittskonfigurationen. Att radera en fil på en klient tar bort en kopia av en hemlighet och lämnar acceptansregeln orörd.

Därför fungerar en stulen nyckel fortfarande efter den uppenbara städningen, och därför känns incidenten olöst även när den nya konfigurationen är installerad.

Börja med serverns regel och arbeta sedan utåt mot klienten.

Certifikat: servern har beslutet

Utfärda utbytet genom utfärdarens egen process så att den nya identiteten registreras, och dra sedan tillbaka den gamla med en signerad återkallelse. Gatewayen måste vara konfigurerad att kontrollera den återkallelsekällan och måste läsa in den igen, annars ligger filen kvar på disken medan tunneln fortsätter att acceptera det gamla serienumret. Aktiva sessioner kan också överleva till omförhandling, så planera en återanslutning.

Bekräfta att utbytet fungerar för den avsedda applikationen och bekräfta sedan genom en godkänd process att det pensionerade certifikatet inte längre etablerar åtkomst.

Det är två olika tester och båda krävs. RFC 5280 definierar certifikat- och återkallelsesemantiken som gatewayen bygger på.

WireGuard: peerens nyckel är identiteten

WireGuard har inget certifikatlager: peerens publika nyckel är identiteten och serverns allowed-ips-post är auktorisationen. Att ta bort den gamla peeren från gränssnittskonfigurationen är återkallelsen, och den gäller omedelbart för nya handskakningar.

Befintliga sessioner avslutas när nästa handskakning misslyckas, vilket vanligtvis sker inom några minuter och inte omedelbart.

Distribuera den nya konfigurationen via en kanal du skulle anförtro ett lösenord, eftersom den privata nyckeln är inloggningsuppgiften. Håll en nyckel per enhet, så att en förlorad enhet inte tvingar varje enhet att byta.

Vad mer fanns i det paketet

Ett klientpaket bär ofta mer än den privata nyckeln: en statisk TLS-nyckel, ett användarnamn och lösenord, en fördelad hemlighet eller en provisioneringstoken. Begränsa incidenten till det som faktiskt exponerades och rotera även de delarna. Att rotera certifikatet medan en delad statisk nyckel ligger kvar stänger en dörr och lämnar en annan öppen.

Om paketet delades mellan enheter ärver varje enhet som bär det exponeringen.

Skriv ned vad som roterades, eftersom nästa revision kommer att fråga.

Bevisa avvisandet och registrera sedan utbytet

Utbytet är klart när två fakta gäller: den nya identiteten fungerar för den avsedda tjänsten och den gamla avvisas. Verifiera det andra med den pensionerade uppgiften från en testmiljö, eller med ett kontrollerat försök som organisationen godkänner, och läs gatewayloggarna för att bekräfta att avvisandet kom från policy och inte från ett skrivfel. Registrera sedan den gamla identifieraren, den nya och tiden för ändringen, eftersom det är dessa tre värden en revisor behöver för att rekonstruera den. Inget annat i ärendet kommer att förklara luckan.

Håll privata nycklar utanför ärenden och chattar, och ta bort inaktuella exporter från lagring och säkerhetskopior enligt policy.

Ett utbyte utan avvisningstest är ett antagande, inte en åtgärd.