Statični ključ ili TLS za OpenVPN vezu između dva peera?

Dva računala koja razgovaraju samo jedno s drugim mogu zadržati tu topologiju i ipak dobiti pregovarane ključeve za promet. Oblik mreže i način zaštite neovisni su izbori, a njihovo miješanje navodi ljude da pokušaju rotirati statičnu tajnu zamjenom datoteke dok oba daemona nastavljaju raditi. Zamjena datoteke ključa ispod para koji radi ne rotira ništa. Statični način rada, koji OpenVPN 2.6 označava kao zastario, drži jedan ključ za cijeli životni vijek tunela, pa se datoteka na disku i ključ u memoriji ponovno slažu tek nakon ponovnog pokretanja oba kraja. Ako je automatska obnova uvjet, način zaštite mora se promijeniti.

Što statični način rada ne može

U tajnom načinu rada oba peera dijele unaprijed podijeljeni ključ koji izravno šifrira i autentificira tunel. Nema rukovanja, pa nema mehanizma da bilo koja strana predloži novi ključni materijal, dokaže identitet ili se oporavi od neslaganja bez intervencije operatora. Oba svojstva proizlaze iz odsutnosti kontrolnog kanala, a ne iz nedostajuće opcije, i nijedna konfiguracijska zastavica ga ne dodaje ovom načinu rada.

OpenVPN 2.6 priručnik izričito navodi da ključ ostaje dok se ne generira novi. To je prihvatljivo za laboratorijsku vezu ili fiksni par uređaja s dokumentiranim postupkom rotacije, a neprihvatljivo svugdje gdje je dugotrajna tajna stvarni rizik. Zamjena datoteke ne stvara novi ključ za par koji radi; ona stvara dva peera koji se ne slažu. Zato zamjena datoteke dodaje prekid rada bez dodavanja rotacije.

Također nema pojma o identitetu peera izvan posjedovanja datoteke. Svatko tko drži ključ je peer, i ništa u tunelu ne bilježi koja je strana koja, pa je opoziv sve ili ništa.

Prelazak na TLS bez redizajna veze

TLS način rada dodaje kontrolni kanal, a s njim i mogućnost pregovaranja ključeva podatkovnog kanala. U postavljanju od točke do točke jedna strana preuzima ulogu poslužitelja, a druga ulogu klijenta, ali topologija ostaje veza između dva peera: svaka strana zna krajnju točku one druge, i ne pojavljuje se nikakav bazen ni višekorisnička usluga. Uloge su detalj rukovanja, a ne nova arhitektura.

Dajte svakom računalu vlastiti identitet. Svaka strana treba certifikat i privatni ključ, sidro povjerenja koje provjerava drugu stranu, i pravilo provjere peera koje imenuje koga se očekuje. Ne koristite ponovno privatni ključ jednog peera na drugom radi uštede vremena; to pretvara dva identiteta u jedan i uklanja mogućnost da se bilo koja strana opozove zasebno. Upis je mjesto gdje se to ispravno rješava, jer kasnije ispravljanje znači ponovno izdavanje certifikata.

Držite mrežni ugovor nepromijenjenim dok se zaštita mijenja. Iste adrese tunela, rute i dopuštene usluge trebaju vrijediti prije i poslije, tako da kvar tijekom migracije bude problem zaštite, a ne prerušeno iznenađenje u usmjeravanju. Zapišite adrese i rute prije promjene; njihova kasnija usporedba brža je od rekonstrukcije po sjećanju.

Neka postavljanja štite i kontrolni kanal vlastitim statičnim ključem, koji se ne rotira s podatkovnim kanalom. Taj ključ čuva rukovanje, a ne korisni teret, pa njegov kompromis izlaže pregovaranje, a ne promet. Čuvajte ga odvojeno od materijala podatkovnog kanala i dajte mu datum zamjene kojeg posjeduje imenovana osoba. Njegova rotacija znači ponovno pokretanje oba peera u koordiniranom prozoru, zato zaslužuje unos u kalendaru, a ne u sjećanju.

Tko obnavlja što, i kada

U TLS načinu rada obnova je vođena konfiguriranim ograničenjima: vremenskim intervalom, brojem bajtova ili brojem paketa. Dokumentirana vremenska kontrola je ono na što se većina postavljanja oslanja, a niža efektivna vrijednost na dva peera može pokrenuti zamjenu, pa podizanje samo na jednoj strani neće zadržati događaj. Ograničenja po volumenu postoje zato što zauzeta veza može potrošiti ključ mnogo prije nego sat. Nijedno ograničenje nije provjera zdravlja i nijedno vam ne kaže da je obnova uspjela.

Zato je dijagnosticiranje ponavljajućeg ponovnog pregovaranja iz jedne konfiguracijske datoteke zavaravajuće. Pročitajte postavke na oba peera, pa pogledajte prijelaz u dnevniku umjesto da pretpostavite kvar. Obnova koja se čisto završi izgleda kao kratki izljev prometa kontrolnog kanala, a ne kao prekid veze.

Držite objekte odvojeno u glavi. Certifikat dokazuje dugoročni identitet i zamjenjuje se po rasporedu koji kontrolirate. Ključ podatkovnog kanala osvježava se automatski, a zasebna razmjena autentifikacije, ako je postavljanje zahtijeva, slijedi politiku računa i može trebati vlastite dogovore za kasnije razmjene.

Potpuno onemogućavanje obnove, postavljanjem intervala na nulu, nije rješenje za bučan dnevnik. Ono pretvara zdrav događaj životnog ciklusa u trajni ključ, što vas vraća na svojstvo koje ste pokušavali ostaviti za sobom.

Prihvaćanje promjene

Izgradite novu konfiguraciju iz podržanog primjera instaliranog izdanja, a ne iz starog minimalnog isječka čiji su algoritmi i putanje datoteka naslijeđeni odnekud drugdje. Uskladite prebacivanje tako da se oba peera promijene zajedno, i držite odobren put oporavka u slučaju da jedna strana ne uspije startati. Spustite vezu namjerno umjesto da čekate prekid da biste testirali vraćanje. Vraćanje koje ste uvježbali vrijedi više od vraćanja koje ste opisali.

Testirajte tri stvari: početna provjera identiteta uspijeva, predviđeni tok aplikacije radi, i kontrolirana obnova se događa bez gubitka prometa. Zatim pročitajte prijelaz u dnevniku zbog onoga što stvarno dokazuje: novi identifikator ključa znači da su peeri završili zamjenu, a ne da se tunel ponovno povezao. Tretirajte to kao dokaz jednog koraka, i provjerite brojače prometa prije nego migraciju proglasite završenom.

Ono što bi obećanje nultog prekida sakrilo jest kvar koji još niste vidjeli. Obnova koja ne uspije, certifikat koji istekne ili kvar na putu još uvijek mogu poremetiti vezu, i nijedno od toga nije isključeno čistim testnim prolazom. Svojstvo za koje vrijedi projektirati uže je i korisnije: rutinska zamjena ključeva prestaje biti ručna zamjena datoteke.