Приватность OCSP: ответчик видит сертификат, а не ваш URL

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

Запрос определяет один сертификат

Идентификатор сертификата OCSP строится из хеш-функции, двух хешей издателя и серийного номера целевого сертификата, как указано в RFC 6960. Каждое поле указывает на один сертификат, а не на URL или HTTP-запрос.

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

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

Что ответчик действительно может наблюдать

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

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

Закреплённый ответ — это другой распространённый шаблон. Расширение TLS status_request из RFC 6066 позволяет серверу прикрепить ответ OCSP к собственному рукопожатию, поэтому клиент проверяет то, что ему дали, вместо того чтобы самому получать статус для этого соединения. Этот сдвиг меняет наблюдателя. Получение выполняет сторона сервера, и собственный адрес клиента для этого соединения никогда не доходит до ответчика.

Статус может прийти закреплённым в рукопожатии

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

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

Кеширование ломает допущение одна страница один запрос

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

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

Действительный ответ о статусе должен соответствовать правилам подлинности и свежести проверяющего, и HTTP 200 — это не то же самое, что хороший статус. Тайм-аут не является отзывом. Эти результаты ведут к разному поведению клиента, и их не следует сводить к одной ошибке.

Решения о приватности, сохраняющие проверку целой

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

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

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