Cloudflare OHTTP Gateway skryje IP, obsah však neochráni pred cieľom

Cloudflare 2. októbra 2026 spustil uzavretú betu spravovanej OHTTP Gateway. Služba umožňuje cieľovej aplikácii prijať požiadavku bez pôvodnej IP adresy klienta, pokiaľ ju sprostredkuje relay iného prevádzkovateľa. Brána požiadavku rozšifruje a aplikácii odovzdá jej obsah, takže ochrana sieťového pôvodu neznamená anonymitu v samotnej aplikácii.

Prístup k službe zatiaľ vedie cez čakaciu listinu uzavretej bety. Nový produkt je určený najmä aplikáciám, ktorých servery už bežia za Cloudflare CDN alebo na Workers: tie môžu použiť bránu Cloudflare a relay mimo jeho infraštruktúry. Existujúci Privacy Gateway dostal názov Cloudflare OHTTP Relay a predstavuje opačné usporiadanie, pri ktorom si prevádzkovateľ aplikácie zabezpečí vlastnú bránu.

Cesta požiadavky cez relay a bránu

Norma RFC 9458 pre Oblivious HTTP opisuje sled klient → relay → gateway → cieľ. Klient najprv získa verejný kľúč brány, zostaví vnútornú HTTP požiadavku a zašifruje ju. Relay prijme šifrovanú správu a prepošle ju bráne, ktorá ju rozšifruje a doručí cieľovej aplikácii. Odpoveď sa cez bránu a relay vracia ku klientovi opäť zašifrovaná.

Pri službe Cloudflare sa OHTTP správy posielajú na koncový bod /.well-known/ohttp-gateway v zóne zákazníka. Brána spravuje kľúče a na požiadavku GET z tohto bodu poskytuje verejnú konfiguráciu; prijatú správu rozšifruje a ako vnútornú požiadavku odošle aplikačnému serveru. Bežná prevádzka mimo OHTTP môže do tej istej aplikácie prichádzať ďalej. Rozdiel vzniká už na klientovi: ak klient požiadavku nezašifruje pre bránu a nepošle cez relay, samotné zapnutie služby na zóne jeho IP adresu pred aplikáciou neskryje.

Čo vidí relay, Cloudflare a cieľová aplikácia

Súkromie tu vyplýva z rozdelenia informácií medzi účastníkov, nie z toho, že by sa údaje stratili. Pre vývojára je rozhodujúce, na ktorom mieste sa nachádza sieťová identita a kde sa mení šifrovaná správa na čitateľnú HTTP požiadavku.

• Relay vidí prichádzajúce spojenie od klienta vrátane jeho IP adresy a vie, ku ktorej bráne správu posiela. Vidí aj dĺžku šifrovanej správy a prevádzkové metadáta, ale vnútornú požiadavku nemôže čítať.
• Cloudflare OHTTP Gateway vidí spojenie od relay, jeho adresu a po rozšifrovaní vnútornú požiadavku. Ak relay neprenesie identifikátory klienta ďalej, brána pôvodnú IP adresu nedostane.
• Cieľová aplikácia dostane požiadavku, ktorú má vybaviť: metódu, cestu, príslušné hlavičky a telo. Môže z nej vytvoriť odpoveď bez prístupu k pôvodnému klientskemu spojeniu; informácie vložené do obsahu však pozná.

Schéma má aj prevádzkový dôsledok. Aplikácia, ktorá doteraz používala IP adresu návštevníka na geografické rozhodnutia, limity alebo spájanie relácií, s týmto signálom pri OHTTP požiadavke nemôže počítať. Dostupná jej zostane adresa relay a aplikačné údaje, ktoré klient do požiadavky sám vložil.

Hranica ochrany: obsah môže znovu prezradiť používateľa

Brána oddeľuje sieťovú identitu od obsahu len po hranicu aplikačnej vrstvy. Ak vnútorná požiadavka obsahuje cookie, prihlasovací token, e-mailovú adresu alebo iný stabilný identifikátor, cieľová aplikácia môže požiadavku priradiť k účtu či k skoršej aktivite. OHTTP tieto polia automaticky neodstraňuje. Najväčší prínos preto má pri požiadavkách, pri ktorých aplikácia nepotrebuje sledovať používateľa medzi volaniami.

Relay musí s vonkajšou správou pracovať tak, aby bráne neposlal identifikátory klienta v ďalších hlavičkách. Bežné proxy zvyknú pridávať polia o pôvode spojenia; pri OHTTP by tým mohli oslabiť oddelenie rolí. Aj veľkosť a načasovanie správ zostávajú pozorovateľnými znakmi prevádzky. Model súkromia preto závisí tiež od správania relay a od toho, koľko klientov používa rovnakú konfiguráciu brány.

Kedy oddelenie prevádzkovateľov vydrží

Relay a gateway musia patriť nezávislým subjektom: prevádzkovateľ, ktorý by ovládal obe úlohy, by mohol spojiť IP adresu s rozšifrovanou požiadavkou. Rovnaké riziko vznikne, ak si dve strany vymieňajú záznamy, z ktorých sa dajú konkrétne požiadavky spárovať. Brána a cieľový server pritom môžu byť pod jedným prevádzkovateľom, pretože oba už pracujú s obsahom, nie s pôvodným klientskym spojením.

Pri architektúre s Cloudflare OHTTP Gateway z toho vyplývajú konkrétne podmienky: klient musí používať OHTTP; relay musí prevádzkovať iná strana a nesmie preposielať identifikačné údaje; aplikácia si musí ujasniť, ktoré vlastné identifikátory v požiadavke potrebuje. Súčasťou návrhu brány je aj poistka proti spojeniu oboch rolí v sieti Cloudflare: odmietne rozšifrovať požiadavky prichádzajúce z Cloudflare Workers alebo z hostiteľov sprostredkovaných cez Cloudflare. Toto obmedzenie sa týka cesty k bráne, nie možnosti prevádzkovať cieľovú aplikáciu na Workers.

Beta prináša spravovanú bránu aj režijné náklady

Cloudflare pri bráne spravuje šifrovacie kľúče, podporuje štandardný aj delený prenos OHTTP a umožňuje použiť Cloudflare Access na overenie relay pred rozšifrovaním. Delený prenos spracúva požiadavku postupne; pri vhodnom type prevádzky môže znížiť čakanie. Tieto funkcie uľahčujú prevádzku brány, no nenahrádzajú výber nezávislého relay ani úpravu klienta a aplikačných údajov.

Každé volanie prechádza cez ďalšiu sieťovú stranu a vyžaduje šifrovanie, väčšiu správu aj ďalšie HTTP prenosy. OHTTP preto pridáva latenciu a výpočtovú réžiu oproti priamemu spojeniu; skutočný rozdiel závisí od polohy relay a aplikácie aj od veľkosti požiadaviek. Služba je v uzavretej bete a pri uvedení má byť plateným doplnkom k zóne. Pre jej nasadenie bude podstatné, či konkrétna aplikácia dokáže prijímať obsah bez klientovej IP adresy a bez identifikátorov, ktoré by tento účinok zrušili.

Prečítajte si aj:

• Cloudflare či Fastly: pole position v meraní nestačí bez ceny prevádzky
• Premiere prišiel na Android zadarmo, kredity Firefly však ostávajú platené