Résumé

  • La RFC 9540 ajoute le paramètre vide ohttp aux enregistrements SVCB ou HTTPS et indique une passerelle située sur le même hôte à l’adresse /.well-known/ohttp-gateway.
  • Elle ne découvre pas le relais et ne transforme ni un certificat valide, ni une clé exploitable, ni une requête achevée en preuve globale de confidentialité.
  • Une clé, une redirection ou un dohpath propre à un client peut reformer son identité ; il faut donc un reçu de cohérence indépendant.

Le déploiement paraissait irréprochable. La zone DNS annonçait ohttp, les certificats étaient valides, la passerelle répondait et les requêtes revenaient du résolveur. Pourtant, l’équipe de contrôle découvrit que les clients d’un même bureau recevaient une configuration de clé différente de celle observée ailleurs.

Le chiffrement n’avait pas cédé. Le classement des utilisateurs avait eu lieu avant lui.

C’est l’intérêt politique et opérationnel de la RFC 9540, publiée en février 2024. Elle normalise la découverte de services Oblivious HTTP au moyen des enregistrements Service Binding et un chemin de récupération des clés. Mais elle décrit aussi les moyens par lesquels la découverte peut devenir une surface de ciblage. Elle oblige ainsi à distinguer ce qu’annonce le contrôle DNS de ce que produit réellement la chaîne de confidentialité.

Une valeur vide, plusieurs décisions

Le paramètre ohttp ne transporte aucune donnée : sa valeur doit être vide dans la présentation comme sur le fil. Sa présence signifie que le service décrit peut être joint comme cible OHTTP par l’intermédiaire d’une passerelle associée.

Ce simple indicateur gouverne pourtant la sélection. S’il figure dans mandatory, un client qui ne le comprend pas doit ignorer l’enregistrement. S’il n’est pas obligatoire, OHTTP reste une possibilité parmi d’autres. Plusieurs enregistrements peuvent présenter des configurations concurrentes.

Il faut conserver la portée exacte du reçu : telle autorité DNS a annoncé cette capacité, à cet instant, avec ce TTL et ces règles de sélection. L’annonce ne dit pas quel chemin le client a finalement utilisé. Elle ne certifie pas la passerelle et ne garantit pas que tous les clients verront la même clé. Sur un DNS en clair non protégé par DNSSEC, un intermédiaire peut même retirer l’information et provoquer un rabattement. Interroger systématiquement la ressource bien connue ou associer DNS chiffré et DNSSEC limite cette attaque ; cela ne prouve toujours pas le comportement ultérieur du service.

Le relais demeure une décision extérieure

L’architecture OHTTP distribue la connaissance. Le relais voit l’adresse réseau du client et la destination de la passerelle, mais pas le message encapsulé. La passerelle ouvre l’enveloppe sans devoir connaître l’identité réseau du client. La cible fournit la réponse applicative.

La RFC 9540 découvre la cible et la passerelle. Elle exclut explicitement la découverte des relais. Le client est supposé disposer déjà d’un relais de confiance capable de joindre la passerelle ou de lui indiquer les passerelles accessibles.

Cette hypothèse doit rester visible dans tout dossier d’approbation. Qui choisit le relais ? Quelles traces conserve-t-il ? Dans quelle juridiction ? Partage-t-il un opérateur, un sous-traitant ou un identifiant avec la passerelle ? Un produit peut être entièrement conforme à la RFC 9540 et rester incapable de répondre. L’expression « service OHTTP découvert » ne saurait couvrir ce vide de gouvernance.

La ressource bien connue doit être parcourue deux fois

Une fois ohttp repéré, le client utilise /.well-known/ohttp-gateway sur le même hôte que la cible. Un serveur peut rediriger cette ressource vers une autre adresse. Le détail essentiel est que le client ne doit pas transmettre au relais l’adresse de redirection qu’il a lui-même reçue.

Sinon, la passerelle pourrait remettre à chaque client une URL différente puis reconnaître cette valeur lorsqu’elle réapparaît par le relais. Le relais doit repartir de l’adresse bien connue et suivre lui-même toute redirection. Une redirection commune peut être mémorisée ; une redirection personnalisée ne doit pas devenir le ticket de routage.

L’observation opérationnelle doit donc conserver deux parcours distincts : celui de la récupération de configuration par le client et celui de la requête encapsulée par le relais. Réduire les deux à une unique « URL finale » efface précisément l’écart qui signalerait le ciblage.

La récupération de clé précède la protection

Pour construire son message, le client demande la configuration de la passerelle avec un GET portant Accept: application/ohttp-keys. Lorsqu’il effectue cette demande directement, il révèle son adresse IP à la passerelle. Ce fait peut être compatible avec un service qui cherche seulement à dissocier les requêtes d’une adresse déjà connue. Il contredit une promesse plus forte de dissimulation de la localisation.

Un mandataire peut cacher l’adresse pendant cette étape. Mais la question centrale n’est pas seulement qui voit le client : c’est ce que la passerelle choisit de lui rendre. Une configuration cryptographiquement correcte peut être unique. Or les requêtes OHTTP peuvent être rapprochées par la configuration utilisée. Distribuer une clé A à une seule personne et une clé B à tous les autres fabrique un groupe d’un seul membre sans casser le chiffrement.

La RFC recommande donc une technique de cohérence, par exemple la confirmation de la clé via un mandataire partagé. Si le client constate une configuration ciblée, il peut abandonner la passerelle et la signaler. Une organisation doit préciser la population comparée, la fenêtre temporelle, les points d’observation indépendants et la politique de rotation. « Clé valide » et « clé commune » sont deux attestations différentes.

Le chemin DoH peut jouer le rôle d’un nom

Dans le cas d’un résolveur DoH oblivious, le dohpath ajoute une autre possibilité d’identification. Un chemin propre à chaque client permet de reconnaître celui-ci même si la clé est commune et la charge utile chiffrée.

Le client peut n’autoriser qu’une valeur connue telle que /dns-query{?dns}. S’il accepte des chemins arbitraires, il devrait les comparer à une autre source. La RFC admet que ces contrôles puissent être échantillonnés selon la capacité et le modèle de menace. Un échantillon produit toutefois une assurance sur les événements contrôlés, pas une certitude générale.

La différence entre DDR et DNR compte également. Avec DDR, les vérifications de certificat prévues pour le résolveur découvert restent nécessaires. Avec DNR, les paramètres peuvent provenir de DHCP ou d’annonces de routeur et l’autorité de désignation suit un autre modèle. Dans les deux cas, la validité du point de terminaison ne dit rien sur l’unicité éventuelle du chemin remis au client.

Neuf reçus, neuf affirmations

Un service gouvernable sépare l’annonce ohttp, la compréhension de son statut obligatoire, l’acceptation de l’autorité DDR ou DNR, la validation du point de terminaison, l’obtention d’une clé analysable, la cohérence de la clé et du chemin, l’acceptabilité du relais, l’achèvement de la transaction et le résultat de confidentialité revendiqué.

La réussite du dernier paquet ne répare pas une désignation douteuse. Un certificat valide ne démontre pas que deux utilisateurs ont reçu la même clé. Une clé commune ne démontre pas l’indépendance des opérateurs. L’issue de confidentialité est une conclusion bornée, établie à partir de plusieurs observations et non un état retourné par l’analyseur DNS.

Cette séparation ne dévalorise pas OHTTP. Elle rend son déploiement honnête. L’annonce ouvre un chemin contrôlé vers une possibilité de confidentialité ; seule la conservation des reçus permet de dire jusqu’où cette possibilité a été réalisée.

Sources