Hvorfor en større OpenVPN-nøgle ikke fjerner gennøgletimeren
Cipherstyrke og nøglens levetid er separate beslutninger. Kontroller byte-, pakke- og tidsudløserne, og test derefter en gennøgling mod det rigtige loginforløb.
At vælge AES-256 eller en længere nøgle siger intet om, hvor længe den nøgle må bruges. Nøglestyrke beskriver algoritmen; gennøglingspolitikken afgør, hvornår sessionen udleder nyt nøglemateriale. En udrulning kan vælge den stærkeste tilgængelige cipher og stadig tage fejl af fornyelsen, fordi de to beslutninger træffes forskellige steder. At blande dem sammen giver enten en unødvendig cipherændring eller en session, der stille overlever sin politik.
Læs gennøglingsindstillingerne, før du rører cipheren, og læs begge parter, når du gør det.
Nøglestyrke og nøglelevetid besvarer forskellige spørgsmål
Cipheren og nøglestørrelsen begrænser, hvor dyrt et angreb på opsnappet trafik ville være. Gennøglingsintervallet begrænser, hvor meget trafik én nøgle beskytter, og hvor længe en kompromitteret nøgle forbliver brugbar. Det er uafhængige knapper, og en stærkere cipher forlænger ikke en sessions sikre levetid. De fleste anbefalinger, der siger 'brug AES-256', tier om fornyelse, fordi fornyelse er et politisk spørgsmål snarere end et algoritmevalg.
Notér begge i udrulningsnoterne: hvad der beskytter datakanalen, og hvad der udløser udskiftning af dens nøgler.
Gennøgling har tre udløsere, og begge parter kan aktivere dem
OpenVPN 2.6 dokumenterer separate udløsere for forhandling igen baseret på byte, pakker og forløbet tid. Tidsudløseren er den, de fleste udrulninger lader stå på standarden, hvilket betyder, at en stille tunnel stadig gennøgler efter planen. Begge parter kan starte udvekslingen, og den part, der ikke startede den, følger efter. At ændre timeren på den ene side fastlægger derfor ikke sessionens adfærd; den effektive værdi er den side, der starter først.
Byte- og pakkeudløsere betyder noget ved arbejdsbelastninger med høj gennemstrømning eller små pakker, hvor en politik, der kun bygger på tid, ville lade én nøgle beskytte langt mere data end tilsigtet. Hvis de tællere forbliver deaktiveret, så sig det med vilje i noterne i stedet for at lade standarden være uundersøgt.
En gennøgling blotlægger godkendelsesforløbet
En ny forhandling er et frisk TLS-håndtryk, hvilket betyder, at godkendelsesstien kører igen. Udrulninger med engangskoder, hardwaretokens eller en RADIUS-udfordring opdager det på den hårde måde: den første forbindelse virker, og sessionen dør en time senere, når det andet håndtryk beder om en kode, der allerede er brugt. auth-gen-token findes for at bygge bro over det hul ved at lade serveren udstede et kortlivet token til forhandlingen i stedet for at kræve et nyt interaktivt login.
Behandl det som et arbejdsgangsproblem, der skal løses med operatøren, ikke som bevis for, at fornyelse bør slås fra.
Test fornyelse under last, ikke i en session på et minut
En accepttest, der forbinder, pinger én gang og afbryder, når aldrig gennøglingen. Kør en session længe nok til at krydse den konfigurerede udløser, hold en overførsel kørende gennem det hele, og hold øje med begge parters logfiler for det nye håndtryk. Test derefter fejlstien: hvad klienten gør, hvis forhandlingen ikke kan fuldføres. En tunnel, der falder rent, er lettere at diagnosticere end en, der bliver ved med at sende ind i en død session.
Læs ikke en vellykket stor overførsel som bevis for en kryptografisk tærskel. Den viser kun, at stien og tællerne overlevede så meget trafik.
Dokumentér begge valg
Posten kræver to linjer: hvordan pakker beskyttes, og hvornår den beskyttelse udskiftes. Tilføj hjemlen for hver værdi, fordi cipheren kan komme fra en distributionsstandard, mens timeren kommer fra en intern politik. En fremtidig operatør bør ikke skulle udlede nogen af dem af en konfigurationsfil.
Hvis kompatibilitet tvinger en undtagelse, skal du afgrænse den til en version og en slutdato. En undtagelse, der overlever sin begrundelse, bliver den politik, som ingen husker at have valgt.