Журнал OpenVPN: шифр керівного каналу проти шифру каналу даних

Рядок журналу, у якому вказано DHE-RSA-AES256-SHA, не є підсумком усього з'єднання. Він належить до TLS-рукостискання, яке захищає керівний канал, а трафік усередині тунелю може бути зашифрований зовсім інакше. Подавати його як шифр даних VPN — помилка, якої треба уникати.

Важливі два результати, і вони відповідають на різні питання. Один — узгоджений набір TLS для керівного каналу; другий — шифр даних для пакетів, які переносить тунель.

Два результати, два питання

Керівний канал переносить рукостискання та керівні повідомлення між сторонами. Його шифр обирає стек TLS, тому ім'я дотримується конвенцій TLS. Канал даних переносить користувацький трафік, і його налаштовує власне узгодження шифру OpenVPN.

Вирішіть, на яке питання ви відповідаєте, перш ніж читати будь-який із рядків. Чи зашифровано тунель і чи є рукостискання надійним — це не те саме питання.

Корисним є той фрагмент журналу, де показано обидва рядки. Читайте керівний рядок для версії та набору TLS, а рядок даних — для алгоритму, який справді захищає корисне навантаження.

Розберіть ім'я набору TLS у його власному контексті

В історичному імені у стилі OpenSSL, як-от DHE-RSA-AES256-SHA, кожен складник описує окреме рішення. DHE — це ефемерне узгодження ключів Діффі — Геллмана, RSA — метод автентифікації, AES256 — AES-256 у режимі CBC для записів TLS, а SHA — MAC запису на основі SHA-1.

Останній складник не є відбитком сертифіката, і читати його так — поширена помилка. Ім'я також саме по собі не вказує версію протоколу, бо TLS 1.3 використовує цілком іншу схему найменування. TLS_AES_256_GCM_SHA384 відповідає новішій формі, де завершальний хеш є частиною побудови набору, а не вибором MAC. Застосовуйте розбір за складниками лише до старішого стилю найменування.

Довідник наборів OpenSSL зіставляє ці імена з їхніми визначеннями, якщо якийсь складник незнайомий.

Прочитайте результат каналу даних для переносного трафіку

Для переносного трафіку читайте рядок каналу даних із тієї самої сесії. Список data-ciphers у конфігурації — це дозволений набір, а не доказ, що було узгоджено конкретний алгоритм. Журнал фіксує вибір; конфігурація перелічує меню.

Шифр AEAD, наприклад AES-GCM, має власну перевірку цілісності, тож окремий HMAC каналу даних не входить у цей шлях.

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

Тримайте перевірки ідентичності поза результатом шифру

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

Тримайте ці перевірки в нотатках до огляду поруч із результатом шифру, а не злитими з ним.

Запишіть узгоджені результати поточної сесії

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

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