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

Если файл был раскрыт, смените и заново распространите его по утверждённому каналу. Добавление символов к скомпрометированному секрету не является сменой и оставляет раскрытый материал действительным.

Храните запись о смене вместе с профилем, к которому она относится. Следующая проверка спросит какой ключ защищал какой период, и баннер на это не ответит.