Можно ли делиться открытым ключом VPN? Проверьте три вещи
Публикация открытой половины — это и есть работа протокола; публикация закрытой половины означает передачу личности. Три проверки определяют, какое значение у вас в руках.
Вы можете отдать свой открытый ключ VPN партнёру, провайдеру или на форум, и туннель продолжит работать. А закрытый ключ нельзя передать даже сотрудникам поддержки, не передав личность, которую этот ключ доказывает. Решение редко остаётся таким однозначным: люди путают, на какую половину пары они смотрят, а некоторые развёртывания относятся к открытому значению как к имени. Три проверки расставляют всё по местам: какая половина у вас, к чему развёртывание её привязывает и сколько стоит замена.
Проверка первая: какая половина пары лежит в буфере обмена
Асимметричные ключи существуют парами, и направление вывода — вся суть. В WireGuard закрытый ключ — это 32 случайных байта, а открытый вычисляется из него; в обратную сторону это не работает. wg genkey записывает закрытое значение, wg pubkey выводит открытое, и только второе место — в сообщении партнёру.
wg genkey | tee private.key | wg pubkey > public.key
chmod 600 private.key
openssl x509 -noout -pubkey -in server.crt
Мир сертификатов использует то же разделение, но с большим числом движущихся частей. Серверный сертификат несёт открытый ключ и имена, и подписан закрытым ключом CA, который никогда не покидает CA. Клиенту, проверяющему этот сервер, нужен сертификат CA, который открыт, а закрытый ключ подписи CA ему совершенно не нужен.
Если вы не уверены, какое значение держите, ищите маркер, а не имя файла. Блок PEM, начинающийся с -----BEGIN PRIVATE KEY-----, или более старая форма BEGIN RSA PRIVATE KEY, — это секретная половина. Значение, которое можно вставить без этого маркера, — кандидат на передачу, с учётом следующих двух проверок.
Проверка вторая: к чему развёртывание привязывает это открытое значение
Криптографическая безопасность и анонимность — разные свойства. Открытый ключ партнёра WireGuard — это стабильный идентификатор внутри развёртывания: конфигурация сервера его перечисляет, рукопожатие его называет, и администратор, читающий журналы, видит одну и ту же строку каждый раз, когда этот партнёр подключается. Опубликовав ключ рядом с вопросом о своей настройке, вы связали эту строку со всем остальным в публикации.
Сертификаты раскрывают личность по своей конструкции. Subject и subject alternative name читаемы, а для публично доверенных TLS-сертификатов сам сертификат публикуется в журналах Certificate Transparency, доступных для поиска. Ничто из этого не раскрывает закрытый ключ, и всё это раскрывает связь.
Именно здесь развёртывания различаются, и это решает ответ. Одноразовый тестовый партнёр на лабораторном сервере — не то же самое, что ключ, идентифицирующий межсайтовую конечную точку компании, хотя байты выглядят одинаково.
Проверка третья: что можно отозвать и как быстро
Третья проверка полностью разделяет половины. Опубликованный открытый ключ можно заменить по своему графику. Опубликованный закрытый ключ отозвать нельзя: удаление вашей копии не затрагивает уже снятые копии, и каждый партнёр, который ему доверял, теперь доверяет тому, что есть у постороннего.
Отзыв — это действие с конфигурацией, а не криптографическое. WireGuard не поставляет список отзыва, поэтому вы удаляете партнёра:
wg set wg0 peer <peer-public-key> remove
# then delete the [Peer] block from the config so it does not return on restart
OpenVPN развёртывания на сертификатах отзывают сертификат и публикуют CRL, который сервер действительно проверяет через crl-verify. Без этой директивы список отзыва — просто украшение. В обоих случаях порядок один: выпустить замену, распространить её по поддерживаемому каналу, затем вывести из обращения старую личность.
Ошибки, которые возникают, когда три проверки смешивают в одну
Большинство реальных утечек — это не решение человека опубликовать закрытый ключ. Это целый профиль, вставленный на форум: .conf WireGuard с PrivateKey строкой, .ovpn пакет со встроенным блоком ключа, или скриншот окна клиента, куда случайно попало поле ключа. Открытое значение, вероятно, было в порядке; оно путешествовало вместе с той частью, которая не была.
Процессы поддержки — второй источник. Ни один законный шаг проверки не требует вашего закрытого ключа, потому что другая сторона выводит нужное из открытой половины. Когда форма или человек просит закрытое значение, правильный ответ — открытое значение плюс локальная команда, которая его создаёт.
Журналы и скриншоты относятся к той же категории. Диагностический вывод может нести материал ключа, идентификаторы сессий и внутренние адреса, и публикация всего этого ради ответа на один вопрос меняет небольшое удобство на большую экспозицию.
Если закрытое значение утекло, выведите личность из обращения
Если закрытое значение всё же вышло, считайте эту личность выведенной из обращения. Сгенерируйте новую пару, установите открытую половину туда, где партнёры её ждут, удалите старого партнёра или отзовите старый сертификат, и проверьте места, где вы это публиковали. Вы не можете удалить копии, которые не контролируете, поэтому удаление — про будущее, а не про прошлое.
Затем запишите распространение: какой ключ принадлежит какому устройству, у кого есть копия, как доставляется замена и кто удаляет выведенного из обращения партнёра. Именно эти части забывают, и именно они определяют, как долго утечка остаётся полезной.