Кількість бітів у файлі статичного ключа — це не сила шифру 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, і до жодної, коли не використовується. Рецензенти, які змішують категорії, просять більший файл ключа тоді, коли насправді хочуть сильніший шифр.

Якщо файл було розкрито, змініть його та поширте заново затвердженим каналом. Додавання символів до скомпрометованого секрету не є зміною, і воно залишає розкритий матеріал чинним.

Тримайте запис про зміну разом із профілем, до якого він належить. Наступна перевірка запитає який ключ захищав який період, і банер на це не відповість.