Собственный сертификат VPN — не дополнительный слой шифрования

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

Три отдельные задачи в рукопожатии TLS 1.3

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

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

Что на самом деле даёт частный CA

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

Но он приносит и обязательства. Доверие нужно распределять осознанно, проверка партнёра должна оставаться включённой, а жизненным циклом учётных данных должен кто-то владеть. Частный CA — не короткий путь в обход любого из этих трёх пунктов.

Когда второй канал — правильный ответ

Предположим, приложение открывает проверенный HTTPS к собственному сервису, а его пакеты идут ещё и через VPN. У такой схемы две границы с потенциально разными конечными точками, и именно так выглядит второй защищённый канал.

Разница важна на шлюзе. Если сеанс TLS приложения завершается на шлюзе VPN, а не в приложении, той защиты, которая, как вы считали, есть за туннелем, там нет. Запишите, кто завершает каждый канал, прежде чем заявлять это свойство.

Спросите, что меняет установка

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

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

Запишите границы

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

Две строки на одной странице обычно закрывают спор, который ротация сертификата закрыть не может.

Решите тремя вопросами

Проблема в том, кем представляется конечная точка, или в том, что происходит с данными? Должна ли защита продолжаться за шлюзом VPN до конкретного приложения? И можете ли вы назвать две конечные точки, которые завершили бы второй канал?

Если верен первый вопрос, исправьте идентичность и доверие. Если второй или третий — спроектируйте второй канал и оставьте сертификат там, где ему место.