Cloudflare OHTTP Gateway loči identiteto od vsebine zahteve

Cloudflare je 2. oktobra 2026 predstavil Cloudflare OHTTP Gateway v zaprtem predogledu in odprl čakalni seznam. Novi upravljani prehod sprejema zahteve po protokolu Oblivious HTTP (OHTTP), jih razšifrira in posreduje aplikaciji brez odjemalčevega izvornega naslova IP. Podjetje je dosedanji Privacy Gateway hkrati preimenovalo v Cloudflare OHTTP Relay, da bi ločilo vlogi obeh izdelkov.

Za razvijalca je odločilno, kdo upravlja pot do prehoda. Rele drugega upravljavca vidi odjemalčevo povezavo, Cloudflarov prehod pa vsebino zahteve; we_are_coded opisuje tudi varovalko, s katero prehod zavrne razšifriranje zahtev, poslanih iz Cloudflare Workers ali prek gostiteljev, ki jih posreduje Cloudflare. Dostop do novega izdelka je za zdaj omejen na zaprti predogled, zato ga razvijalec še ne more prosto vključiti v račun.

Pot zahteve: kdo jo posreduje in kdo jo odpre

Odjemalec najprej pridobi javni ključ prehoda in z njim šifrira notranjo zahtevo. Šifrirano sporočilo pošlje releju, ta pa ga posreduje prehodu. Rele nima ključa za branje notranje zahteve. Cloudflare OHTTP Gateway jo razšifrira, iz nje sestavi običajno zahtevo HTTP za aplikacijski strežnik in odgovor znova šifrira za vrnitev odjemalcu.

Pot je zato mogoče prikazati v eni vrstici: odjemalec → neodvisni rele → Cloudflare OHTTP Gateway → izvorni strežnik. Odgovor potuje nazaj po isti verigi. Prehod kot neposrednega pošiljatelja vidi rele, izvorni strežnik pa prejme zahtevo od prehoda. Naslov IP naprave, ki se je povezala z relejem, se po tej poti ne prenese samodejno do aplikacije.

Razdelitev dela ima tudi operativno posledico. Aplikacijskemu strežniku ni treba izvajati šifriranja in razšifriranja OHTTP, saj to prevzame prehod. Odjemalec mora zahtevo še vedno pravilno sestaviti in šifrirati, razvijalec pa mora zagotoviti rele, ki ga ne upravlja ista stran kot prehod oziroma aplikacija.

Matrika podatkov, ki ostanejo vidni

OHTTP loči podatke o povezavi od vsebine zahteve. Posamezni udeleženci pri postavitvi z neodvisnim relejem in Cloudflarovim prehodom vidijo različne dele iste izmenjave:

• Odjemalec pozna vsebino, ki jo pošilja, in odgovor, ki ga prejme. Pred pošiljanjem vsebino šifrira za prehod.
• Rele vidi odjemalčev naslov IP, značilnosti njegove povezave in cilj posredovanja. Vidi tudi dolžino šifriranega sporočila, ne more pa prebrati notranje zahteve.
• Prehod vidi povezavo releja in razšifrirano notranjo zahtevo. Iz same poti OHTTP ne izve izvornega naslova IP odjemalca.
• Izvorni strežnik prejme vsebino za obdelavo in podatke o povezavi s prehodom. Odjemalca lahko kljub temu prepozna, če ga razkrijejo podatki v notranji zahtevi.

Ta zadnja možnost določa mejo zaščite. Če odjemalec v telo zahteve vključi e-poštni naslov, uporabniško ime ali drug prepoznaven podatek, ga prehod po razšifriranju vidi, aplikacija pa ga lahko obdela. OHTTP torej prikrije izvorno omrežno identiteto pred prehodom in aplikacijo; ne odstrani identifikatorjev, ki jih aplikacija sama zahteva v vsebini. Rele medtem še vedno ve, s katerim strežnikom komunicira odjemalec in kako veliko je šifrirano sporočilo.

Ločena upravljavca sta pogoj zasebnosti

Če ista stran upravlja rele in prehod, lahko primerja zapise o odjemalčevi povezavi z razšifriranimi zahtevami. Šifriranje med posameznimi deli poti bi še vedno delovalo, obljubljena ločitev identitete od vsebine pa bi izgubila smisel. Enako tveganje nastane, če upravljavec releja lahko dostopa do podatkov aplikacijskega strežnika in oba pogleda poveže.

Cloudflare zato za svoj OHTTP Gateway predvideva rele drugega upravljavca. Njegova zavrnitev zahtev iz Workers in gostiteljev, posredovanih prek Cloudflara, preprečuje eno neposredno napačno postavitev, pri kateri bi Cloudflare videl oba dela izmenjave. Sama tehnična zavrnitev pa ne odloča o vseh odnosih med zunanjim relejem in lastnikom aplikacije: tudi tam je pomembno, ali lahko upravljavca združita podatke.

Izbira releja zato ni zgolj vprašanje, kam poslati šifrirano sporočilo. Njegov upravljavec ima vpogled v izvor povezave, medtem ko prehod in aplikacija poznata vsebino. Če ti strani sodelujeta pri povezovanju zapisov, lahko iz časovnega zaporedja in drugih razpoložljivih podatkov sklepata, katera zahteva pripada posameznemu odjemalcu. Zasebnostna lastnost protokola temelji na ločenem, nesodelujočem upravljanju teh pogledov.

Kako je prehod zasnovan za aplikacijo

Cloudflare OHTTP Gateway je predviden kot plačljiv dodatek za območje aplikacije. Zahteve OHTTP sprejema na poti /.well-known/ohttp-gateway, na istem naslovu pa lahko odjemalci s poizvedbo GET pridobijo javne ključe. Cloudflare upravlja ključe in razšifrirano notranjo zahtevo posreduje aplikacijskemu strežniku. Običajne zahteve HTTP lahko še naprej potujejo do strežnika brez obdelave v prehodu.

Podprti sta standardna in razdeljena obdelava OHTTP; pri slednji lahko prehod dele zahteve obdeluje postopno. Prehod je vezan na območje aplikacije, kar omejuje, kam sme poslati razšifrirano zahtevo. Za nadzor nad prometom pred razšifriranjem je predvidena tudi uporaba Cloudflare Access, na primer za preverjanje releja s storitvenimi poverilnicami ali vzajemnim TLS.

Takšna zasnova je posebej pomembna za aplikacije, katerih strežniki so že za Cloudflarovim CDN ali tečejo v Workers: upravljani prehod lahko stoji ob njih, odjemalčevo povezavo pa mora najprej sprejeti zunanji rele. Razvijalec s tem prenese kriptografski del prehoda na Cloudflare, odgovornost za podatke v notranji zahtevi in izbiro neodvisnega releja pa ostane del zasnove aplikacije.

Zaprt predogled omejuje vključitev

Čakalni seznam za novi Gateway še ne pomeni splošne razpoložljivosti ali samodejnega vklopa za obstoječe uporabnike Cloudflara. Ločen izdelek, Cloudflare OHTTP Relay, je po dokumentaciji prav tako v zaprtem predogledu, namenjen izbranim podjetjem in partnerjem; dokumentacija je bila posodobljena 2. oktobra 2026. Njegova vloga je posredovanje šifriranih zahtev, ne razšifriranje v novem prehodu.

Za uporabo Cloudflarovega prehoda bo torej potrebna odobritev dostopa in rele drugega upravljavca. Do širšega odprtja ostaja čakalni seznam meja med opisano arhitekturo in vključitvijo izdelka v aplikacijo.

Preberite tudi:

• PostgreSQL ali MySQL: isti JSON zahteva drugačno indeksiranje
• Cloudflare ali Fastly: napačen preizkus lahko izbere napačen CDN
• Pravica do odklopa: klic po službi še ne zahteva odgovora