Cloudflare a commencé un test fermé de Cloudflare OHTTP Gateway, une fonctionnalité payante pouvant être activée sur le domaine du client afin de recevoir du trafic Oblivious HTTP (OHTTP) via une infrastructure gérée. Le service s’adresse aux développeurs qui souhaitent dissimuler l’adresse IP et les indicateurs d’identification du client aux serveurs de leurs applications, notamment lorsque ces serveurs sont hébergés derrière le réseau Cloudflare ou sur Workers.
Parallèlement, l’entreprise a renommé son ancien produit Privacy Gateway en Cloudflare OHTTP Relay. Ce changement reflète l’existence de deux produits distincts dans le modèle OHTTP : le relais transmet les requêtes chiffrées et dissimule l’identité du client, tandis que la passerelle prend en charge le déballage chiffré de la requête et le remballage de la réponse avant sa remise au serveur d’application.
Comment fonctionne le modèle OHTTP ?
Dans une connexion traditionnelle, le serveur d’application peut voir l’adresse IP du client, les caractéristiques TLS et les informations de localisation, ce qui peut permettre de relier plusieurs requêtes au même utilisateur. Avec OHTTP, la requête passe par un relais indépendant qui retire les indicateurs d’identité du client avant de la transmettre. Le contenu de la requête reste chiffré à l’aide de Hybrid Public Key Encryption (HPKE), de sorte que le relais ne voit pas le texte en clair.
Ensuite, la passerelle traite la partie cryptographique et transmet la requête au serveur d’application sous la forme HTTP habituelle. Il en résulte une séparation de la confiance : le relais voit l’identité de la connexion, mais pas le contenu de la requête, tandis que la passerelle et le serveur d’application voient le contenu de la requête sans disposer de l’identité directe du client. Ce modèle exige que les deux entités assumant les rôles de relais et de passerelle ne gèrent pas ces fonctions de manière collusoire.
Qu’ajoute la nouvelle passerelle ?
OHTTP Gateway fonctionne comme une fonctionnalité au sein du domaine Cloudflare et peut être activée via des points d’accès spécifiques tels que /.well-known/ohttp-gateway. Le service prend en charge OHTTP standard et Chunked OHTTP, avec une recommandation d’utiliser le type fragmenté pour traiter les requêtes progressivement. Cloudflare gère également les clés publiques HPKE et les fournit aux clients, au lieu de laisser au client la responsabilité de gérer le cycle de vie des clés.
Le service bénéficie du réseau mondial de Cloudflare, ce qui permet d’exécuter la passerelle à la périphérie du réseau et de réduire la latence entre le relais et la passerelle. Si les serveurs d’application utilisent le CDN de l’entreprise, la requête et l’accès au serveur peuvent être traités sur la même infrastructure. La passerelle traite uniquement les requêtes OHTTP, tandis que les requêtes ordinaires continuent d’atteindre le serveur sans passer par le traitement OHTTP.
Contrôles de confiance et utilisation
Cloudflare Access permet d’imposer des politiques d’authentification avant le déchiffrement des requêtes, notamment mutual TLS, des identifiants de service statiques et une logique externe personnalisée. La passerelle refuse également de déchiffrer les requêtes provenant de Cloudflare Workers ou d’hôtes faisant transiter leur trafic via Cloudflare, afin d’éviter que la même entité n’exploite le relais et la passerelle et d’affaiblir la séparation de la confiance sur laquelle repose OHTTP.
Cloudflare recommande d’utiliser OHTTP Gateway lorsque les serveurs d’application sont derrière Cloudflare ou lorsque la requête provient d’un relais et d’un client appartenant à un tiers, comme dans certains cas d’utilisation d’Apple LiveCallerID. De son côté, Cloudflare OHTTP Relay, sous son nouveau nom, convient à ceux qui souhaitent utiliser le relais Cloudflare tout en exécutant eux-mêmes la passerelle en dehors de Cloudflare.
Qu’est-ce qui change concrètement ?
Le nouveau service réduit la charge opérationnelle liée à la mise en place d’une passerelle OHTTP, mais n’élimine pas les exigences architecturales fondamentales. Le client doit en effet implémenter OHTTP, tandis que l’utilisateur a besoin d’un relais indépendant. Cloudflare souligne également que le relais doit être une entité digne de confiance en ce qui concerne l’absence d’inspection des journaux et l’absence de mise en relation des identités des clients avec les requêtes déchiffrées. OHTTP ne protège pas non plus les métadonnées présentes dans le corps de la requête lui-même ; il incombe donc au développeur de ne pas envoyer l’adresse e-mail, le nom d’utilisateur ou tout autre identifiant dans le contenu de la requête.
Le service est actuellement disponible dans le cadre d’un test fermé et d’une liste d’attente, et l’annonce n’a fixé ni date de lancement public ni détails tarifaires. Cette étape représente donc une expansion importante des outils de confidentialité réseau, mais elle exige encore des équipes de développement qu’elles prennent des décisions indépendantes concernant le relais, le contenu de la requête et le modèle de confiance entre les parties.