Nøkkelbytte, gjentilkobling eller reautentisering: hva trenger du?

En økt som har kjørt i timer beholder ikke de samme nøklene for alltid, og det er med vilje. Tre forskjellige hendelser kalles nøkkelrotasjon: nytt øktmateriale under en eksisterende assosiasjon, en full gjenoppbygging av forbindelsen og en gjentakelse av identitetskontrollen. Hver har en annen utløser, en annen kostnad og en annen feilsignatur. Velger du feil, gjør rettelsen enten ingenting eller tar tunnelen ned uten grunn.

Avgjørelsen avhenger av hvilket lag som faktisk er utløpt.

Tre operasjoner som kalles rotasjon

Et nøkkelbytte lager ferske trafiksnøkler innenfor det eksisterende kontrollforholdet, ved hjelp av mekanismen protokollen definerer. IKEv2 gjør det med en ny underordnet sikkerhetsassosiasjon, TLS 1.3 med en nøkkeloppdateringsmelding, og WireGuard med et nytt håndtrykk når tids- eller meldingsgrensene nås. Tunneladressene og den autentiserte identiteten blir der de var.

En gjentilkobling forkaster forbindelsen og bygger den opp igjen fra begynnelsen, noe som gjentar adressetildeling, installasjon av ruter og enhver forhandling det første forsøket gjorde.

Reautentisering gjentar selve identitetsbeviset, som kan omfatte et passord, et sertifikat eller en annen faktor. Det kan skje med eller uten gjentilkobling, avhengig av produktet.

Hva brukerne merker ved fornyelse

Et nøkkelbytte bør være nesten usynlig. Assosiasjons-ID-er endres, tellere kan nullstilles, og applikasjoner beholder socketene sine; en kort pause i én retning er normalt under utvekslingen. En ny ID i en statusliste er ikke bevis på feil. Logglinjen som følger utvekslingen, er det som forteller deg om den ble ferdig.

Et faktisk brudd ved fornyelse peker på noe bestemt. Uenighet i forslaget, utløpt passord eller endret sti gir hver sin logglinje, og bare én av dem rettes ved å justere levetider.

Hvor de tre skiller lag i praksis

Hvis det eneste som er utløpt er nøkkelmateriale, gjør et nøkkelbytte. Hvis peer-adressen, ruten eller NAT-bindingen er endret og pakkene ikke lenger kommer, koble til på nytt. Hvis organisasjonen krever en periodisk identitetskontroll, er det reautentisering, og ingen justering av levetider erstatter den.

Protokollens standardverdier inneholder vanligvis det riktige svaret. WireGuard bytter nøkkel etter en tids- og datamengdegrense uten brukerinngripen; IKEv2-levetider forhandles per underordnet assosiasjon; TLS-baserte tunneler roterer nøkler inne i den eksisterende økten. Å øke levetidene for å unngå en tilbakevendende feil utsetter feilen og forlenger eksponeringen hvis en nøkkel kompromitteres.

Ett forbehold er viktig for lange økter: hyppighet alene skaper ikke forward secrecy. Egenskapen avhenger av hvordan øktnøkler forholder seg til langsiktige hemmeligheter og om gamle nøkler ødelegges, noe som er et design- og implementeringsspørsmål, ikke en innstilling.

Velg standardverdier, og registrer deretter fasen

Behold leverandørens standardverdier med mindre et dokumentert krav sier noe annet, og endre levetider på begge peers hvis du endrer dem i det hele tatt. Registrer deretter hvilken fase hver hendelse nådde, slik at neste forekomst kan kontrolleres mot samme punkt i håndtrykket.

swanctl --list-sas
ip xfrm state | grep -E 'proto|replay-window'
wg show
journalctl -u strongswan --since '1 hour ago' | grep -i -E 'rekey|rekeyed|child'

Etter en rettelse, kjør en kontrollert fornyelse og send fersk applikasjonstrafikk gjennom den nye assosiasjonen. En tunnel som rapporterer at den er etablert men ikke videresender noe, er feilen denne kontrollen finnes for å fange.