Прыватнасць OCSP: адказнік бачыць сертыфікат, а не ваш URL

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

Запыт вызначае адзін сертыфікат

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

Шлях старонкі, радок запыту і любы змест форм адсутнічаюць у стандартным ідэнтыфікатары. Сцвярджэнне, што адказнік атрымлівае дакладны URL, патрабуе доказаў з іншага месца, чым праверка сертыфіката. Запыт усё ж называе сертыфікат і момант, і адказнік можа ведаць, якая служба яго прадстаўляе.

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

Што адказнік сапраўды можа назіраць

Адказнік бачыць злучэнне, якое да яго даходзіць: адрас крыніцы, час і любыя метаданыя транспарту, якія запісвае яго разгортванне. Калі запыт статусу ідзе праз VPN, гэтай крыніцай можа быць выхад VPN, а не сетка доступу карыстальніка. Не мяркуйце, што запыт статусу ідзе тым жа шляхам, што і запыт старонкі, толькі таму што абодва належаць адной сесіі браўзера.

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

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

Статус можа прыходзіць прымацаваным у рукапацісканні

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

Прагляд сертыфіката ў адным браўзеры не апісвае кожную аперацыйную сістэму і VPN-кліента. Аднолькавы перахоп сеткі можа азначаць рознае пры розных наладах праверкі.

Кэшаванне ламае дапушчэнне адна старонка — адзін запыт

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

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

Сапраўдны адказ статусу павінен адпавядаць правілам сапраўднасці і свежасці правяральніка, і HTTP 200 не тое ж самае, што добры статус. Тайм-аўт не з'яўляецца адкліканнем. Гэтыя вынікі вядуць да розных паводзін кліента і не павінны злівацца ў адну памылку.

Прыватнасць: выбар, які захоўвае праверку цэласнай

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

Цішэйшы след не азначае бяспечнейшае злучэнне. Захоўвайце цэласнымі ідэнтычнасць партнёра, праверку ланцуга і мэтавую палітыку адклікання, а шлях дастаўкі змяняйце толькі праз опцыю, якую падтрымлівае разгортванне. Запішыце, якая опцыя абраная і хто ёй валодае.

Калі запыт з'яўляецца нечакана, называйце атрымальніка, маршрут і аперацыю з сертыфікатам асобна. Спампоўка ад выдаўца, запыт статусу і запыт старонкі — гэта тры падзеі. Разгляд іх як адной робіць агляд прыватнасці недакладным і хавае, які бок сапраўды нешта даведаўся. Пачніце з палёў пратакола і рухайцеся вонкі да сеткавага шляху.