Cloudflare OHTTP Gateway separa le richieste delle app dagli indirizzi IP

Cloudflare OHTTP Gateway è progettato per consentire alle applicazioni di ricevere richieste senza conoscere l’indirizzo internet dell’utente, mantenendone al contempo il contenuto illeggibile per l’intermediario che le inoltra. In un annuncio datato 2 ottobre 2026, gli autori di Cloudflare Lara Schull e Akshat Mahajan descrivono un servizio gestito che si occupa della crittografia necessaria per Oblivious HTTP (OHTTP), un protocollo che separa le informazioni su chi si connette da quelle su ciò che richiede.

Per i proprietari di siti web e i team che si occupano delle applicazioni, il cambiamento principale è operativo: Cloudflare si assume la responsabilità della crittografia e delle chiavi di cifratura del gateway, anziché richiedere ai clienti di gestire autonomamente questo componente. Secondo l’azienda, il servizio opera sulla rete globale di Cloudflare, con una capacità che viene adeguata automaticamente. I server applicativi possono utilizzarlo indipendentemente dal fatto che si trovino o meno dietro Cloudflare per le altre funzioni.

Separare l’identità dal contenuto delle richieste

Un indirizzo IP è l’indirizzo di rete utilizzato per connettersi a internet. Insieme alle informazioni sulla posizione e alle caratteristiche della connessione, può aiutare un servizio ad associare le attività a un utente. OHTTP inserisce un relay, un intermediario che inoltra il traffico, tra l’applicazione dell’utente e l’infrastruttura ricevente. Il server applicativo vede quindi i dettagli di rete del relay anziché quelli dell’utente.

Cloudflare lo illustra con una richiesta che mostra l’indirizzo IP del relay, 128.62.37.13, e l’ASN 18. Un numero di sistema autonomo (ASN) identifica una rete su internet. L’esempio colloca il relay ad Austin, in Texas, negli Stati Uniti, e riporta TLSv1.3 e AEAD-AES-128-GCM-SHA256 tra i dettagli della connessione. Transport Layer Security (TLS) protegge le connessioni; l’identificatore della suite crittografica descrive i metodi di crittografia utilizzati. Nel loro insieme, questi dettagli possono costituire un’impronta TLS, una combinazione riconoscibile di impostazioni della connessione. In questo esempio, la posizione e l’impronta appartengono al relay, non all’utente finale.

Quando molti utenti condividono un relay, questi dettagli di rete non permettono più al server applicativo di distinguere le loro singole richieste. Ciò limita la capacità del server di ricondurre le attività a una persona attraverso tali dettagli. Si tratta di un confine preciso a tutela della privacy, non dell’affermazione che sia scomparso ogni possibile mezzo per identificare qualcuno.

L’altro elemento essenziale è la crittografia. Un semplice proxy di inoltro, un servizio che trasmette il traffico ad altri sistemi, non garantisce di per sé la separazione della visibilità offerta da OHTTP. OHTTP utilizza Hybrid Public Key Encryption (HPKE), un metodo per cifrare i messaggi destinati a uno specifico destinatario, per racchiudere richieste e risposte in un involucro cifrato. Il relay vede dati cifrati anziché contenuti leggibili. Un gateway tra il relay e il server applicativo decifra le richieste in ingresso e cifra le risposte in uscita, lasciando all’applicazione la gestione del normale HTTP, il linguaggio di richieste e risposte utilizzato dai servizi web.

Il risultato è un modello di privacy basato sulla separazione della fiducia: il relay può vedere gli identificatori di rete del client ma non la richiesta interna, mentre il gateway e il server applicativo possono vedere il contenuto delle richieste senza ricevere gli identificatori di rete dell’utente. Le risposte seguono lo stesso percorso a ritroso. Il gateway fa quindi parte dell’infrastruttura fidata che può leggere la richiesta, e non è semplicemente un altro servizio di inoltro privo di visibilità sul contenuto.

Come funziona il gateway gestito

Cloudflare OHTTP Gateway viene abilitato per una zona, ossia la configurazione del dominio gestita tramite Cloudflare. I client inviano richieste OHTTP nel formato corretto a https://your-zone.com/.well-known/ohttp-gateway. Il gateway decifra ogni richiesta, effettua una richiesta separata al server applicativo e cifra la risposta prima di restituirla. Il traffico non OHTTP salta questa elaborazione del gateway, quindi un’applicazione può continuare ad accettare anche normali richieste HTTP.

Il servizio supporta OHTTP standard e OHTTP a blocchi, che suddivide i messaggi in parti elaborabili progressivamente. Cloudflare consiglia l’opzione a blocchi per ottenere prestazioni migliori. Secondo quanto riferisce l’azienda, il progetto affronta le difficoltà incontrate dai clienti di Cloudflare OHTTP Relay che gestivano i propri gateway.

Legare il gateway a una zona limita anche le destinazioni a cui può inoltrare le richieste. Per una zona denominata example.com, i client possono indirizzare le richieste a foo.example.com o bar.example.com, ma non a wikipedia.com. Questa restrizione mira a impedire ai client non autorizzati di utilizzare il gateway di un cliente per indirizzare traffico verso domini estranei.

Cloudflare gestisce anche le chiavi di cifratura. Ai client serve una configurazione della chiave pubblica HPKE, ossia informazioni che consentono loro di cifrare messaggi che il gateway può decifrare. La recuperano inviando una richiesta GET, l’operazione web standard per ottenere una risorsa, a /.well-known/ohttp-gateway. Cloudflare afferma che i client possono rafforzare la privacy ottenendo queste chiavi tramite un indirizzo IP diverso da quello utilizzato per contattare il gateway.

Affidarsi al relay senza riunire entrambi i ruoli

Poiché il gateway riceve deliberatamente poche informazioni sul client originario, si affida al relay per autenticare i client e inoltrare il traffico in modo responsabile. Cloudflare Access, il prodotto dell’azienda per la verifica delle autorizzazioni di accesso, interviene prima che le richieste del gateway vengano decifrate. I clienti possono applicare le sue regole standard per limitare i relay autorizzati a connettersi.

Le opzioni supportate includono TLS reciproco, in cui entrambe le parti dimostrano la propria identità tramite certificati digitali; credenziali di servizio statiche, ossia credenziali fisse utilizzate dal software; e logica esterna personalizzata, ovvero verifiche fornite da un altro sistema. Questi controlli contrastano gli abusi senza richiedere al gateway di acquisire la visibilità sull’utente di cui dispone il relay.

Cloudflare descrive inoltre una misura di protezione per evitare che i clienti affidino accidentalmente entrambi i lati del confine a tutela della privacy allo stesso fornitore. Il suo gateway rifiuta di decifrare richieste provenienti da Cloudflare Workers, la sua piattaforma per l’esecuzione di applicazioni, o da host il cui traffico passa attraverso Cloudflare come proxy. Lo scopo dichiarato è impedire a Cloudflare di vedere sia le identità dei client sia le richieste interne decifrate.

Per le aziende che valutano come mantenere separate queste responsabilità, AEU-I offre servizi IT, infrastrutturali e di consulenza che mettono al primo posto la sicurezza, utili per esaminare la progettazione di un’applicazione in cui la privacy è un aspetto delicato.

L’annuncio fornito si interrompe nel corso di un confronto tra Cloudflare OHTTP Gateway e Cloudflare OHTTP Relay, quindi non presenta indicazioni complete per la scelta né le condizioni commerciali. Descrive però un gateway gestito con gestione delle chiavi, autenticazione dei relay e restrizioni volte a preservare la separazione della fiducia. Per i proprietari delle applicazioni, questa separazione è il requisito fondamentale da verificare, non semplicemente il fatto che il traffico sia cifrato.