Броят битове във файла със статичен ключ не е силата на шифъра на OpenVPN

Скенер или колега сочи броя битове, отпечатан във файл със статичен ключ на OpenVPN, и пита защо тунелът не използва шифър с такъв размер. Въпросът звучи разумно, а отговорът не е число: банерът брои съхранения ключов материал, докато шифърът изразходва само частта, която изисква размерът на ключа му. Ако приемем този сбор за настройка на сила, се стига до промени, които не променят нищо. Форматът е създаден да пази повече материал, отколкото използва който и да е отделен алгоритъм.

Тук се смесват два въпроса: колко ключов материал пази файлът и колко силен е договореният шифър. Само вторият описва тунела.

Какво всъщност брои числото в банера

Контейнерът сериализира материала за шифър и материала за HMAC като отделни структури, а двупосочната форма съдържа два такива набора, така че всяка посока да носи собствени ключове. Кодът за запис извежда отпечатаното число от броя сериализирани структури, техния размер и осем бита на байт. Това е аритметика върху съхранение, а не твърдение, че един шифър изразходва всеки съхранен байт. Заглавната част също фиксира максимално разпределение за материала на шифъра, за да не може промяна в библиотека тихо да промени размера на формата.

Сравнете това с ключ от сертификат, където броят битове наистина описва размера на един обект. Ключ RSA с 4,096 бита и файл с ключ, на чийто банер пише 4,096 бита, са различни артефакти с различни задачи и подреждането им като две настройки на едно копче води до лоши изводи.

Два набора ключове в един файл

Всяка половина на файла доставя материал за криптиране и автентикация, защото режимът с предварително споделен ключ защитава пакетите в двете посоки с тези отделни части. Активният шифър използва само байтовете, които изисква размерът на ключа му, а хешът използва собствения си размер на изхода, затова използваемата сила идва от опциите, а не от дължината на файла. Удължаването на шестнадесетичния блок не кара конфигурирания алгоритъм да изразходва повече от него. Редактирането на коментара с по-голямо число променя още по-малко.

Ако наистина искате по-дълъг ключ, настройката за промяна е шифърът или хешът, а генераторът създава каквото изискват избраните алгоритми.

Четенето на профила ви казва кой режим имате

Същият формат на файла служи на две доста различни задачи и само профилът казва коя е вашата. Старият ред secret прави файла единствения ключов материал на тунела, докато tls-auth или tls-crypt го прави защита на контролния канал редом със сертификатите. Никое от двете приложения не го превръща в частен ключ на клиентски сертификат, колкото и подобен да изглежда блокът. Определете опцията и версията, преди да създадете замяна, и използвайте документирания генератор, вместо да добавяте знаци.

Това разграничение решава и реакцията при разкриване. Изтекъл ключ tls-auth не разкрива сесийните ключове, но позволява на нападател да вкарва трафик в контролния канал, затова пак трябва да се смени. Изтекъл ключ secret е по-лош, защото той беше материалът, който пазеше самите данни.

Какво трябва да запише прегледът на сигурността

Запишете три неща поотделно: договорената защита на канала за данни, защитата на контролния канал и как се автентикират партньорите. Ред като data-ciphers AES-256-GCM описва само първото и доклад, който спира там, не може да отговори дали контролният канал е защитен изобщо. Файлът със статичен ключ спада към втората категория, когато се използва с tls-auth или tls-crypt, и към нито една, когато не се използва. Рецензентите, които смесват категориите, искат по-голям файл с ключ, когато всъщност искат по-силен шифър.

Ако файлът е бил разкрит, завъртете го и го разпределете отново по одобрения канал. Добавянето на знаци към компрометирана тайна не е завъртане и оставя разкрития материал валиден.

Пазете записа за завъртането заедно с профила, към който принадлежи. Следващият преглед ще пита кой ключ кой период е защитавал, а банерът няма да отговори на това.