Bytte ut ein leka VPN-nøkkel: kva serveren må gjere

Ein berbar PC med ein klientnøkkel vart borte, og det første tiltaket er vanlegvis å slette den lokale kopien. Det endrar ingenting på serveren, som framleis har ein autorisasjon som vil godta nøkkelen til nokon fjernar han. Utskifting er to operasjonar, og berre den andre gjeld den gamle legitimasjonen.

Den lokale kopien er ikkje autoriteten

Ein VPN-legitimasjon vert godteken fordi konfigurasjonen på serversida seier det. For sertifikat tyder det at sertifikatet knyter seg til ein klarert utferdar og ikkje står på ei tilbakekallingsliste som gatewayen sjekkar. For WireGuard tyder det at den offentlege nøkkelen til peeren står i grensesnittkonfigurasjonen. Å slette ei fil på ein klient fjernar éin kopi av ein hemmelegheit og lèt godtakingsregelen vere urørt.

Difor verkar ein stolen nøkkel framleis etter den openberre oppryddinga, og difor kjennest hendinga uavklart sjølv når den nye konfigurasjonen er installert.

Start med regelen til serveren, og arbeid deg deretter utover til klienten.

Sertifikat: serveren har avgjerda

Utferd erstattaren gjennom den eigne prosessen til utferdaren slik at den nye identiteten vert registrert, og trekk deretter tilbake den gamle med ein signert tilbakekalling. Gatewayen må vere konfigurert til å slå opp den tilbakekallingskjelda, og han må laste henne på nytt, elles vert fila liggjande på disken medan tunnelen held fram med å godta det gamle serienummeret. Aktive økter kan òg overleve til re-forhandling, så planlegg ein attilkopling.

Stadfest at erstattaren verkar for den tiltenkte applikasjonen, og stadfest deretter gjennom ein godkjend prosess at det avvikla sertifikatet ikkje lenger etablerer tilgang.

Det er to ulike testar, og begge krevst. RFC 5280 definerer sertifikat- og tilbakekallingssemantikken gatewayen byggjer på.

WireGuard: peernøkkelen er identiteten

WireGuard har ikkje noko sertifikatlag: den offentlege nøkkelen til peeren er identiteten, og allowed-ips-oppføringa til serveren er autorisasjonen. Å fjerne den gamle peeren frå grensesnittkonfigurasjonen er tilbakekallinga, og ho gjeld med ein gong for nye handtrykk.

Eksisterande økter sluttar når neste handtrykk mislukkast, noko som vanlegvis skjer innan eit par minutt og ikkje med ein gong.

Distribuer den nye konfigurasjonen over ein kanal du ville betrodd eit passord, fordi den private nøkkelen er legitimasjonen. Hald éin nøkkel per eining, slik at éi tapt eining ikkje tvingar kvar eining til å bytte.

Kva anna var i den pakken

Ein klientpakke ber ofte meir enn den private nøkkelen: ein statisk TLS-nøkkel, eit brukarnamn og passord, ein førehandsdelt hemmelegheit eller eit provisjoneringstoken. Avgrens hendinga til det som faktisk vart eksponert, og roter òg dei elementa. Å rotere sertifikatet medan ein delt statisk nøkkel vert ståande lukkar éi dør og lèt ei anna stå open.

Viss pakken vart delt mellom einingar, arvar kvar eining som ber han eksponeringa.

Skriv ned kva som vart rotert, fordi neste revisjon vil spørje.

Prov avvisinga, og registrer deretter erstattaren

Erstattaren er fullført når to fakta held: den nye identiteten verkar for den tiltenkte tenesta, og den gamle vert avvist. Stadfest det andre med den avvikla legitimasjonen frå eit testmiljø, eller med eit kontrollert forsøk organisasjonen godkjenner, og les gateway-loggene for å stadfeste at avvisinga kom frå policy og ikkje frå ein skrivefeil. Registrer deretter den gamle identifikatoren, den nye og tidspunktet for endringa, fordi det er desse tre verdiane ein revisor treng for å rekonstruere henne. Ingenting anna i saka vil forklare gapet.

Hald private nøklar unna saker og chat, og fjern utdaterte eksportar frå lagring og tryggingskopiar i tråd med policy.

Ein erstattar utan avvisingstest er ei antekning, ikkje ei retting.