Кто-то сообщает, что ключ VPN стал публичным, и эта фраза скрывает три совершенно разные ситуации. Это может быть сертификат CA, который должен быть у каждого клиента, закрытый ключ идентичности, который никогда не должен был покидать одну машину, или общий секрет канала управления, который должны хранить обе стороны. Исправление, срочность и масштаб последствий в каждом случае разные, поэтому первая задача — классификация, а не действие. Ошибётесь с категорией — и каждый следующий шаг станет напрасной работой.

Начинайте с директивы, а не с имени файла

Прочитайте активную конфигурацию и найдите, какая директива указывает на нужный материал. Опции TLS в OpenVPN используют ca для доверенного материала сертификата, cert для сертификата локального узла и key для относящегося к нему закрытого ключа.

Имена файлов ничего не доказывают. Файл с именем key.pem может содержать сертификат, а встроенный блок в профиле может содержать ровно тот же объект, что и отдельный файл на диске. Откройте файл и посмотрите на его заголовок, вместо того чтобы доверять имени. Эта одна проверка снимает большую часть неопределённости в отчёте.

Если профиль — это пакет PKCS#12, распакуйте его в контролируемом месте, чтобы увидеть, что в нём на самом деле. Один пакет может нести сертификат, его цепочку и закрытый ключ, а значит, утечка пакета — это утечка всех трёх.

Запишите классификацию до того, как кто-либо изменит файл: объект, директива, какие узлы его хранят и кто может его читать. Именно от этой фразы зависит остальная часть ответа.

Сертификат CA создан для того, чтобы им делились

Публичный сертификат CA — это материал доверия. Клиентам он нужен для проверки сервера, и его распространение — обычное дело, а не инцидент. Его публикация не публикует закрытый ключ подписи CA, а именно этот объект позволил бы злоумышленнику создавать новые идентичности.

Эту разницу стоит явно зафиксировать в заявке, потому что эти две вещи постоянно путают. Вопрос, на который нужно ответить, — сертификат это или ключ подписи, и быстрый взгляд на содержимое файла решает его. Сертификат содержит открытый ключ и подпись; ключ подписи в нём вообще не встречается.

Распространение всё же требует аккуратности. Клиенты должны получать сертификат по утверждённому пути доставки профилей, а не с сайта для вставки, а сертификат, пришедший по недоверенному маршруту, может быть подменён в пути.

Ключ узла и секрет tls-auth — это не

Закрытый ключ узла — это материал идентичности. Как только он скопирован, сервер больше не может отличить предназначенное устройство от любого, у кого есть копия, потому что демонстрируемым свойством было именно эксклюзивное владение. Продолжать авторизацию или менять её — решение владельца VPN, а не того, кто нашёл файл.

Секрет tls-auth — это третье. Он добавляет аутентификацию HMAC вокруг пакетов канала управления, чтобы неправильно аутентифицированные пакеты отбрасывались до обмена TLS, и это не закрытый ключ узла и не ключ, шифрующий данные приложения.

Если этот общий секрет публичен, барьер, который он давал, исчез для всех, у кого он есть. Из этого не следует, что каждый владелец проходит проверки сертификата и пользователя за ним, поэтому классификация важнее уровня тревоги. Скажите, какой барьер пал, и скажите, какие остались.

Чините роль, которая утекла, а не соседнюю

Общий секрет нельзя снова сделать закрытым, переименовав файл или скрыв ссылку на скачивание. Замена означает создание нового значения и его распространение каждому узлу в рамках согласованного изменения, а замена только одной стороны ломает договорённость для всех, у кого ещё старое значение.

Если идентичность узла была раскрыта, используйте процедуру отзыва и повторной регистрации оператора для этой идентичности. Смена пароля несвязанной учётной записи не аннулирует скопированный сертификат, и замена файла tls-auth тоже.

Прежде чем полагаться на что-либо из этого, подтвердите, что развёрнутый сервер действительно применяет. Список отзыва, который не обновляется, или проверка роли, отключённая во время сбоя, полностью меняют ответ. Читайте работающую конфигурацию, а не копию в репозитории.

Оценивайте прошлый трафик по его собственным условиям

Открытый файл сам по себе не говорит, можно ли расшифровать ранее перехваченные сессии. Это зависит от метода установления ключей, раскрытого материала и того, какие записи существуют, и оба утверждения — «весь трафик потерян» и «ничего не случилось» — догадки без этих фактов.

Не публикуйте ещё одну копию учётных данных, пока спрашиваете, к какой категории они относятся. Вместо этого передайте имена директив и несекретные метаданные по утверждённому пути поддержки.

Полезный вывод называет объект, его роль, утраченную защиту и требуемое согласованное действие. Всё более короткое — это заголовок, а не оценка.

Похожие статьи