Обмен ключами TLS против клиентского сертификата: что из них выполняет вход?

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

Два объекта, которые в записи выглядят одинаково

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

Четыре строки независимы. Соединение может иметь первую и вторую строку, пропустить третью и всё равно нести четвёртую в заголовке cookie.

Решите, что может доказать записанное рукопожатие

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

Поэтому честный вывод узок: в этом обмене клиентский сертификат не предъявлялся. Дело не в том, что клиент не отправил ничего связываемого, и уж точно не в том, что сеанс не нёс никакого идентификатора.

Читайте сообщения, а не имя шифра

Спросите сервер, что он запрашивает, вместо того чтобы делать вывод из набора шифров. Рукопожатие TLS 1.3 с запросом сертификата видно в расшифровке, и его отсутствие столь же заметно.

openssl s_client -connect app.example.net:443 -tls1_3 -msg < /dev/null 2>&1 | grep -i -E 'key_share|CertificateRequest'

Затем повторите с настроенным клиентским сертификатом и сравните. Второй запуск должен показать, что сертификат отправляется и принимается; первый не должен показывать ничего, и именно в этом конкретная разница, о которой идёт спор.

openssl s_client -connect app.example.net:443 -tls1_3 -cert client.pem -key client.key -quiet

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

Где возобновление меняет ответ

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

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

Запишите четыре свойства, а не один вердикт

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

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