Самопідписаний сертифікат VPN: що він означає і чому довіряє

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

Сертифікат — не сховище довіри

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

Прийняття приходить з іншого місця: файл CA, на який ви вказуєте клієнту, відбиток, який ви звіряєте вручну, або корінь, що вже лежить у сховищі, яке читає клієнт. Розгортання може бути цілком здоровим, хоча його сертифікат провалив би кожен публічний тест. openssl verify проти системного набору повідомить про невідомого видавця, і це повідомлення правильне, а не дефект.

Опція ca OpenVPN — найясніший випадок довіри, обмеженої застосунком. Цей файл називає якорі, які клієнт прийме, і може містити один приватний CA або в невеликому розгортанні власний самопідписаний сертифікат сервера. Версія 2.6 також приймає --peer-fingerprint для закріплення відбитка SHA-256 замість розповсюдження файлу CA. WireGuard стоїть ще далі: у ньому взагалі немає сертифікатів, лише статичний відкритий ключ для кожного партнера, тож питання самопідпису до нього не застосовне.

Де ви встановлюєте довіру, вирішує, хто її успадкує

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

У Debian або Ubuntu розміщення файлу в /usr/local/share/ca-certificates/ і запуск update-ca-certificates змінюють загальносистемний набір. У Windows certutil -addstore -f Root пише до сховища машини і потребує підвищеного командного рядка, тоді як додавання -user націлене на сховище поточного користувача; ці два не взаємозамінні. Firefox тримає власну базу NSS, тож імпорт на рівні ОС може там ніколи не з'явитися.

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

Ви все ще шифруєте без публічного CA

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

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

Довіра видавцю не оминає перевірку імені

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

OpenVPN робить поділ видимим. verify-x509-name закріплює очікуваний суб'єкт через збіг name, name-prefix або subject. remote-cert-tls server вимагає, щоб сертифікат партнера був придатний як серверний сертифікат, що відхиляє сертифікат лише клієнта навіть при довіреному видавцеві. Жодне з налаштувань не замінюється надсиланням файлу CA.

Огляньте сертифікат, перш ніж щось вирішувати:

• openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName показує, хто його видав, для яких імен і до якого часу.
• openssl verify -CAfile ca.crt server.crt перевіряє, чи справді ланцюжок, який ви збираєтеся надіслати, засвідчує лист.
• openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -CAfile ca.crt -verify_return_error працює для кінцевих точок TLS, як-от вебпортал; протокол OpenVPN на 1194 не є звичайним потоком TLS, тому цей тест там не застосовний.

Сертифікат із простроченою датою, без subjectAltName для імені, до якого ви підключаєтеся, або без використання serverAuth не проходить незалежно від того, наскільки ретельно встановлено якір.

П'ять перевірок, перш ніж прийняти один

Порівняйте відбиток каналом, який не є з'єднанням, що ви намагаєтеся полагодити: консоль, наявний інсталятор, підписаний файл конфігурації. openssl x509 -in server.crt -noout -fingerprint -sha256 на сервері та те саме значення в журналі клієнта достатні, щоб знати, що ви дивитеся на один об'єкт.

Далі вирішіть, що ви встановлюєте: один лист чи установу, яка може карбувати більше. Потім вирішіть, куди це йде, і назвіть застосунки, які читають це сховище. Запишіть шлях видалення, поки ще пам'ятаєте його, бо «довірся і йди далі» — це спосіб, у який тимчасовий імпорт стає постійним.

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

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