OpenVPN без CA: як peer-fingerprint перевіряє партнерів
Відбиток закріплює один сертифікат, а не спільний секрет. Простежте, що охоплює дайджест, як кожна сторона будує свій список дозволених і скільки коштує оновлення.
Невелике розгортання тягнеться до відбитків, бо засвідчувальний центр виглядає як інфраструктура, на яку ні в кого немає часу. Інстинкт розумний, а короткий шлях, який люди обирають замість нього—копіювання одного секрету каналу даних на обидва кінці—ні. Налаштування peer-fingerprint зберігає структуру TLS недоторканою: кожна сторона досі тримає власний закритий ключ і сертифікат, і кожна сторона досі перевіряє іншу. Змінюється те, де перевірка закріплена: від довіреного видавця до короткого списку закріплених дайджестів. Оскільки дайджест охоплює весь сертифікат, а не ім’я, оновлення стає операцією, яка справді забирає час.
До чого відбиток насправді зобов’язує
Відбиток сертифіката — це дайджест усього сертифіката в кодуванні DER, а не його відкритого ключа і не імені його суб’єкта. Тому два сертифікати з однаковими іменами й одним і тим самим ключем, але різними термінами дії мають різні відбитки. Це робить закріплення точним і це ж робить оновлення незручним. Закріплення не може означати довіру до ключа взагалі, бо воно називає один артефакт в один момент його життя. Дайджест може знати будь-хто, і саме знання нічого не доводить.
openssl x509 -in server.crt -noout -fingerprint -sha256
openssl x509 -in client-07.crt -noout -fingerprint -sha256
Володіння відповідним закритим ключем — це те, що доводить, що партнер тримає цей сертифікат, а дайджест — це те, як інша сторона вирішує, чи очікувала вона цей сертифікат узагалі. Це розділення є причиною, чому цей проєкт не стара схема зі спільним секретом: спільний ключ автентифікує будь-кого, хто знає ті самі байти, тоді як закріплення автентифікує один сертифікат. Інший пристрій отримує власний запис, а не копію того самого секрету, що є малою різницею у файлах і великою в масштабі шкоди.
Карта взаємна, а не симетрична
Кожному кінцю потрібні дві речі: власний закритий ключ із сертифікатом і заява про те, які сертифікати партнерів він прийме. У клієнті ця заява — це дайджест сертифіката сервера; у сервері це список дайджестів зареєстрованих клієнтів. Офіційний приклад для невеликої конфігурації для Community 2.6 показує влаштування з peer-fingerprint, і його варто прочитати перед вибором цієї моделі довіри для реального розгортання. Два напрямки не є одним перевернутим списком, і вони не відмовляють в один момент.
| Verification direction | What is pinned | What never leaves that endpoint | How a wrong pin shows up |
|---|---|---|---|
| Client checks the server | One digest, for the server certificate | The server private key | The client aborts during the TLS handshake |
| Server checks the client | A digest per enrolled client | Each client private key | The server rejects the peer before a tunnel exists |
Додавання пристрою редагує список дозволених на сервері, не копіюючи закритий матеріал наявного клієнта і нікуди не переміщуючи ключ сервера. Два напрямки також відмовляють незалежно, що корисно під час діагностики: та сторона, яка закриває рукостискання, і є сторона, чиє очікування не справдилося. Якщо клієнт відхиляє сервер, дайджест не збігається з поданим сертифікатом. Якщо сервер відхиляє клієнта, дайджесту цього клієнта немає в списку, або клієнт подає інший сертифікат, ніж зареєстрований.
Реєстрація: як приєднується новий пристрій
Згенеруйте ключ і сертифікат нового пристрою там, де житиме закритий ключ, потім перенесіть лише публічний артефакт тій стороні, яка має його закріпити. Передайте очікуваний дайджест каналом, якому ви вже довіряєте, і порівняйте сертифікат цілком, а не знайоме на вигляд ім’я. Дайджест, скопійований із того самого неперевіреного завантаження, що й сертифікат, доводить лише те, що два файли узгоджуються один з одним. Це перевірка узгодженості, а не особи, і це найтихіший спосіб послабити цей проєкт.
На сервері додавання дайджесту — це зміна конфігурації, яка проходить через звичайний менеджер і супроводжується перепідключенням. Переконайтеся, що новий пристрій підключається, а пристрій, чий дайджест видалено, більше не підключається. Тест, що покриває лише позитивний випадок, залишає список дозволених неперевіреним, і саме в такому стані ви будете через пів року.
Оновлення — дорогий момент
Кожен сертифікат спливає, і новий сертифікат має новий дайджест, навіть коли ключ та імена залишаються тими самими. За видавця оновлення прозоре для партнерів, які довіряють цьому видавцеві; за закріплення це подія реєстрації для кожного партнера, який закріплює сертифікат.
Плануйте порядок до дати спливу, а не після неї. Розподіліть новий дайджест сторонам, які його перевіряють, застосуйте зміну і лише потім замініть сертифікат на кінцевій точці. Такий порядок не залишає вікна, у якому дві сторони розходяться щодо того, який сертифікат чинний. Тримайте під переглядом і сам список, бо закріплений список накопичує записи пристроїв, виведених з експлуатації місяці тому. Кожен застарілий запис — це особа, яка все ще автентифікується, якщо її ключ виживе, тому видалити один — це дія з безпеки, а не прибирання.
Чого карта довіри не вирішує
Автентифікація — це один шар, і закріплена карта нічого не каже про пул адрес, просунуті маршрути, MTU шляху чи політику брандмауера. Вони залишаються окремою конфігурацією з окремими режимами відмови. Тунель, що автентифікується і не пропускає трафік, — це інше розслідування, ніж той, що ніколи не піднімається.
Карта також не масштабується безмежно, і PKI на основі видавця — це те, до чого приходять більші розгортання. Ця перевага про експлуатацію, а не про криптографію, бо додавати й виводити особи через один орган дешевше, ніж редагувати список на кожному партнері в міру зростання флоту. Там, де реалізація клієнта не підтримує цю опцію, відповідь — сумісна модель довіри, яку цей клієнт документує, або підтримувана заміна. Придушення попередження про перевірку не додає цієї підтримки, і вся цінність проєкту в тому, що перевірка все ще відбувається.