Résumé

  • draft-ietf-httpapi-privacy-06 traite la redirection HTTP vers HTTPS comme un mauvais filet de sécurité pour une API authentifiée : le secret part dans la première requête, avant toute réponse du serveur.
  • HSTS, l’enregistrement DNS HTTPS, le refus du port 80, l’attribut Secure et le mode HTTPS exclusif interviennent à des étapes différentes. L’URL finale ne peut remplacer aucune de ces preuves.
  • Un identifiant reçu en clair doit conduire à un refus uniforme, à une qualification de l’exposition puis, selon sa nature, à une révocation. Le texte est approuvé par l’IESG et dans la file du RFC Editor, mais n’était pas encore un RFC le 1er octobre 2026.

La faute la plus discrète tient parfois à une lettre : http au lieu de https. Le programme ne s’arrête pas. Il ouvre la connexion, ajoute le jeton, envoie la requête, reçoit un 3xx, suit l’adresse sécurisée et obtient enfin ses données. Le test d’intégration devient vert. Le secret, lui, a franchi le réseau avant que la réparation ne commence.

La révision 06 force à raisonner dans l’ordre du fil. Une redirection n’est pas une consigne préalable : c’est la réponse à une requête déjà émise. TLS sur la seconde connexion protège la seconde connexion. Il ne retire aucune copie observée sur la première.

Quand la disponibilité maquille la perte de confidentialité

Sur le Web humain, guider un navigateur vers HTTPS améliore souvent l’expérience. Pour une API munie d’un secret réutilisable, cette tolérance transforme une mauvaise configuration en comportement durable. Le client réussit, l’utilisateur n’est pas alerté et les mesures de disponibilité récompensent précisément le mécanisme qui cache la fuite.

Le billet de terrain de mai 2024 à l’origine du travail rapporte une faute réelle de schéma et un relevé de services connus. Ce relevé reste une photographie historique, non une mesure actuelle de chaque fournisseur. Sa valeur durable vient de l’expérience reproductible : un client qui suit automatiquement la redirection peut envoyer deux fois le même pouvoir, d’abord sans protection puis sous TLS.

Il faut donc distinguer les reçus. La configuration dit quelle URI a été fournie. La résolution DNS et l’enregistrement HTTPS disent ce que le client a découvert. L’état HSTS dit ce qu’il avait appris auparavant. La capture du premier transport dit où les octets sont réellement partis. Le 3xx ou le 403 décrit la réaction. Le handshake TLS décrit la connexion suivante. La révocation décrit le sort du secret. L’autorisation et le reçu métier décrivent l’effet. Aucun voyant ne résume honnêtement toute cette suite.

Les contrôles utiles agissent avant l’envoi

La RFC 6797 permet à HSTS d’imposer des connexions sécurisées futures, mais la politique est apprise sur une connexion HTTPS antérieure et doit être conservée. Une bibliothèque sans magasin HSTS n’est pas protégée par la seule présence d’un en-tête côté serveur.

La RFC 9460 place l’information plus tôt : un enregistrement HTTPS peut orienter le choix avant la connexion. Encore faut-il que le client le demande, l’interprète et reçoive une réponse non supprimée. Le brouillon recommande l’association des deux mécanismes sans leur attribuer une perfection qu’ils n’ont pas.

Ne pas écouter en HTTP ferme une voie du serveur authentique. C’est une excellente réduction de surface, mais pas une authentification de ce qui répond sur le réseau. Un adversaire actif peut prendre la place du port absent. L’invariant ultime appartient donc au client : ne jamais joindre le secret à une requête dont le transport sûr n’est pas établi.

Les identifiants peuvent porter une restriction. L’attribut Secure de la RFC 6265 interdit l’envoi du Cookie dans un contexte non sûr. La RFC 8959 propose une forme secret-token qui communique un usage attendu. Une clé placée dans un en-tête propriétaire ne reçoit pas automatiquement cette discipline. Le nom du champ n’est pas une politique exécutable.

Refuser sans créer un oracle

Lorsque le port 80 doit rester ouvert, le brouillon recommande un 403 pour toute requête non chiffrée contenant un identifiant, qu’il soit valable ou non. La RFC 9110 permet ce refus pour une raison indépendante de la suffisance des identifiants. Renvoyer un message ou un temps différent selon la validité offrirait à l’attaquant un outil de vérification.

Ce refus marque l’incident ; il ne l’annule pas. Une clé API ou un bearer token transmis directement devient une capacité copiable et devrait être considéré comme compromis. Une signature ou un MAC dérivé peut ne révéler que la preuve d’un message : le secret sous-jacent, la liaison de la requête, le nonce et la rejouabilité doivent alors être examinés séparément.

Révoquer immédiatement crée à son tour une surface de déni de service : un attaquant peut présenter des valeurs devinées en HTTP pour tenter de faire révoquer la bonne. Limites de débit, fermeture de connexion, notification et délai contrôlé sont donc des choix de gouvernance de l’incident. Ils ne changent pas le fait observé sur le fil.

Le statut du texte ne doit pas être grossi

Le Datatracker classe le document au groupe HTTPAPI avec l’objectif Best Current Practice. Son historique consigne l’approbation de l’IESG et l’entrée dans la file du RFC Editor le 5 juin 2026. Au 1er octobre, la source demeure la révision 06 du 11 mai, sans numéro RFC.

Cette trajectoire atteste une revue institutionnelle, pas l’adoption par un SDK particulier. Le dossier signale même l’absence de rapports d’implémentation spécifiques. Le dépôt de travail documente l’élaboration du texte ; seul un essai du premier paquet peut démontrer le comportement d’un client.

La RFC 7258 élargit enfin le regard : la surveillance généralisée est une attaque, même sans secret réutilisable. Chemins, identifiants et intention opérationnelle méritent aussi une protection. Le jeton rend seulement la conséquence immédiatement transférable.

Un registre écrit dans l’ordre du temps

Conserver, pour chaque famille de clients, l’URI configurée, la version de bibliothèque, la politique de redirection, l’instant où le secret est attaché, le mode non sûr explicite, le résultat HTTPS RR, l’origine et l’âge de HSTS, le premier schéma réellement ouvert, le pair et le port, la classe d’identifiant, le premier statut, la destination de redirection, le pair TLS suivant, la qualification d’exposition, la mise en quarantaine ou la rotation, la décision d’autorisation et le reçu de l’opération.

Une absence reste une absence : hsts=none, exposition=possible, revocation=en_attente. L’ultime URL ne doit pas écraser le commencement de la trace.

La Spécification initiale minimale justifie ici une règle commune étroite : aucun secret réutilisable dans un transport non sûr. La Primauté du code en fonctionnement demande d’observer les premiers octets, pas l’intention. Le miroir des politiques montre le pouvoir réel des valeurs par défaut. Les couches de réalité empêchent enfin de confondre configuration, découverte, exposition, réponse, autorisation et effet.

Sources