Résumé

  • Dans RFC 9458, le relais connaît la provenance réseau du client sans pouvoir lire sa requête ; la passerelle déchiffre la requête sans recevoir cette provenance. Les deux fonctions ne peuvent appartenir à la même entité si l'objectif de confidentialité doit subsister.
  • Cette dissociation peut être annulée par le contenu lui-même : cookie, identifiant stable, configuration HPKE propre à un appareil, contexte réutilisé, journal partagé, faible volume ou corrélation temporelle recréent un lien que le chiffrement avait retiré du trajet.
  • Le travail de Christopher A. Wood, coauteur avec Martin Thomson, définit moins une garantie universelle qu'une incapacité à entretenir : chaque exploitation doit prouver la séparation des pouvoirs, la fraîcheur cryptographique, la sûreté des rejouements et la réalité de l'ensemble d'anonymat.

Analyse : la confidentialité commence là où l'observation s'arrête

Un service ordinaire sous HTTPS réunit souvent deux informations dans la même main : l'adresse réseau qui établit la connexion et le message en clair que l'application doit traiter. La liaison est utile au diagnostic, à la lutte contre les abus et à la personnalisation. Elle est aussi un pouvoir de corrélation.

Oblivious HTTP modifie ce pouvoir. Le client prépare un message HTTP binaire, le protège avec une configuration de clé de passerelle et l'envoie à un relais sur HTTPS. Le relais voit arriver le client, mais reçoit une enveloppe HPKE qu'il ne sait pas ouvrir. Il transmet l'enveloppe à la passerelle sur un second trajet HTTPS. La passerelle l'ouvre et contacte la ressource cible ; son homologue réseau est le relais, non le client d'origine. La réponse revient dans le sens inverse, protégée pour le client.

La propriété importante n'est donc pas l'absence de données. Chaque rôle en possède. Elle est l'absence d'un observateur complet. Le relais peut répondre « d'où ? », la passerelle « quoi ? », mais aucun ne devrait répondre seul aux deux questions.

RFC 9458 emploie une formule sans ambiguïté : relais et passerelle ne peuvent être la même entité pour atteindre les objectifs annoncés. La norme ne transforme toutefois pas « entité » en organigramme prêt à auditer. Deux noms de domaine peuvent dépendre de la même équipe. Deux sociétés peuvent verser leurs traces dans le même entrepôt. Deux fournisseurs peuvent partager un sous-traitant d'analyse ou une procédure d'incident qui donne accès aux deux journaux.

En déduire qu'une séparation juridique, administrative et informationnelle doit accompagner la séparation protocolaire est une analyse éditoriale, non une citation de la RFC. Mais sans cette analyse, la conformité devient cosmétique : deux chemins sur le schéma, une seule mémoire dans l'exploitation.

Situer Christopher A. Wood sans transformer l'auteur en garant

Publié en janvier 2024 sur la voie normative de l'IETF, RFC 9458 porte les noms de Martin Thomson et Christopher A. Wood. Le dossier Datatracker consulté le 1er septembre 2026 présente Wood comme ingénieur chez Apple dans le domaine de l'ingénierie cryptographique et lui attribue 24 RFC, dont celle-ci. Ces renseignements sont datés et pourront évoluer. Ils n'en font ni l'inventeur unique d'OHTTP, ni le contrôleur d'une mise en œuvre extérieure.

Deux ans avant la publication finale, Wood et Jonathan Hoyland avaient décrit une analyse assistée par ordinateur du protocole. Leur modèle Tamarin autorisait l'adversaire à observer le réseau et à compromettre soit le relais, soit la passerelle, tout en supposant que ces deux acteurs ne collaboraient pas et que le relais ne livrait pas d'information identifiante à la passerelle.

Le dépôt public conserve des propriétés vérifiées concernant le secret des requêtes et réponses, leur liaison, leur cohérence et l'usage des nonces. La propriété d'impossibilité de liaison exposée dans l'article est conditionnelle : pour connaître à la fois la requête et la connexion chiffrée arrivée au relais, l'adversaire doit avoir compromis les deux rôles. Les auteurs précisent que cela n'établit pas une indiscernabilité générale. L'inférence directe et les statistiques sur le trafic restent des voies d'attaque.

Cette précision est plus précieuse qu'un slogan. Une preuve formelle borne ce qu'un modèle autorise. Elle ne sait pas si le même administrateur dispose des deux consoles, si les journaux sont centralisés, si un jeton de compte se trouve dans le message ou si une région ne compte que trois utilisateurs actifs. La contribution intellectuelle de Wood se lit dans cette frontière explicite : la cryptographie est démontrable à l'intérieur d'hypothèses que l'exploitation doit ensuite rendre vraies.

La passerelle n'est pas la ressource cible

Dans la représentation la plus courte d'OHTTP, la passerelle ressemble à un tunnel transparent. Elle ne l'est pas. La protection de message relie le client à la passerelle, pas directement le client à la ressource cible. Après décapsulation, la passerelle choisit comment joindre la cible et peut déterminer la réponse renvoyée au client.

Le client doit donc savoir quelle passerelle est autorisée pour quelle cible et authentifier sa configuration de clé. Une politique de certificat épinglé directement à la cible ne se transpose pas simplement à cette relation médiée. La provenance de la configuration devient une décision de sécurité : substituer la clé, c'est déplacer le point où le texte clair apparaît.

Une configuration distribuée à un seul appareil crée en outre un autre problème. Même correcte du point de vue cryptographique, elle forme un identifiant. Chaque configuration active découpe l'ensemble d'anonymat. L'opérateur doit connaître le nombre réel de clients qui la partagent, la période de chevauchement lors d'une rotation et les segmentations par pays, version ou compte.

Une autorisation de cible, une liste blanche de passerelle et une liaison HTTPS entre passerelle et cible limitent des détournements. Elles ne suppriment pas la responsabilité d'expliquer ce que la passerelle peut faire à la place de la cible et ce que le client a réellement authentifié.

Le message en clair peut rendre l'adresse superflue

La plus parfaite indépendance entre opérateurs ne protège pas un message qui se présente lui-même. Un cookie de session, un jeton d'autorisation, un numéro de compte, un identifiant d'appareil ou une combinaison extrêmement rare de paramètres suffisent à relier la demande à une personne. Dans ce cas, la passerelle n'a pas besoin de l'adresse IP que le relais lui cache.

RFC 9458 limite donc son applicabilité aux usages où le contenu ne transporte pas un état corrélable. La sobriété doit être vérifiée sur les octets encodés, après le passage des bibliothèques clientes et des mécanismes de reprise. Un contrat d'API déclarant « sans cookie » ne voit pas forcément l'en-tête ajouté par un kit logiciel, la valeur de télémétrie stable ou le code d'erreur repris dans la requête suivante.

Le relais a une obligation symétrique : il ne doit pas ajouter des champs Via ou Forwarded qui révèlent le client. Une architecture peut donc échouer de trois manières distinctes : le client s'identifie dans le contenu, le relais transmet l'origine, ou les journaux relient après coup l'origine et le contenu. Un test limité au déchiffrement ne détecte aucune de ces fautes.

La bonne preuve est un inventaire répété. Pour chaque version cliente, il faut capturer la représentation binaire avant encapsulation, classer chaque valeur stable, expliquer sa nécessité et vérifier les chemins de succès, d'erreur et de reprise. La confidentialité est une propriété des données effectivement envoyées, pas du nom donné à la fonctionnalité.

Fraîcheur, rejeu et durée de compromission

HPKE, défini par RFC 9180, combine mécanisme d'encapsulation de clé, dérivation et chiffrement authentifié pour établir des contextes de protection. RFC 9458 exige un contexte neuf pour chaque requête OHTTP. La réutilisation ne constitue pas une simple imperfection de performance : elle peut rendre des échanges corrélables et, dans certaines conditions, livrer du contenu au relais.

Une nouvelle tentative doit elle aussi repartir avec un état HPKE neuf. Le client ne peut déduire d'un délai dépassé que l'action n'a pas eu lieu. Une opération modifiant un compte ou déclenchant un paiement peut être exécutée deux fois. L'application doit rejeter le rejeu ou rendre son effet idempotent. Une reprise automatique n'est sûre que si la réponse affirme positivement que la première requête n'a pas été traitée.

La valeur d'encapsulation peut servir de nonce. Une date peut borner une fenêtre, mais elle impose une horloge, une tolérance et une durée de conservation. RFC 8470 fournit un vocabulaire voisin pour le rejeu de données HTTP précoces ; elle ne choisit pas la sémantique métier d'une action OHTTP.

La clé longue durée de la passerelle crée une autre fenêtre. OHTTP ne fournit pas de secret persistant vers l'avenir pendant toute la vie d'une configuration. Une clé privée compromise, associée à du trafic enregistré ou à la coopération du relais, peut ouvrir l'historique protégé sous cette configuration. Il faut donc prouver la rotation et surtout la suppression : nœuds, sauvegardes, images de diagnostic et systèmes d'incident compris.

Le volume et le temps peuvent parler

Les deux connexions HTTPS sont obligatoires, mais elles ne rendent pas tous les objets de même taille ni tous les clients simultanés. Une requête rare de 43 kilo-octets quittant un appareil, suivie presque immédiatement d'un objet de même profil entrant à la passerelle, constitue un signal. Quand le service a peu d'utilisateurs, le simple ordre des événements peut suffire.

Le bourrage réduit la précision des tailles ; l'attente, la mise en lot ou une gigue contrôlée réduit celle du temps. Ces mesures consomment bande passante, latence et capacité. Elles doivent être annoncées comme des paramètres de confidentialité. Les désactiver pendant une surcharge peut modifier le niveau réel de protection sans toucher à une ligne de cryptographie.

Le relais peut aussi réduire l'ensemble d'anonymat en traitant différemment certains clients. Blocage sélectif, limitation de débit et marquage contre les abus peuvent isoler un flux. Une métrique sérieuse suit donc le nombre de clients actifs par configuration et par fenêtre temporelle, la singularité des tailles, la concentration des relais et les exceptions de routage.

Une preuve d'exploitation plutôt qu'un badge OHTTP

Le dossier de contrôle devrait commencer par quatre propriétaires : client, relais, passerelle et cible. Pour chacun, inscrire l'entité juridique, les comptes d'infrastructure, les administrateurs, les prestataires, les régions, les journaux, leur rétention et les droits d'accès en incident. Les traits qui relient deux colonnes sont les risques principaux.

Pour la configuration de passerelle, conserver émission, signature, cible autorisée, canal de distribution, taille de population, expiration, rotation et reçu de suppression. Pour le client, conserver l'inventaire des champs, le contrôle des contextes neufs et le comportement de reprise. Pour le relais, vérifier l'absence de métadonnées identifiantes ajoutées et l'absence de traitement différentiel capable d'étiqueter un flux. Pour la passerelle, limiter la trace du texte clair et des clés.

Le rapport doit aussi simuler séparément une compromission du relais, de la passerelle, de l'entrepôt de journaux et d'un compte d'administration commun. « Un composant compromis » est une catégorie trop large : chaque scénario donne à l'attaquant une connaissance différente et appelle un confinement différent.

La primauté du code en fonctionnement défendue par Heng Lu invite à créditer OHTTP de ce qu'il exécute réellement : une séparation de visibilité. Elle interdit d'en déduire une indépendance institutionnelle que le protocole ne peut observer. Sa notion de spécification initiale minimale rappelle qu'un noyau commun peut faciliter l'adoption, à condition que les mises en œuvre locales ne suppriment pas l'hypothèse qui rend ce noyau utile.

Au fond, la confidentialité d'OHTTP est une incapacité organisée. Aucun acteur ne doit obtenir seul le tableau complet. Ce n'est pas une faiblesse de la norme ; c'est sa proposition la plus forte. La responsabilité des opérateurs est de rendre cette incapacité durable face aux clés, aux journaux, aux urgences et aux incitations économiques qui cherchent constamment à réunir les deux moitiés.

Sources