Présentation
Cloudflare a annoncé le lancement d’une passerelle OHTTP (Oblivious HTTP) accessible via son réseau d’envergure mondiale. L’objectif déclaré est d’étendre l’accès à une infrastructure qui sépare l’identité du client du contenu de la requête HTTP, réduisant ainsi la surface d’observation pour les intermédiaires. L’annonce se situe dans le cadre des initiatives de confidentialité de l’entreprise, mais le billet de blog ne fournit que peu de paramètres chiffrés (pas de version de protocole, de débit maximal ou de métriques de latence).
Architecture du service OHTTP
La passerelle s’appuie sur le modèle d’OHTTP défini par le groupe IETF, qui utilise un encapsulation hybride de clé publique (HPKE) pour chiffrer la charge utile du client avant qu’elle ne touche le serveur d’origine. Cloudflare agit comme un relay : il reçoit la requête chiffrée, la transmet au serveur cible, puis renvoie la réponse chiffrée au client. Cette séparation implique deux points d’attache distincts : le client (ou le SDK intégré) qui possède la clé publique du relay, et le serveur qui détient la clé privée correspondante. Le blog indique que la passerelle est déployée sur le même réseau d’edge que les services Workers, mais ne précise pas le nombre de nœuds ou la répartition géographique.
Le protocole conserve la sémantique HTTP standard : méthodes, en‑têtes et codes de statut sont transmis sans transformation, ce qui permet aux applications existantes de fonctionner sans modification du code serveur. L’utilisation de TLS 1.3 est mentionnée comme couche de transport, mais le texte ne détaille pas si le tunnel OHTTP repose exclusivement sur TLS ou s’il ajoute une couche de chiffrement supplémentaire via HPKE.
Analyse de la confidentialité et des limites
En théorie, la séparation du client et du contenu empêche un observateur du réseau (y compris le relay) d’associer une adresse IP à la charge utile HTTP. Cette propriété est pertinente pour les cas d’usage où la géolocalisation ou le suivi d’adresse IP constitue un risque de vie privée, comme les requêtes de recherche ou les appels d’API sensibles. Toutefois, l’efficacité dépend de la gestion des clés : la perte ou la compromission de la clé privée du relay annulerait la protection, et le blog ne décrit pas les mécanismes de rotation ou de stockage sécurisé de ces clés.
Un autre point d’attention concerne la latence. Le double chiffrement (TLS + HPKE) et le routage via un relay supplémentaire introduisent potentiellement un surcoût, mais aucune mesure de performance n’est fournie. De plus, le service ne semble pas offrir de garantie de disponibilité ou de SLA distincte, ce qui pourrait limiter son adoption dans des environnements à haute exigence de temps de réponse.
Enfin, le déploiement reste limité aux clients qui intègrent explicitement le SDK OHTTP ou qui utilisent les points d’accès fournis par Cloudflare. Les navigateurs grand public ne supportent pas encore nativement ce protocole, ce qui contraint son usage à des applications spécialisées ou à des services back‑end.
