Які пакети OpenVPN захищає дайджест auth?
Опція auth охоплює менше, ніж підказує профіль. Розберіть канал, випадок AEAD і захист керувального каналу, перш ніж задавати політику дайджеста.
Більшість суперечок про дайджести OpenVPN починається не з того пакета. Читати auth SHA256 як «приймати лише тих партнерів, що пропонують SHA256», — перше, від чого треба відвикнути. Опція називає дайджест для певних пакетів, і те, які це пакети, залежить від каналу і від того, чи цей канал є AEAD. Пройдіть чотири питання нижче по порядку; кожне звужує те, що налаштування може означати у вашому розгортанні.
Назвіть канал, який налаштування має захищати
OpenVPN має керувальний канал, що несе трафік рукостискання TLS, і канал даних, що несе корисне навантаження тунелю. Дайджест auth відіграє роль в обох, але не однакову, і профіль рідко робить різницю видимою. Запишіть, який із двох ви намагаєтеся обмежити, перш ніж торкатися файлу конфігурації.
Таблиця нижче — стисла версія того, як та сама опція потрапляє в кожен контекст.
| Context | What the auth digest does |
|---|---|
| Data channel without AEAD | Selects the HMAC digest that authenticates each data packet |
| Data channel with AEAD, such as GCM | Unused for the data channel; the cipher authenticates its own packets |
| Control channel protected by tls-auth | Selects the HMAC digest for that protection, even when data is AEAD |
Перевірте, чи канал даних є AEAD, перш ніж покладатися на нього
Якщо узгоджений шифр даних — AES-GCM або CHACHA20-POLY1305, канал даних автентифікує сам себе, і окремий дайджест не виконує тієї роботи, яку ви, можливо, уявляєте. Обидва є конструкціями AEAD, тому цілісність створюється тією ж операцією, що шифрує навантаження. Це не зниження рівня, але означає, що політика, обґрунтована як «кожен пакет даних — HMAC-SHA256», на цьому тунелі фактично хибна. Підтвердьте узгоджене значення в журналі сервера або у виводі стану клієнта, перш ніж переписувати політику.
Досліджуйте шифр, який справді було узгоджено, а не список у профілі, бо переговори можуть зупинитися на іншому члені набору. data-ciphers AES-256-GCM:AES-128-GCM — це список для переговорів, і обидва записи AEAD, тому жоден із них не витрачає дайджест auth на захист навантаження.
Ставтеся до захисту керувального каналу як до окремого рішення
tls-auth додає HMAC до пакетів керувального каналу й бере свій дайджест з налаштування auth, тому тунель AEAD усе ще може мати осмислено налаштований дайджест. tls-crypt — інша схема з власним фіксованим захистом, тож не припускайте, що вона успадковує кожну властивість tls-auth. Читайте документацію обраного механізму, а не переносьте припущення між ними.
Обидві сторони також мають домовитися про схему й про напрям ключа. Дайджест, що збігається, але файл ключа, використаний у хибному напрямі, дає рукостискання, яке зривається з причин, які налаштування дайджеста пояснити не може.
Тримайте auth окремо від переговорів про шифри та від сертифікатів
Три налаштування постійно плутають: дайджест auth, список шифрів даних і алгоритм підпису сертифіката. Зміна першого не перевипускає сертифікат, не вибирає його дайджест підпису і не створює метод «користувач-пароль». Визначення опцій протоколу в джерелах OpenVPN 2.6 описують кожну в окремому розділі, що є корисною нагадкою: це незалежні регулятори.
Коли партнер відмовляється підключатися після зміни дайджеста, причина зазвичай у невідповідності одного з двох інших налаштувань. Прочитайте обидві сторони, перш ніж змінювати будь-яке з них.
Запишіть політику і порівняйте її з робочими конфігураціями
Заява на рівні флоту має в одному реченні явно назвати дозволені режими каналу даних і обраний захист керувального каналу. Це речення можна перевірити; «ми використовуємо SHA256» — ні. Потім порівняйте його з чинними профілями сервера й клієнта, а не з шаблоном у сховищі.
Заверште записом того, про що кожен тунель справді домовився і який механізм автентифікував його пакети. Видимий рядок auth у профілі — це доказ лише наміру конфігурації, а намір — найдешевша частина перевірки.