tls-auth проти tls-crypt: що захищає кожен у OpenVPN

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

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

Що насправді захищає спільний ключ

Ключ, який використовують ці параметри, належить керуючому каналу: обміну, який узгоджує параметри, доводить ідентичності та виводить ключі даних. Це заздалегідь розділений секрет, який має бути в обох сторін до того, як рукостискання продовжиться. Оскільки він стоїть перед перевірками ідентичності, неправильний ключ зупиняє розмову раніше, ніж це зробив би неправильний пароль. Саме цей порядок пояснює, чому відмова виглядає так тихо.

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

tls-crypt іде далі: він не лише засвідчує захищений керуючий трафік, а й шифрує його. Вміст сертифікатів, узгоджені назви шифрів та інші деталі рукостискання більше не видно в мережі, і спостерігач без ключа не може побачити навіть, яка версія TLS використовується. Для розгортання, яке боїться розкрити свій відбиток VPN, ця властивість і є головною причиною вибрати його. Але це все ще груповий секрет, а не облікові дані окремого користувача.

Жоден механізм не видає ідентичностей. Спільний ключ це груповий секрет, і кожен, у кого він є, може пройти цей рівень перевірки.

Чим різняться два варіанти

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

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

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

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

Чому розбіжність виглядає так, ніби нічого не відбувається

Коли спільний матеріал не збігається, інша сторона відкидає пакети, не повідомляючи відправникові причину. Читати нічого: пакет так і не дійшов до рівня, який створив би помилку автентифікації.

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

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

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

Що ще потрібно налаштовувати окремо

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

Вони також не вибирають шифр даних. Це окреме узгодження, яким керують налаштування каналу даних на обох сторонах, і тунель, захищений за допомогою tls-crypt, усе одно може використовувати шифр, який ви не планували.

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