Nøgleskift, genopkobling eller reautentificering: hvad har du brug for?

En session, der har kørt i timer, beholder ikke de samme nøgler for evigt, og det er med vilje. Tre forskellige hændelser beskrives som nøglerotation: nyt sessionsmateriale under en eksisterende association, en fuld genopbygning af forbindelsen og en gentagelse af identitetskontrollen. Hver har en forskellig udløser, en forskellig pris og en forskellig fejlsignatur. Vælger du den forkerte, gør rettelsen enten ingenting eller tager tunnelen ned uden grund.

Beslutningen afhænger af, hvilket lag der faktisk er udløbet.

Tre operationer, der kaldes rotation

Et nøgleskift opretter friske trafiknøgler inden for det eksisterende kontrolforhold ved hjælp af den mekanisme, protokollen definerer. IKEv2 gør det med en ny underordnet sikkerhedsassociation, TLS 1.3 med en nøgleopdateringsmeddelelse, og WireGuard med et nyt håndtryk, når dets tids- eller meddelelsesgrænser nås. Tunneladresserne og den autentificerede identitet bliver, hvor de var.

En genopkobling kasserer forbindelsen og bygger den op igen fra begyndelsen, hvilket gentager tildeling af adresser, installation af ruter og enhver forhandling, som det første forsøg udførte.

Reautentificering gentager selve identitetsbeviset, som kan omfatte en legitimationsoplysning, et certifikat eller en anden faktor. Det kan ske med eller uden genopkobling, afhængigt af produktet.

Hvad brugerne bemærker ved fornyelse

Et nøgleskift bør være tæt på usynligt. Associations-id'er ændres, tællere kan nulstilles, og applikationer beholder deres sockets; en kort pause i én retning er normal under udvekslingen. Et nyt id i en statusliste er ikke bevis på en fejl. Loglinjen efter udvekslingen er det, der fortæller dig, om den blev færdig.

Et egentligt afbrud ved fornyelse peger på noget bestemt. Uenighed i forslaget, en udløbet legitimationsoplysning eller en ændret sti giver hver en forskellig loglinje, og kun én af dem rettes ved at justere levetider.

Hvor de tre skiller sig ad i praksis

Hvis det eneste, der er udløbet, er nøglemateriale, så skift nøgle. Hvis peer-adressen, ruten eller NAT-bindingen er ændret, og pakkerne ikke længere ankommer, så genopkobl. Hvis organisationen kræver en periodisk identitetskontrol, er det reautentificering, og ingen justering af levetider erstatter den.

Protokollernes standardværdier indeholder normalt det rigtige svar. WireGuard skifter nøgle efter en tids- og datamængdegrænse uden brugerindgriben; IKEv2-levetider forhandles for hver underordnet association; TLS-baserede tunneler roterer nøgler inde i den eksisterende session. At hæve levetiderne for at undgå en tilbagevendende fejl udskyder fejlen og forlænger eksponeringen, hvis en nøgle kompromitteres.

Én forbehold er vigtigt for lange sessioner: hyppighed alene skaber ikke forward secrecy. Egenskaben afhænger af, hvordan sessionsnøgler forholder sig til langsigtede hemmeligheder, og om gamle nøgler destrueres, hvilket er et design- og implementeringsspørgsmål snarere end en indstilling.

Vælg standardværdier, og registrér derefter fasen

Behold leverandørens standardværdier, medmindre et dokumenteret krav siger andet, og ændr levetider på begge peers, hvis du ændrer dem. Registrér derefter, hvilken fase hver hændelse nåede, så den næste forekomst kan kontrolleres mod det 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'

Efter en rettelse kører du en kontrolleret fornyelse og sender frisk applikationstrafik gennem den nye association. En tunnel, der rapporterer etableret, men ikke videresender noget, er den fejl, denne kontrol findes for at fange.