Zakaj večji ključ OpenVPN ne odpravi časovnika obnove ključev

Izbira AES-256 ali daljšega ključa ne pove nič o tem, kako dolgo se ta ključ sme uporabljati. Moč ključa opisuje algoritem; politika obnove odloča, kdaj seja izpelje novo ključno gradivo. Uvedba lahko izbere najmočnejšo razpoložljivo šifro in se pri obnovi vseeno zmoti, ker se odločitvi sprejmeta na različnih mestih. Njuno mešanje povzroči bodisi nepotrebno spremembo šifre bodisi sejo, ki tiho preživi svojo politiko.

Preberite nastavitve obnove, preden se dotaknete šifre, in pri tem berite obe strani.

Moč ključa in življenjska doba ključa odgovarjata na različni vprašanji

Šifra in velikost ključa omejujeta, kako drag bi bil napad na prestreženi promet. Interval obnove omejuje, koliko prometa varuje en ključ in kako dolgo ostane kompromitiran ključ uporaben. To so neodvisne nastavitve in močnejša šifra ne podaljša varne življenjske dobe seje. Večina smernic, ki pravijo »uporabite AES-256«, molči o obnovi, ker je obnova vprašanje politike in ne izbira algoritma.

Zapišite oboje v zapiske o uvedbi: kaj varuje podatkovni kanal in kaj sproži zamenjavo njegovih ključev.

Obnova ima tri sprožilce in vsaka stran jih lahko sproži

OpenVPN 2.6 dokumentira ločene sprožilce za ponovno pogajanje glede na bajte, pakete in pretečeni čas. Časovni sprožilec je tisti, ki ga večina uvedb pusti na privzeti vrednosti, kar pomeni, da tihi tunel še vedno obnavlja ključ po urniku. Vsaka stran lahko začne izmenjavo, stran, ki je ni začela, pa ji sledi. Zato sprememba časovnika na eni strani ne določa vedenja seje; veljavna vrednost je tista na strani, ki začne prva.

Sprožilci po bajtih in paketih so pomembni pri obremenitvah z visoko prepustnostjo ali majhnimi paketi, kjer bi politika samo po času pustila enemu ključu varovati veliko več podatkov, kot je bilo mišljeno. Če ti števci ostanejo izklopljeni, to namenoma povejte v zapiskih, namesto da bi privzeto vrednost pustili nepreverjeno.

Obnova razkrije potek preverjanja pristnosti

Ponovno pogajanje je novo rokovanje TLS, kar pomeni, da pot preverjanja pristnosti znova teče. Uvedbe z enkratnimi kodami, strojnimi žetoni ali izzivom RADIUS to odkrijejo na težji način: prva povezava deluje, seja pa umre uro pozneje, ko drugo rokovanje zahteva že uporabljeno kodo. auth-gen-token obstaja zato, da premosti to vrzel tako, da strežniku omogoči izdajo kratkotrajnega žetona za ponovno pogajanje, namesto da bi zahteval novo interaktivno prijavo.

Obravnavajte to kot težavo delovnega toka, ki jo je treba rešiti z upravljavcem, ne kot dokaz, da je treba obnovo izklopiti.

Preizkusite obnovo pod obremenitvijo, ne v enominutni seji

Sprejemni preizkus, ki se poveže, enkrat pingne in prekine, nikoli ne doseže obnove. Zaženite sejo, dovolj dolgo, da presežete nastavljeni sprožilec, ves čas ohranjajte prenos in spremljajte dnevnike obeh strani zaradi novega rokovanja. Nato preizkusite pot okvare: kaj odjemalec naredi, če ponovnega pogajanja ni mogoče dokončati. Tunel, ki pade čisto, je lažje diagnosticirati kot tistega, ki še naprej pošilja v mrtvo sejo.

Uspešnega velikega prenosa ne berite kot dokaz kriptografskega praga. Kaže le, da sta pot in števca zdržala toliko prometa.

Dokumentirajte obe izbiri

Zapis potrebuje dve vrstici: kako so paketi zaščiteni in kdaj se ta zaščita zamenja. Dodajte pristojnost za vsako vrednost, ker lahko šifra prihaja iz privzete nastavitve distribucije, časovnik pa iz interne politike. Prihodnji upravljavec ne bi smel nobenega od njiju sklepati iz konfiguracijske datoteke.

Če združljivost zahteva izjemo, jo omejite na različico in končni datum. Izjema, ki preživi svoj razlog, postane politika, za katero se nihče ne spomni, da jo je izbral.