OpenVPN tls-crypt-v2: що роблять ключ клієнта та загорнутий blob
Профіль tls-crypt-v2 містить ключ керування клієнта та загорнуту копію, яку може відкрити лише сервер. Тримайте кожен об'єкт і кожен крок виведення з експлуатації окремо.
Вставляння профілю tls-crypt-v2 у тікет виглядає безпечно, доки не порахуєш, що містить файл. Ключ каналу керування клієнта стоїть поруч із зашифрованою копією того самого ключа, а третій об'єкт, ключ загортання, ніколи не залишає сервер, що приймає. Ці три відповідають на різні питання про зберігання, спільне використання та виведення з експлуатації. Їх розділення знімає більшість суперечок про політику ще до початку.
Що насправді містить профіль
Клієнтська половина tls-crypt-v2 — це ключ плюс його загорнута копія. Клієнт використовує звичайний ключ для захисту каналу керування і під час налаштування передає загорнуту копію серверу, тож сервер відновлює той самий ключ, не зберігаючи копію у відкритому вигляді для кожного клієнта. Ключ загортання уможливлює це відновлення і належить лише стороні, що приймає. Усе нижче випливає з того, де живуть ці три об'єкти.
| Object | Where it lives | What can open it | What a leak costs |
|---|---|---|---|
| Server wrapping key | accepting servers only | the unwrap step inside the server | every wrapped copy issued to that group becomes readable |
| Wrapped client key | inside the client profile | the server wrapping key | it names a client and exposes its metadata, but not the key inside |
| Client control key | inside the client profile, usable as-is | the client that owns it | someone can open handshakes as that client until the server refuses the key |
Читайте таблицю за зберіганням, а не за назвою, і наслідки проявляться самі. Втрата ключа загортання — дорога подія, бо ніщо в профілі не може його відтворити, а чесне відновлення — це повторний випуск групи. Профіль, що витік, дешевший, але значно поширеніший, адже люди вставляють профілі в тікети, вірячи, що загорнута копія робить файл безпечним для передавання. Два збої вимагають різних відповідей, і саме тому об'єкти тримають окремо.
Чому загорнута копія — не вся історія
Профіль несе придатний клієнтський матеріал разом зі своїм загорнутим двійником, тож захист копії для сервера нічого не каже про захист файлу. Blob безпечний для передавання й небезпечний для публікації. Метадані всередині видимі кожному, хто отримує blob, зокрема тим, хто згодом прочитає тікет, куди його вставили.
Ставтеся до профілю як до облікових даних, а не як до прикладу конфігурації. Файл, що витік, дає власникові робочу особу клієнта, доки сервер не перестане приймати цю особу, і загортання нічого не робить із цим вікном. Випускайте один профіль на клієнта, щоб відкликання лишалося рішенням про один файл, і зберігайте резервну копію ключа загортання окремо від конфігурації сервера, яку він уможливлює. Жодна з цих звичок не виправляє скомпрометований профіль, але обидві визначають, наскільки швидко буде локалізовано наступний.
Де розташований гачок перевірки в рукостисканні
Гачок перевірки запускається до розкриття стека TLS, і його завдання — перевірити метадані, які переносяться в загорнутому blob. Він отримує ці метадані плюс невелике документоване середовище і має менше матеріалу для роботи, ніж гачок автентифікації. Припущення, що він бачить імена користувачів, стан сеансу або змінні плагінів, — звичайний спосіб погано написати цей гачок. Читайте власний розділ посібника гачка, а не позичайте очікування від іншого гачка.
Його код виходу — це рішення: ненульовий результат відмовляє клієнту, а нульовий дозволяє рукостисканню тривати. Тому політика мусить казати, що відбувається, коли метадані відсутні, не розбираються або неочікувані. Спершу напишіть шлях відмови, потім вирішіть, які значення прийнятні.
tls-crypt-v2 /etc/openvpn/server/tcv2-server.key
tls-crypt-v2-verify /etc/openvpn/server/verify-client-metadata.shЦі два рядки — поверхня політики на сервері: один називає ключ загортання, інший називає програму, що оцінює кожного клієнта. Усе цікаве живе в скрипті, який заслуговує на контроль версій і такий самий огляд, як будь-яке інше правило доступу.
Обліковий запис, сертифікат і ключ керування виводяться окремо
Раннє прийняття каналу керування — не автентифікація, бо воно відбувається до перевірки особи TLS і до будь-якої авторизації облікового запису. Вимкнення облікового запису, відкликання сертифіката й відмова клієнтському ключу керування — три дії з трьома механізмами. Розгортання, що виконує лише одну з них, має прогалину, а не політику. Узгодьте всі три навмисно і запишіть, який крок здійснює які повноваження.
Час — друга відмінність. Змінений список приймання діє для нових рукостискань, а вже встановлені сеанси працюють далі, доки щось їх не завершить. Рахувати записи в новому списку доказом того, що старі сеанси закінчилися, — це спосіб, у який вилучений клієнт залишається підключеним годинами.
Неузгоджені повноваження залишають дві діри, які легко знайти на практиці. Обліковий запис може бути вимкнений, поки його ключ керування ще відкриває рукостискання, а сертифікат може бути відкликаний, поки політика метаданих ще приймає того самого клієнта. Обидва — та сама помилка в різних місцях, бо оператор вважав один список усією повнотою повноважень. Покладіть три списки поряд у момент вилучення, і помилка стане видимою.
Випуск і відкликання профілю
Випуск — легша половина: створіть ключ клієнта на стороні, що приймає, передайте профіль рівно одному власникові, тримайте матеріал загортання обмеженим і запускайте ту саму програму перевірки на кожному сервері, що приймає. Дешевий допуск — властивість усієї групи, а не найновішого хоста. Другий сервер зі старішим або слабшим скриптом тихо стає найслабшим шляхом у розгортанні.
Відкликання вимагає трьох кроків у навмисному порядку. Відмовте клієнту в гачку перевірки, щоб нові рукостискання не проходили, відкличте його сертифікат, якщо використовується PKI, і вимкніть обліковий запис, щоб подальшій авторизації не було чого авторизувати. Потім завершіть сеанси, які дозволяв старий допуск, бо вони не помітять жодного з трьох. Відпрацюйте послідовність на клієнті, яким можете дозволити собі пожертвувати.
Метадані в профілі — це вхідні дані для цієї політики, а не доказ того, що контроль доступу вже існує. Проєктний документ OpenVPN 2.6 описує об'єкти й межу, яку вони проводять, а застосування залишається за оператором.