Hvorfor en større OpenVPN-nøkkel ikke fjerner omnøkkel-timeren

Å velge AES-256 eller en lengre nøkkel sier ingenting om hvor lenge den nøkkelen kan brukes. Nøkkelstyrke beskriver algoritmen; omnøklingspolicyen avgjør når økten utleder nytt nøkkelmateriale. En utrulling kan velge den sterkeste tilgjengelige chifferen og likevel ta feil av fornyelsen, fordi de to beslutningene tas på forskjellige steder. Å blande dem gir enten en unødvendig chifferendring eller en økt som stille overlever policyen sin.

Les omnøklingsinnstillingene før du rører chifferen, og les begge parter når du gjør det.

Nøkkelstyrke og nøkkellevetid svarer på forskjellige spørsmål

Chifferen og nøkkelstørrelsen begrenser hvor dyrt et angrep på avlyttet trafikk ville være. Omnøklingsintervallet begrenser hvor mye trafikk én nøkkel beskytter og hvor lenge en kompromittert nøkkel forblir nyttig. Dette er uavhengige innstillinger, og en sterkere chiffer forlenger ikke en økts sikre levetid. De fleste anbefalinger som sier «bruk AES-256», tier om fornyelsen, fordi fornyelse er et policyspørsmål og ikke et algoritmevalg.

Noter begge i utrullingsnotatene: hva som beskytter datakanalen, og hva som utløser utskifting av nøklene dens.

Omnøkling har tre utløsere, og begge parter kan utløse dem

OpenVPN 2.6 dokumenterer separate utløsere for ny forhandling basert på byte, pakker og medgått tid. Tidsutløseren er den de fleste utrullinger lar stå på standardverdien, noe som betyr at en stille tunnel likevel omnøkler etter planen. Begge parter kan starte utvekslingen, og parten som ikke startet den, følger etter. Å endre timeren på én side fastsetter derfor ikke øktens oppførsel; den effektive verdien er den siden som starter først.

Byte- og pakkeutløsere betyr noe ved arbeidsbelastninger med høy gjennomstrømning eller små pakker, der en policy kun basert på tid ville la én nøkkel beskytte langt mer data enn tiltenkt. Hvis disse tellerne blir stående avslått, si det med vilje i notatene i stedet for å la standardverdien være uundersøkt.

En omnøkling avdekker autentiseringsflyten

Ny forhandling er en fersk TLS-håndtrykk, som betyr at autentiseringsbanen kjøres på nytt. Utrullinger med engangskoder, maskinvaretokener eller en RADIUS-utfordring oppdager dette på den harde måten: den første tilkoblingen virker, og økten dør en time senere når det andre håndtrykket ber om en kode som allerede er brukt. auth-gen-token finnes for å bygge bro over det gapet ved å la serveren utstede et kortlivet token for ny forhandling i stedet for å kreve en ny interaktiv innlogging.

Behandle det som et arbeidsflytproblem som skal løses sammen med operatøren, ikke som bevis for at fornyelse bør slås av.

Test fornyelse under last, ikke i en økt på ett minutt

En akseptansetest som kobler til, pinger én gang og kobler fra, når aldri omnøklingen. Kjør en økt lenge nok til å krysse den konfigurerte utløseren, hold en overføring gående gjennom hele, og følg loggene til begge parter etter det nye håndtrykket. Test deretter feilveien: hva klienten gjør hvis ny forhandling ikke kan fullføres. En tunnel som faller rent, er lettere å diagnostisere enn en som fortsetter å sende inn i en død økt.

Ikke les en vellykket stor overføring som bevis for en kryptografisk terskel. Den viser bare at banen og tellerne tålte så mye trafikk.

Dokumenter begge valgene

Oppføringen trenger to linjer: hvordan pakker beskyttes, og når den beskyttelsen erstattes. Legg til hjemmelen for hver verdi, fordi chifferen kan komme fra en distribusjonsstandard mens timeren kommer fra en intern policy. En fremtidig operatør bør ikke måtte utlede noen av dem fra en konfigurasjonsfil.

Hvis kompatibilitet tvinger frem et unntak, begrens det til en versjon og en sluttdato. Et unntak som overlever grunnen sin, blir policyen ingen husker at de valgte.