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

Провера статуса поставља једно питање о једном сертификату, а одговор путује сопственом везом. Она не садржи путању странице која је довела до провере. Расправе о приватности често третирају ту размену као ток историје прегледања, што прецењује шта захтев носи и потцењује шта одговорник може да посматра. Прочитајте захтев пре него што одлучите шта открива.

Захтев идентификује један сертификат

Идентификатор сертификата OCSP гради се од хеш функције, два хеша издаваоца и серијског броја циљног сертификата, како је наведено у RFC 6960. Свако поље показује на један сертификат, а не на URL или HTTP захтев.

Путања странице, упитни низ и било који садржај обрасца недостају у стандардном идентификатору. Тврдња да одговорник прима тачан URL захтева доказ однекуд другде, а не из провере сертификата. Захтев и даље именује сертификат и тренутак, а одговорник може да зна која услуга га представља.

Оно што недостаје је страница, а не цео контекст. Провера сертификата плус позната услуга плус поновљени извор могу бити информативнији од било чега од тога појединачно.

Шта одговорник заиста може да посматра

Одговорник види везу која до њега стиже: изворну адресу, време и све транспортне метаподатке које његово увођење бележи. Ако захтев за статус иде кроз VPN, тај извор може бити VPN излаз, а не корисникова приступна мрежа. Не претпостављајте да захтев за статус иде истим путем као захтев за страницу само зато што оба припадају једној сесији прегледача.

Проверите подржано усмеравање и понашање при верификацији на клијенту уместо да то закључујете из једног трага. Подељени тунел може послати два захтева у различитим смеровима.

Причвршћени одговор је други уобичајени образац. TLS екстензија status_request из RFC 6066 омогућава серверу да причврсти OCSP одговор на сопствено руковање, па клијент верификује оно што му је дато уместо да сам прибавља статус за ту везу. Та промена мења посматрача. Прибављање ради серверска страна, а клијентова сопствена адреса никада не стиже до одговорника за ту везу.

Статус може стићи причвршћен у руковању

Ништа од овога не гарантује да клијент никада неће упутити још један захтев за верификацију. Изградња ланца, политика статуса и подржани механизми разликују се по имплементацији.

Преглед сертификата у једном прегледачу није опис сваког оперативног система и VPN клијента. Исти мрежни снимак може значити различите ствари под различитим подешавањима верификације.

Кеширање руши претпоставку једна страница једно тражење

Кеширање раздваја учитавање страница од тражења. Прегледач може поново користити одговор неко време, па један преглед странице не значи један мрежни захтев.

Супротна грешка је једнако честа. Кеширани одговор не говори ништа о томе када ће се догодити следеће освежавање, а распоред освежавања може бити неповезан са страницом која се отвара. Користите тренутну документацију клијента и важећу политику верификације пре него што снимак припишете OCSP-у.

Ваљан одговор статуса мора да задовољи правила аутентичности и свежине верификатора, а HTTP 200 није исто што и добар статус. Истек времена није опозив. Ти исходи воде различитом понашању клијента и не треба их сводити на једну грешку.

Избори приватности који чувају верификацију нетакнутом

Тамо где је само тражење осетљиво, разговарајте о подржаним опцијама доставе и кеширања са власником система. Не решавајте то искључивањем провере опозива или верификације ланца.

Тиши траг није сигурнија веза. Сачувајте нетакнутима идентитет друге стране, верификацију ланца и предвиђену политику опозива, а пут доставе мењајте само кроз опцију коју увођење подржава. Забележите која је опција изабрана и коме припада.

Када се тражење појави неочекивано, именујте примаоца, руту и операцију са сертификатом одвојено. Преузимање од издаваоца, упит статуса и захтев за страницу су три догађаја. Третирање их као једног чини преглед приватности нетачним и скрива која је страна заиста нешто сазнала. Почните од поља протокола и радите ка споља ка мрежној путањи.