Kvifor ein større OpenVPN-nøkkel ikkje fjernar omnøkkel-timaren

Å velje AES-256 eller ein lengre nøkkel seier ingenting om kor lenge den nøkkelen kan brukast. Nøkkelstyrke skildrar algoritmen; omnøklingspolicyen avgjer når økta leier ut nytt nøkkelmateriale. Ei utrulling kan velje den sterkaste tilgjengelege chifferen og likevel ta feil av fornyinga, fordi dei to avgjerdene blir tekne på ulike stader. Å blande dei gir anten ei unødvendig chifferendring eller ei økt som stille overlever policyen sin.

Les omnøklingsinnstillingane før du rører chifferen, og les begge partar når du gjer det.

Nøkkelstyrke og nøkkellevealder svarar på ulike spørsmål

Chifferen og nøkkelstorleiken avgrensar kor dyrt eit åtak på avlytta trafikk ville vere. Omnøklingsintervallet avgrensar kor mykje trafikk éin nøkkel vernar og kor lenge ein kompromittert nøkkel held fram med å vere nyttig. Dette er uavhengige innstillingar, og ein sterkare chiffer forlengjer ikkje den trygge levetida til ei økt. Dei fleste rettleiingane som seier «bruk AES-256», teier om fornyinga, fordi fornying er eit policyspørsmål og ikkje eit algoritmeval.

Noter begge i utrullingsnotata: kva som vernar datakanalen, og kva som utløyser utskifting av nøklane hans.

Omnøkling har tre utløysarar, og begge partar kan utløyse dei

OpenVPN 2.6 dokumenterer separate utløysarar for ny forhandling basert på byte, pakkar og medgått tid. Tidsutløysaren er den dei fleste utrullingar lèt stå på standardverdien, noko som tyder at ein stille tunnel likevel omnøklar etter planen. Begge partar kan starte utvekslinga, og parten som ikkje starta ho, følgjer etter. Å endre timeren på éi side fastset derfor ikkje åferda til økta; den effektive verdien er den sida som startar først.

Byte- og pakkeutløysarar har noko å seie ved arbeidslaster med høg gjennomstrøyming eller små pakkar, der ein policy berre basert på tid ville late éin nøkkel verne langt meir data enn tenkt. Viss desse teljarane blir ståande avslått, seier du det med vilje i notata i staden for å late standardverdien vere uundersøkt.

Ein omnøkling avdekkjer autentiseringsflyten

Ny forhandling er eit ferskt TLS-handtrykk, som tyder at autentiseringsbana blir køyrd på nytt. Utrullingar med eingongskodar, maskinvaretoken eller ei RADIUS-utfordring oppdagar dette på den harde måten: den første tilkoplinga verkar, og økta døyr ein time seinare når det andre handtrykket ber om ein kode som alt er brukt. auth-gen-token finst for å byggje bru over det gapet ved å late tenaren gje ut eit kortliva token for ny forhandling i staden for å krevje ei ny interaktiv innlogging.

Handter det som eit arbeidsflytproblem som skal løysast saman med operatøren, ikkje som prov på at fornying bør slåast av.

Test fornying under last, ikkje i ei økt på eitt minutt

Ein akseptansetest som koplar til, pingar éin gong og koplar frå, når aldri omnøklinga. Køyr ei økt lenge nok til å krysse den konfigurerte utløysaren, hald ei overføring gåande gjennom heile, og følg loggane til begge partar etter det nye handtrykket. Test deretter feilvegen: kva klienten gjer viss ny forhandling ikkje kan fullførast. Ein tunnel som fell reint, er lettare å diagnostisere enn ein som held fram med å sende inn i ei død økt.

Ikkje les ein vellukka stor overføring som prov på ein kryptografisk terskel. Ho viser berre at bana og teljarane tolte så mykje trafikk.

Dokumenter begge vala

Oppføringa treng to linjer: korleis pakkar blir verna, og når det vernet blir erstatta. Legg til heimelen for kvar verdi, fordi chifferen kan kome frå ein distribusjonsstandard medan timeren kjem frå ein intern policy. Ein framtidig operatør bør ikkje måtte utleie nokon av dei frå ei konfigurasjonsfil.

Viss kompatibilitet tvingar fram eit unntak, avgrens det til ein versjon og ein sluttdato. Eit unntak som overlever grunnen sin, blir policyen ingen hugsar at dei valde.