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

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

Запит визначає один сертифікат

Ідентифікатор сертифіката OCSP будується з хеш-функції, двох хешів видавця та серійного номера цільового сертифіката, як визначено в RFC 6960. Кожне поле вказує на один сертифікат, а не на URL чи HTTP-запит.

Шлях сторінки, рядок запиту та будь-який вміст форм відсутні у стандартному ідентифікаторі. Твердження, що відповідач отримує точний URL, потребує доказів з іншого місця, а не з перевірки сертифіката. Запит усе ще називає сертифікат і момент, і відповідач може знати, яка служба його подає.

Бракує сторінки, а не всього контексту. Перевірка сертифіката плюс відома служба плюс повторюване джерело можуть дати більше, ніж будь-що з цього окремо.

Що відповідач справді може спостерігати

Відповідач бачить з'єднання, яке до нього доходить: адресу джерела, час і будь-які метадані транспорту, які записує його розгортання. Якщо запит статусу йде через VPN, цим джерелом може бути вихід VPN, а не мережа доступу користувача. Не припускайте, що запит статусу йде тим самим шляхом, що й запит сторінки, лише тому що обидва належать одній сесії браузера.

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

Прикріплена відповідь — це інший поширений шаблон. Розширення TLS status_request з RFC 6066 дозволяє серверу прикріпити відповідь OCSP до власного рукостискання, тож клієнт перевіряє те, що йому дали, замість того щоб самому отримувати статус для цього з'єднання. Цей зсув змінює спостерігача. Отримання виконує сторона сервера, і власна адреса клієнта для цього з'єднання ніколи не доходить до відповідача.

Статус може прийти прикріпленим у рукостисканні

Ніщо з цього не гарантує, що клієнт ніколи не зробить ще один запит перевірки. Побудова ланцюжка, політика статусу та підтримувані механізми різняться залежно від реалізації.

Переглядач сертифікатів в одному браузері не описує кожну операційну систему й кожного клієнта VPN. Той самий перехоплений трафік може означати різне за різних налаштувань перевірки.

Кешування руйнує припущення одна сторінка один запит

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

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

Дійсна відповідь про статус має відповідати правилам автентичності та свіжості перевіряча, і HTTP 200 — це не те саме, що добрий статус. Тайм-аут не є відкликанням. Ці результати ведуть до різної поведінки клієнта, і їх не слід зводити до однієї помилки.

Рішення щодо приватності, які зберігають перевірку цілою

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

Тихіший слід — не безпечніше з'єднання. Зберігайте цілими ідентичність партнера, перевірку ланцюжка та передбачену політику відкликання, а шлях доставки змінюйте лише через варіант, який підтримує розгортання. Запишіть, який варіант обрано і хто за нього відповідає.

Коли запит з'являється несподівано, називайте отримувача, маршрут і операцію із сертифікатом окремо. Завантаження від видавця, запит статусу та запит сторінки — це три події. Розгляд їх як одного робить огляд приватності неточним і приховує, яка сторона справді щось дізналася. Почніть із полів протоколу та рухайтеся назовні до мережевого шляху.