Varför en större OpenVPN-nyckel inte tar bort omnycklingstimern

Att välja AES-256 eller en längre nyckel säger ingenting om hur länge den nyckeln får användas. Nyckelstyrka beskriver algoritmen; omnycklingspolicyn avgör när sessionen härleder nytt nyckelmaterial. En driftsättning kan välja det starkaste tillgängliga chifret och ändå ha fel om förnyelsen, eftersom de två besluten fattas på olika ställen. Att blanda ihop dem ger antingen en onödig chifferändring eller en session som tyst överlever sin policy.

Läs omnycklingsinställningarna innan du rör chifret, och läs båda parter när du gör det.

Nyckelstyrka och nyckellivslängd svarar på olika frågor

Chifret och nyckelstorleken begränsar hur dyrt ett angrepp på avlyssnad trafik skulle vara. Omnycklingsintervallet begränsar hur mycket trafik en nyckel skyddar och hur länge en komprometterad nyckel förblir användbar. Det är oberoende inställningar, och ett starkare chiffer förlänger inte en sessions säkra livslängd. De flesta råd som säger 'använd AES-256' tiger om förnyelsen, eftersom förnyelse är en policyfråga och inte ett algoritmval.

Anteckna båda i driftsättningsnoteringarna: vad som skyddar datakanalen, och vad som utlöser utbyte av dess nycklar.

Omnyckling har tre utlösare, och båda parter kan utlösa dem

OpenVPN 2.6 dokumenterar separata utlösare för omförhandling baserat på byte, paket och förfluten tid. Tidsutlösaren är den som de flesta driftsättningar lämnar på standardvärdet, vilket innebär att en tyst tunnel ändå nycklar om enligt schemat. Båda parter kan starta utbytet, och den part som inte startade det följer efter. Att ändra timern på en sida fastställer därför inte sessionens beteende; det effektiva värdet är den sida som börjar först.

Byte- och paketutlösare spelar roll vid arbetslaster med hög genomströmning eller små paket, där en policy enbart baserad på tid skulle låta en nyckel skydda långt mer data än avsett. Om dessa räknare förblir avstängda, säg det med avsikt i noteringarna istället för att lämna standardvärdet outrett.

En omnyckling blottar autentiseringsflödet

Omförhandling är en ny TLS-handskakning, vilket innebär att autentiseringsvägen körs igen. Driftsättningar med engångskoder, hårdvarutoken eller en RADIUS-utmaning upptäcker detta på det hårda sättet: den första anslutningen fungerar och sessionen dör en timme senare när den andra handskakningen ber om en kod som redan använts. auth-gen-token finns för att överbrygga den luckan genom att låta servern utfärda en kortlivad token för omförhandling istället för att kräva en ny interaktiv inloggning.

Behandla det som ett arbetsflödesproblem att lösa med operatören, inte som bevis för att förnyelsen bör stängas av.

Testa förnyelse under last, inte i en session på en minut

Ett acceptanstest som ansluter, pingar en gång och kopplar från når aldrig omnycklingen. Kör en session tillräckligt länge för att passera den konfigurerade utlösaren, håll en överföring igång hela tiden och titta i båda parternas loggar efter den nya handskakningen. Testa sedan felvägen: vad klienten gör om omförhandlingen inte kan slutföras. En tunnel som faller rent är lättare att diagnostisera än en som fortsätter skicka in i en död session.

Läs inte en lyckad stor överföring som bevis på en kryptografisk tröskel. Den visar bara att vägen och räknarna klarade så mycket trafik.

Dokumentera båda valen

Posten behöver två rader: hur paket skyddas, och när det skyddet byts ut. Lägg till behörigheten för varje värde, eftersom chifret kan komma från en distributionstandard medan timern kommer från en intern policy. En framtida operatör bör inte behöva härleda något av dem från en konfigurationsfil.

Om kompatibilitet tvingar fram ett undantag, begränsa det till en version och ett slutdatum. Ett undantag som överlever sitt skäl blir policyn som ingen minns att de valde.