Трасування керуючих пакетів OpenVPN: tls-auth до TLS

Збій tls-auth зазвичай описують як проблему рукостискання, хоча ним він ніколи не був. HMAC перевіряється на керуючому пакеті до будь-якої обробки TLS, тому невідповідний ключ або напрямок дає збій, що виглядає як проблема сертифіката і вирішується двома рівнями раніше. Якщо розглядати конверт як окремий об'єкт, діагностика стає короткою: прочитайте поля, переконайтеся, що перевірка спрацьовує рано, і порівняйте три речі, про які мають домовитися обидві сторони.

Читайте конверт у тому порядку, у якому він збирається

Керуючий пакет несе ідентифікатор сеансу, необов'язковий HMAC tls-auth, відомості про повтор і підтвердження, а також надійний ідентифікатор повідомлення, після чого йде корисне навантаження типу повідомлення. Якщо повідомлення є повідомленням рукостискання, корисним навантаженням виявляється шифротекст TLS. Увесь зв'язок саме такий: матеріал TLS подорожує всередині повідомлення, яке конверт уже захищає. Зверніться до довідника з мережевого протоколу OpenVPN, де поля керуючого каналу перелічені в цьому порядку.

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

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

Покажіть, що перевірка спрацьовує до рукостискання

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

Підвищте докладність демона і спостерігайте за керуючим каналом, а не за пристроєм tun:

openvpn --config /etc/openvpn/server.conf --verb 6

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

Обробка напрямку також тут. Коли статичний файл ключа використовується з tls-auth, дві сторони займають протилежні напрямки ключа, і протокол використовує цей поділ, щоб перехоплений пакет не можна було відбити назад до його відправника. Обернений напрямок залишає ключ тим самим і все одно провалює кожен пакет. Змінюйте по одній стороні за раз, потім перезапустіть обидва демони, щоб пара завантажилася разом.

Узгодьте ключ, напрямок і digest на обох сторонах

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

grep -E 'tls-auth|tls-crypt|key-direction|auth ' /etc/openvpn/server.conf

Створюйте спільний секрет інструментом, а не редактором, і тримайте права жорсткими:

openvpn --genkey secret /etc/openvpn/ta.key
chmod 600 /etc/openvpn/ta.key

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

Не плутайте tls-auth з tls-crypt. Обидва захищають керуючий канал, але tls-crypt ще й шифрує його та приховує рукостискання від спостерігачів, і замінює поділ напрямків власною обробкою ключів. Профіль з одним не працюватиме з партнером, налаштованим на інше, і жодне налаштування digest не закриває цю прогалину.

Відтворюйте тег лише з реального формату

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

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

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

Відкотіть розбіжність, не знімаючи захист

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

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

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