Résumé

  • CONNECT classique nomme la destination TCP, mais pas le service proxy par une origine et un chemin qui lui soient propres. Le nouveau mode utilise un modèle d’URI et transporte le flux dans des capsules.
  • L’IESG a approuvé le projet pour publication comme Proposed Standard le 30 octobre. Une passerelle compatible devra convertir le nouveau tunnel entre les versions HTTP qu’elle prend en charge ; le dossier ne donne aucun chiffre de déploiement.

Le proxy a enfin une adresse. La passerelle, elle, reçoit une tâche de plus.

Depuis des années, CONNECT permet à un client de demander à un proxy une connexion TCP vers un hôte et un port. Le proxy transporte ensuite les octets entre le client et cette destination. Mais la requête désigne le tunnel et son point d’arrivée, pas le service proxy lui-même. Elle ne lui donne ni chemin ni origine explicites.

Ce détail compte dès qu’un même serveur HTTP héberge plusieurs services proxy. Sans chemin ou origine de service, il ne peut pas les distinguer comme il distingue des ressources Web ou des hôtes virtuels. Le projet pointe aussi un effet de sécurité : sans origine explicite pour le proxy, les protections habituelles contre les attaques de confusion de port côté serveur ne s’appliquent pas comme prévu ; la portée de réponses telles que Alt-Svc ou Strict-Transport-Security devient ambiguë.

Le 30 octobre, l’IESG a approuvé draft-ietf-httpbis-connect-tcp pour publication comme Proposed Standard. La version 17 du texte date de la veille. Le projet propose une nouvelle façon de transporter TCP dans HTTP ; il ne décide pas quelles destinations un utilisateur est autorisé à joindre. Le proxy obtient une adresse mieux définie. La décision d’accès reste entre les mains de son opérateur.

Le service est identifié par un modèle d’URI comportant target_host et target_port. Le client y insère la destination avant d’envoyer la requête au proxy. En HTTP/1.1, il utilise GET puis Upgrade vers connect-tcp. En HTTP/2 et HTTP/3, il envoie un Extended CONNECT dont :protocol vaut connect-tcp. Le proxy annonce sa prise en charge dans ses paramètres.

Le flux TCP voyage dans le protocole Capsule. DATA transporte les octets ; FINAL_DATA transporte les derniers octets et signale la fermeture équivalente à FIN. Les limites des capsules ne prétendent pas reproduire celles des segments TCP ou des enregistrements TLS. Elles emballent le flux dans HTTP.

L’origine et le chemin donnent au service proxy une place claire dans les sémantiques HTTP. Un serveur peut distinguer ses services, et les en-têtes liés à l’origine ont enfin une portée définie. Mais l’autorisation demeure une décision distincte : le proxy doit toujours appliquer ses propres règles de destination. Un modèle d’URI n’est pas une liste de contrôle d’accès.

Voici la facture : une passerelle qui promet la compatibilité doit gérer Upgrade en HTTP/1.1 ou Extended CONNECT, transférer le protocole connect-tcp et convertir les requêtes entre les versions HTTP qu’elle prend en charge. Elle doit aussi laisser passer Proxy-Status. Si l’origine authentifie les clients par certificat TLS, la passerelle doit effectuer cette authentification ou transmettre les informations du certificat à l’origine.

L’IESG a écrit ce relais dans les exigences. Il n’a pas mis à jour les passerelles. Le projet et le journal de décision ne donnent ni nombre de passerelles déployées, ni prévision d’adoption, ni résultat d’interopérabilité en production. Une norme peut fixer la forme des messages ; les opérateurs doivent encore recenser chaque proxy, intermédiaire et frontière d’authentification concernés.

Sources