Чому більший ключ OpenVPN не скасовує таймер перевипуску ключів

Вибір AES-256 або довшого ключа нічого не каже про те, як довго цей ключ можна використовувати. Стійкість ключа описує алгоритм; політика перевипуску вирішує, коли сеанс отримає новий ключовий матеріал. Розгортання може вибрати найстійкіший доступний шифр і все одно помилитися щодо оновлення, бо ці два рішення ухвалюються в різних місцях. Їх змішування дає або непотрібну зміну шифру, або сеанс, який тихо переживає свою політику.

Прочитайте налаштування перевипуску, перш ніж торкатися шифру, і читайте обидві сторони, коли це робите.

Стійкість ключа й термін життя ключа відповідають на різні питання

Шифр і розмір ключа обмежують, наскільки дорогою була б атака на перехоплений трафік. Інтервал перевипуску обмежує, скільки трафіку захищає один ключ і як довго скомпрометований ключ залишається корисним. Це незалежні налаштування, і стійкіший шифр не подовжує безпечний термін життя сеансу. Більшість порад «використовуйте AES-256» мовчать про оновлення, бо оновлення — це питання політики, а не вибір алгоритму.

Запишіть і те й те в нотатки про розгортання: що захищає канал даних і що запускає заміну його ключів.

Перевипуск має три тригери, і будь-яка сторона може їх запустити

OpenVPN 2.6 документує окремі тригери повторного узгодження за байтами, пакетами та минулим часом. Тригер за часом — той, який більшість розгортань залишає за замовчуванням, а отже тихий тунель усе одно перевипускає ключ за розкладом. Будь-яка сторона може почати обмін, а сторона, яка його не почала, слідує за нею. Тому зміна таймера на одній стороні не задає поведінку сеансу; чинним є значення тієї сторони, яка починає першою.

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

Перевипуск розкриває процес автентифікації

Повторне узгодження — це нове рукостискання TLS, тобто шлях автентифікації проходить знову. Розгортання з одноразовими кодами, апаратними токенами або викликом RADIUS дізнаються про це важким шляхом: перше з'єднання працює, а за годину сеанс помирає, коли друге рукостискання просить уже використаний код. auth-gen-token існує, щоб закрити цю прогалину: сервер видає короткоживучий токен для повторного узгодження замість вимоги нового інтерактивного входу.

Ставтеся до цього як до проблеми робочого процесу, яку треба вирішити з оператором, а не як до доказу, що оновлення слід вимкнути.

Перевіряйте оновлення під навантаженням, а не в хвилинному сеансі

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

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

Задокументуйте обидва вибори

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

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