Privateco de OCSP: la respondanto vidas atestilon, ne vian URL

Statuskontrolo demandas unu demandon pri unu atestilo, kaj la respondo vojaĝas sur sia propra konekto. Ĝi ne enhavas la paĝan vojon, kiu kondukis al la kontrolo. Privatecaj diskutoj ofte traktas la interŝanĝon kiel fluon de retuma historio, kio troigas tion, kion la peto portas, kaj subtaksas tion, kion la respondanto povas observi. Legu la peton antaŭ ol decidi, kion ĝi malkaŝas.

La peto identigas unu atestilon

La OCSP-atestila identigilo estas konstruata el haketa funkcio, du haketoj de la eldonanto kaj la seria numero de la cela atestilo, kiel specifite en RFC 6960. Ĉiu kampo montras al unu atestilo, ne al URL aŭ al HTTP-peto.

La paĝa vojo, la mendĉeno kaj ajna forma enhavo forestas el la norma identigilo. La aserto, ke la respondanto ricevas la precizan URL, bezonas pruvon de aliloke ol de la atestila kontrolo. La peto ankoraŭ nomas atestilon kaj momenton, kaj la respondanto povas scii, kiu servo prezentas ĝin.

Mankas la paĝo, ne la tuta kunteksto. Atestila kontrolo plus konata servo plus ripetiĝanta fonto povas esti pli informaj ol iu ajn el ili sola.

Kion la respondanto efektive povas observi

La respondanto vidas la konekton, kiu atingas ĝin: fontan adreson, tempon kaj ajnajn transportajn metadatenojn, kiujn ĝia deplojo registras. Se la statuspeto sekvas la VPN-on, tiu fonto povas esti la VPN-elirejo anstataŭ la alirreto de la uzanto. Ne supozu, ke la statuspeto sekvas la saman vojon kiel la paĝpeto nur ĉar ambaŭ apartenas al unu retuma seanco.

Kontrolu la subtenatan enkursigadon kaj validigan konduton de la kliento anstataŭ dedukti ĝin el unu spuro. Dividita tunelo povas sendi la du petojn en malsamajn direktojn.

Alkroĉita respondo estas la aliakomuna ŝablono. La TLS-etendaĵo status_request de RFC 6066 permesas al servilo aldoni OCSP-respondon al sia propra manpremo, do la kliento validigas tion, kion ĝi ricevis, anstataŭ mem akiri statuson por tiu konekto. Tiu ŝanĝo ŝanĝas la observanton. La servila flanko faras la akiron, kaj la propra adreso de la kliento neniam atingas la respondanton por tiu konekto.

Statuso povas alveni alkroĉite en la manpremo

Nenio el tio garantias, ke kliento neniam faros alian validigan peton. Ĉenkonstruado, statuspolitiko kaj subtenataj mekanismoj varias laŭ efektivigo.

Atestila rigardilo en unu retumilo ne estas priskribo de ĉiu operaciumo kaj VPN-kliento. La sama retkaptaĵo povas signifi malsamajn aferojn sub malsamaj validigaj agordoj.

Kaŝmemorado rompas la supozon unu paĝo unu serĉo

Kaŝmemorado malkunligas paĝajn ŝarĝojn de serĉoj. La retumilo povas reuzi respondon dum periodo, do unu paĝvido ne implicas unu retan peton.

La kontraŭa eraro estas same ofta. Kaŝmemorita respondo diras nenion pri tio, kiam okazos la sekva refreŝigo, kaj la refreŝiga horaro povas esti senrilata al la malfermata paĝo. Uzu la aktualan dokumentaron de la kliento kaj la validan validigan politikon antaŭ ol atribui kaptaĵon al OCSP.

Valida statusrespondo devas plenumi la aŭtentecajn kaj freŝecajn regulojn de la validiganto, kaj HTTP 200 ne samas al bona statuso. Tempa limo ne estas revoko. Tiuj rezultoj kondukas al malsama klienta konduto kaj ne devus esti kunfanditaj en unu eraron.

Privatecaj elektoj, kiuj konservas la validigon sendifekta

Kie la serĉo mem estas delikata, diskutu subtenatajn liverajn kaj kaŝmemorajn elektojn kun la sistema posedanto. Ne solvu ĝin per malŝalto de la revoka kontrolo aŭ de la ĉena validigo.

Pli silenta spuro ne estas pli sekura konekto. Konservu sendifektaj la samtavolan identecon, la ĉenan validigon kaj la celitan revokan politikon, kaj ŝanĝu la liveran vojon nur per elekto, kiun la deplojo subtenas. Notu, kiu elekto estis elektita kaj kiu posedas ĝin.

Kiam serĉo aperas neatendite, nomu la ricevanton, la vojon kaj la atestilan operacion aparte. Elŝuto de eldonanto, statusa demando kaj la paĝpeto estas tri eventoj. Trakti ilin kiel unu igas la privatecan revizion malprecizan kaj kaŝas, kiu partio efektive lernis ion. Komencu de la protokolaj kampoj kaj laboru eksteren al la reta vojo.