Cloudflare a anunțat pe 2 octombrie 2026 deschiderea unei beta private pentru Cloudflare OHTTP Gateway, un serviciu self-serve care permite clienților să activeze un gateway OHTTP ca add-on plătit pe zona lor și să primească trafic OHTTP în câțiva pași, prin înscriere pe listă de așteptare. În paralel, compania a redenumit vechiul Privacy Gateway în Cloudflare OHTTP Relay, pentru a separa clar cele două produse. Sursa: Cloudflare Blog.

Ce este OHTTP și de ce contează separarea relay-gateway

Oblivious HTTP (OHTTP) este un standard IETF care permite backend-urilor de aplicații să primească cereri HTTP fără să vadă adresa IP a utilizatorului. Mecanismul se bazează pe două hopuri operate independent: un relay și un gateway. Relay-ul transmite orbește cereri criptate, ascunzând identificatorii clientului față de serverele de aplicație. Gateway-ul face munca criptografică: decapsulează cererile criptate și împachetează răspunsurile, astfel încât serverele aplicației să trateze cererile OHTTP ca pe HTTP simplu.

Diferența față de un proxy clasic de forwarding este criptarea datelor între client și serverul de aplicație. Cererile și răspunsurile sunt încapsulate cu Hybrid Public Key Encryption (HPKE), astfel încât doar clientul și serverul de aplicație văd textul în clar, iar relay-ul vede doar ciphertext. Rezultatul este un model „double-blind”: relay-ul vede doar identificatorii clientului, gateway-ul și serverul de aplicație văd doar conținutul cererii, niciun actor nu vede ambele.

Punctul critic, pe care Cloudflare îl repetă explicit, este separarea trust-ului. Dacă relay-ul și gateway-ul ar fi operate de aceeași parte, acea parte ar vedea simultan cine face cererea și ce cere, ceea ce anulează modelul de confidențialitate. De aceea compania precizează că gateway-ul refuză să decapsuleze cereri trimise din Cloudflare Workers sau de pe host-uri proxied prin Cloudflare, pentru a nu rupe accidental această separare.

Ce s-a schimbat concret: de la Privacy Gateway la două produse

În 2022 Cloudflare a lansat un produs de relay OHTTP sub numele Privacy Gateway. Acum acel produs se numește Cloudflare OHTTP Relay, iar noul OHTTP Gateway vine ca piesă complementară. Logica e simplă și ține de arhitectură: clienții care își protejează deja serverele în spatele Cloudflare nu puteau folosi și un relay operat de Cloudflare, pentru că Cloudflare ar fi văzut atât metadatele clientului, cât și conținutul decriptat al cererilor, ceea ce încalcă modelul OHTTP.

Astfel, clienții au acum două opțiuni clare. Prima: folosesc Cloudflare OHTTP Relay și își rulează singuri gateway-ul, potrivit dacă serverele de aplicație sunt găzduite în afara Cloudflare. A doua: folosesc noul Cloudflare OHTTP Gateway cu un relay terț, potrivit dacă serverele sunt deja în spatele Cloudflare (CDN sau Workers), dacă acceptă cereri OHTTP de la un terț precum Apple LiveCallerID, sau dacă vor un gateway administrat care minimizează latența și efortul operațional.

În materialul sursă apar exemple de utilizare reale ale relay-ului: Flo Health folosește OHTTP pentru modul Anonymous din aplicație, iar Apple Private Cloud Compute îl folosește pentru a disocia cererile de inferență AI de identitatea utilizatorilor. Sunt cazuri care arată că OHTTP nu mai e un experiment de nișă, ci infrastructură de producție pentru produse cu mize mari de confidențialitate.

Cum funcționează gateway-ul în practică

Gateway-ul este construit ca funcție a zonei clientului. Clienții trimit cereri OHTTP bine formatate către endpoint-ul /.well-known/ohttp-gateway pe zona respectivă, iar serviciul interceptează fiecare cerere, o decriptează, emite o subcerere către serverul aplicației și returnează un răspuns criptat clientului. Cererile non-OHTTP ajung la server fără să atingă gateway-ul. Cloudflare spune că suportă atât OHTTP standard, cât și chunked OHTTP, recomandând varianta chunked pentru performanță, pentru că permite procesarea incrementală.

Gestionarea cheilor este complet administrată de Cloudflare. Gateway-ul menține o configurație publică de chei HPKE, necesară pentru ca clienții să cripteze cereri, și servește cheile publice ca răspuns la cereri GET pe același endpoint. Pentru confidențialitate mai puternică, clienții pot descărca cheile de pe o adresă IP diferită de cea pe care fac cererea către gateway.

Legarea gateway-ului de zonă aduce și protecție anti-abuz. Un client care trimite cereri către example.com poate folosi subdomenii precum foo.example.com, dar nu poate folosi zona respectivă ca punct de plecare către alte domenii. În plus, Cloudflare Access rulează înainte de decriptare, permițând autentificarea traficului prin politici standard: mutual TLS, credențiale statice de serviciu sau logică externă custom. Este o alegere interesantă: autentifici relay-ul înainte ca cererea să fie decriptată, păstrând astfel separarea dintre identitate și conținut.

Merită menționat și un detaliu de responsabilitate pe care Cloudflare îl semnalează explicit în ghidul de început: OHTTP oferă confidențialitate la nivel de rețea, dar nu atinge corpul interior al cererii. Dacă aplicația trimite în body un email sau un nume de utilizator, acel identificator rămâne vizibil pentru serverul care procesează cererea. Altfel spus, protocolul rezolvă o parte a problemei, nu toată, iar decizia de a nu trimite date identificatoare aparține echipei de produs.

Limite, ipoteze și ce rămâne de verificat

Faptul că beta-ul este închis și se accesează prin listă de așteptare înseamnă că disponibilitatea generală și prețul nu sunt confirmate în materialul sursă. Nu avem date despre costuri, despre nivelurile de serviciu promise sau despre regiunile în care add-on-ul va fi comercializat. Cine își planifică arhitectura pe baza acestui produs ar trebui să trateze aceste necunoscute ca atare.

De asemenea, performanța reală depinde de topologie. Cloudflare argumentează că rularea gateway-ului pe toate serverele din rețeaua edge și abordarea anycast reduc latența pe hopul relay-gateway, iar dacă folosești CDN-ul lor, cererile pot fi decriptate și rezolvate pe aceleași metale, economisind latență gateway-origin. Este o ipoteză de arhitectură rezonabilă, dar nu un rezultat măsurat pe cazul tău concret. Aici intervine verificarea: orice decizie de adoptare ar trebui precedată de măsurători proprii.

Un alt punct de atenție este că OHTTP nu rezolvă toate problemele de confidențialitate și nici nu elimină nevoia de bunuri practici în aplicație. El limitează corelarea la nivel de rețea, dar dacă logica de business trimite identificatori în body sau dacă logging-ul intern păstrează date sensibile, modelul double-blind nu te salvează. Confidențialitatea rămâne o proprietate a întregului sistem, nu a unui singur hop.

Ce înseamnă pentru tine, ca antreprenor sau marketer român

Dacă ai un magazin online, un SaaS sau o aplicație cu utilizatori din UE, subiectul te privește indirect, dar concret. Pe de o parte, OHTTP este infrastructură pentru backend, nu pentru media buying: nu îți schimbă ROAS-ul, nu îți reduce CPA-ul și nu îți aduce clienți. Cine vinde asta ca soluție de marketing vinde gogoși. Pe de altă parte, confidențialitatea la nivel de rețea devine un argument de produs și de conformitate, iar dacă aplicația ta colectează date sensibile (sănătate, fintech, date de minor), arhitectura contează tot mai mult.

Pentru un antreprenor român, pașii practici sunt limitați și deloc spectaculoși. Primul: verifică unde stau serverele tale și cine vede ce. Dacă ești deja pe Cloudflare, un gateway administrat îți poate simplifica operațiunile, dar beta-ul închis înseamnă că nu poți conta pe el în producție astăzi. Al doilea: separă clar discuția de conformitate de cea de performanță. OHTTP nu este un substitut pentru un audit de date, ci un strat tehnic printre altele. Al treilea: nu promite utilizatorilor mai mult decât livrezi. Dacă spui „anonim”, dar trimiți email în body, promisiunea nu ține.

Pentru echipele care lucrează cu date de campanie și atribute, discuția despre cine vede ce este deja familiară. Am atins tema în analiza despre stratul ascuns de date al Google și badge-urile de reducere false, unde transparența datelor schimbă încrederea în raportări, și în materialul despre ce cred marketerii greșit despre Omnisend în 2026, unde separarea semnalului de zgomot e esențială. Logica e aceeași: înțelege cine vede ce date și de ce.

FAQ

Ce este Cloudflare OHTTP Gateway? Este un serviciu care decapsulează cereri OHTTP criptate și împachetează răspunsurile, astfel încât serverele aplicației să primească HTTP simplu fără să vadă adresa IP sau fingerprintul TLS al utilizatorului. Se activează ca add-on pe o zonă Cloudflare, iar accesul se face momentan prin beta privat și listă de așteptare.

Prin ce diferă de Cloudflare OHTTP Relay? Relay-ul transmite orbește cereri criptate și ascunde identificatorii clientului, dar nu face munca criptografică. Gateway-ul face decapsularea și încapsularea. Pentru separarea trust-ului ai nevoie de ambele, operate de părți independente, de aceea Cloudflare a redenumit Privacy Gateway în OHTTP Relay.

Pot folosi OHTTP Gateway din România? Materialul sursă nu confirmă disponibilitatea pe țări. Produsul este în beta privată, cu înscriere pe listă de așteptare, iar detaliile de disponibilitate geografică și preț nu sunt precizate. Orice afirmație despre accesul din România ar fi o ipoteză, nu un fapt verificat.

Concluzie

OHTTP nu este un subiect de marketing, ci de infrastructură și încredere. Cloudflare rezolvă o problemă reală de adopție: construirea și operarea unui gateway OHTTP la scară este dificilă, iar un serviciu administrat reduce bariera. Dar rămâne o piesă într-un sistem, nu o soluție completă.

AI-ul ajută aici la analiză și planificare: compară arhitecturi, structurează întrebările de verificat, pune pe hârtie compromisurile dintre latență, cost și separarea trust-ului. Decizia și execuția rămân umane, iar media buyer-ul rămâne cel care știe ce date sunt cu adevărat necesare în fluxul de conversie și ce poate fi eliminat fără să strice măsurarea. Pasul concret îl face ALLSoft Agency, cu verificări pe date reale, nu cu promisiuni de confidențialitate lipite pe slide.