Miért nem szünteti meg a nagyobb OpenVPN-kulcs az újrakulcsolási időzítőt
A titkosítás erőssége és a kulcs élettartama külön döntés. Ellenőrizze a bájt-, csomag- és időalapú kiváltókat, majd tesztelje az újrakulcsolást a valódi bejelentkezési folyamaton.
Az AES-256 vagy egy hosszabb kulcs választása semmit sem mond arról, meddig használható az a kulcs. A kulcs erőssége az algoritmust írja le; az újrakulcsolási szabályzat dönti el, mikor származtat a munkamenet új kulcsanyagot. Egy telepítés választhatja a legerősebb elérhető titkosítást, és mégis tévedhet a megújítás terén, mert a két döntés különböző helyeken születik. Ha összekeverik őket, vagy szükségtelen titkosításváltás lesz belőle, vagy olyan munkamenet, amely csendben túlélia saját szabályzatát.
Olvassa el az újrakulcsolási beállításokat, mielőtt hozzányúl a titkosításhoz, és olvassa el mindkét felet, amikor ezt teszi.
A kulcs erőssége és a kulcs élettartama más-más kérdésre válaszol
A titkosítás és a kulcsméret korlátozza, mennyire lenne költséges egy támadás az elfogott forgalom ellen. Az újrakulcsolási intervallum korlátozza, mennyi forgalmat véd egy kulcs, és meddig marad hasznos egy kiszivárgott kulcs. Ezek független beállítások, és egy erősebb titkosítás nem hosszabbítja meg a munkamenet biztonságos élettartamát. A legtöbb útmutató, amely azt mondja, „használjon AES-256-ot”, hallgat a megújításról, mert a megújítás szabályzat kérdése, nem algoritmusválasztás.
Rögzítse mindkettőt a telepítési feljegyzésekben: mi védi az adatcsatornát, és mi váltja ki a kulcsainak cseréjét.
Az újrakulcsolásnak három kiváltója van, és bármelyik fél kiválthatja őket
OpenVPN 2.6 külön kiváltókat dokumentál az újratárgyaláshoz bájtok, csomagok és eltelt idő alapján. Az időalapú kiváltó az, amelyet a legtöbb telepítés az alapértéken hagy, ami azt jelenti, hogy a csendes alagút is ütemezés szerint újrakulcsol. Bármelyik fél indíthatja a cserét, és a fél, amelyik nem indította, követi. Ezért az időzítő egyoldalú módosítása nem határozza meg a munkamenet viselkedését; a tényleges értéket az a fél adja, amelyik először kezdeményez.
A bájt- és csomagalapú kiváltók nagy áteresztőképességű vagy kis csomagos terhelésnél számítanak, ahol a csak időre épülő szabályzat egy kulcsot a tervezettnél jóval több adat védelmére engedne. Ha ezek a számlálók kikapcsolva maradnak, mondja ki ezt szándékosan a feljegyzésekben, ahelyett hogy az alapértéket vizsgálatlanul hagyná.
Az újrakulcsolás feltárja a hitelesítési folyamatot
Az újratárgyalás új TLS kézfogás, ami azt jelenti, hogy a hitelesítési útvonal újra lefut. Az egyszeri kódokat, hardvertokeneket vagy RADIUS-kihívást használó telepítések ezt a nehéz úton tapasztalják meg: az első kapcsolat működik, és a munkamenet egy órával később meghal, amikor a második kézfogás már felhasznált kódot kér. auth-gen-token azért létezik, hogy áthidalja ezt a rést azzal, hogy a kiszolgáló rövid élettartamú tokent ad ki az újratárgyaláshoz ahelyett, hogy új interaktív bejelentkezést követelne.
Tekintse ezt az üzemeltetővel megoldandó munkafolyamat-problémának, nem annak bizonyítékaként, hogy a megújítást ki kell kapcsolni.
Terhelés alatt tesztelje a megújítást, ne egyperces munkamenetben
Az az átvételi teszt, amely csatlakozik, egyszer pingel és bontja a kapcsolatot, soha nem éri el az újrakulcsolást. Futtasson elég hosszú munkamenetet a beállított kiváltó átlépéséhez, tartson közben folyamatosan egy átvitelt, és figyelje mindkét fél naplóit az új kézfogásért. Utána tesztelje a hibaút: mit tesz az ügyfél, ha az újratárgyalás nem tud befejeződni. Az az alagút, amely tisztán megszakad, könnyebben diagnosztizálható, mint amelyik tovább küld egy halott munkamenetbe.
Ne olvasson bele egy sikeres nagy átvitelbe kriptográfiai küszöb bizonyítékát. Az csak azt mutatja, hogy az útvonal és a számlálók kibírtak ennyi forgalmat.
Dokumentálja mindkét választást
A feljegyzésnek két sorra van szüksége: hogyan védik a csomagokat, és mikor cserélik le ezt a védelmet. Adja hozzá az egyes értékek jogosultságát, mert a titkosítás jöhet egy disztribúció alapértékéből, míg az időzítő belső szabályzatból. Egy jövőbeli üzemeltetőnek egyiket sem kellene konfigurációs fájlból kikövetkeztetnie.
Ha a kompatibilitás kivételt kényszerít ki, korlátozza azt egy verzióra és egy záró dátumra. Az a kivétel, amely túléli az okát, az a szabályzat lesz, amelyre senki sem emlékszik, hogy ő választotta.