Что на самом деле защищает парольная фраза на закрытом ключе VPN

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

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

Один диалог, несколько разных секретов

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

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

Что охватывает шифрование на диске

Зашифрованный ключ PEM бывает двух видов, и заголовок говорит, какой у вас. Современная форма PKCS#8 начинается с -----BEGIN ENCRYPTED PRIVATE KEY-----; старая форма PEM, всё ещё распространённая в старых настройках OpenVPN, начинается с -----BEGIN RSA PRIVATE KEY----- и содержит Proc-Type: 4,ENCRYPTED и строку DEK-Info сразу под ней. Файл хранит закрытый ключ зашифрованным под ключом, производным от вашей парольной фразы, обычно через KDF на основе пароля с указанным числом итераций или рабочим фактором. Документация OpenSSL pkey описывает форматы и параметры парольной фразы, применимые при чтении.

Отсюда следуют два вывода. Слабую парольную фразу можно атаковать офлайн со скоростью, которую допускает KDF, поэтому права на файл и доступ к резервным копиям по-прежнему важны, даже когда файл зашифрован. А атакующий, получивший только файл без парольной фразы, вынужден угадывать; тот, кто получил файл и парольную фразу, владеет ключом, как если бы он никогда не был зашифрован.

head -3 vpn.key
openssl pkey -in vpn.key -noout -pubout
openssl pkcs12 -in bundle.p12 -info -noout

head -3 показывает заголовок, а в старом файле — строки Proc-Type и DEK-Info, доказывающие шифрование; одна строка сама по себе не является доказательством ни в одну сторону. Строка pkey запрашивает парольную фразу и печатает только открытую половину, что доказывает работоспособность файла и фразы без раскрытия закрытого ключа. Не используйте -text для этой проверки: она печатает закрытые компоненты, privateExponent, prime1, prime2 и остальное, и этот вывод нельзя никуда вставлять — ни в тикет, ни в чат, ни в журнал. Команда PKCS#12 также сообщает, есть ли в пакете отдельный пароль MAC или шифрования, что стоит знать перед передачей коллеге.

Что перестаёт защищаться после загрузки ключа

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

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

Почему запрос продолжает возвращаться

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

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

Потеря и раскрытие — не одно и то же исправление

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

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