Résumé

  • draft-ietf-httpbis-connect-tcp-14 fait d’un modèle d’URI contenant target_host et target_port le point d’entrée configuré d’un proxy TCP.
  • L’URI obtenu rattache la demande à une origine HTTP, un chemin, un espace de protection et une politique de destination ; la provenance du modèle devient donc une donnée d’autorisation.
  • L’IESG recueille les commentaires jusqu’au 1er octobre 2026. Le texte reste un Internet-Draft, sans preuve d’approbation finale, de mise en œuvre ni de déploiement.

Une adresse qui choisit aussi le gardien

Le CONNECT classique met en avant la machine et le port à joindre. Le projet CONNECT-TCP ajoute une étape : le client reçoit un modèle d’URI, y insère l’hôte et le port cibles, puis adresse la requête à l’origine du proxy.

Cette étape détermine davantage qu’une syntaxe. Elle choisit l’origine qui recevra les identifiants, le chemin que la passerelle acheminera, l’espace de protection auquel l’authentification s’appliquera et le contexte des en-têtes liés à l’origine. Alt-Svc, HSTS ou un cookie ne se rattachent pas à une abstraction neutre ; ils s’attachent à cette origine.

Le projet reprend les contraintes de RFC 9298. Le modèle doit être absolu, fournir des composants scheme, authority et path non vides, garder les variables dans le chemin ou la requête et contenir les deux paramètres cibles. Plusieurs opérateurs d’expansion sont interdits. Un client qui détecte une configuration invalide doit l’abandonner avant l’envoi.

Cette validation établit la conformité d’une construction. Elle n’établit ni l’identité du diffuseur du modèle, ni son mandat pour modifier le point de sortie, ni l’appartenance de l’origine au service prévu. Une expansion exacte peut conduire avec précision au mauvais gardien.

Les réponses HTTP décrivent des étapes différentes

En HTTP/1.1, le client envoie une requête GET vers l’URI calculé et demande la mise à niveau connect-tcp. Si la requête est bien formée et admissible, le proxy doit tenter la connexion TCP avant de rendre une réponse finale, sauf un éventuel 100 Continue. Une connexion réussie conduit à 101 Switching Protocols.

En HTTP/2 et HTTP/3, le proxy annonce extended CONNECT. Le client utilise :protocol = connect-tcp, place l’origine du proxy dans :authority et fournit le scheme et le path issus du modèle. Une réponse CONNECT réussie ouvre le flux au Capsule Protocol.

La présence de 100 Continue est éclairante. Elle signifie que le proxy a reçu la demande et ne l’a pas rejetée immédiatement. Elle ne dit rien encore du handshake vers la destination. Le 101 ou la réussite d’extended CONNECT constitue un reçu plus fort : le proxy déclare avoir établi TCP. Ce reçu ne valide ni le certificat TLS du service, ni l’identité applicative, ni la livraison d’un message, ni l’exécution d’un ordre.

Un tableau de bord qui résume ces états par « connexion réussie » efface trois pannes différentes : refus avant tentative, échec de la connexion cible, échec de l’application après ouverture du tunnel.

L’authentification HTTP reste celle du proxy

Parce que le service possède une origine explicite, il utilise normalement 401, WWW-Authenticate et Authorization. Le projet écarte le schéma 407 du proxy classique, qui ne traverse pas les passerelles HTTP ordinaires. Les ressources produites par un même modèle sont supposées partager un espace de protection ; un certificat client TLS est également possible.

L’avantage est réel. L’opérateur peut réutiliser routage par chemin, défense DDoS, normalisation des requêtes et autorisation utilisateur. Un chemin à forte entropie ou une authentification dissimulée peut réduire la visibilité du service pour une sonde non autorisée.

Mais l’objet de la preuve ne change pas. Un identifiant accepté établit le résultat du mécanisme d’authentification pour l’espace de protection du proxy. Une règle distincte autorise ou refuse l’hôte et le port. La résolution choisit une adresse. Le TLS de destination vérifie un autre pair. Enfin, l’application décide si l’acteur peut produire l’effet demandé.

RFC 9110 rappelle qu’un CONNECT ouvert vers des ports arbitraires peut transformer le proxy en relais pour des protocoles imprévus. Le modèle d’URI ne supprime pas cette menace ; il donne à la décision une surface HTTP plus explicite.

La capsule transporte l’ordre, pas le sens du métier

Les octets TCP circulent dans des capsules DATA. FINAL_DATA peut porter les derniers octets et annonce en plus la fermeture de ce sens, comme un FIN TCP. Après FINAL_DATA, aucun DATA ni second FINAL_DATA n’est permis. Un FIN reçu côté TCP doit devenir FINAL_DATA ; un FINAL_DATA valide doit devenir FIN.

Les frontières des capsules ne correspondent pas nécessairement aux segments TCP, aux enregistrements TLS, aux trames HTTP ou aux messages de l’application. Un intermédiaire peut fusionner ou découper des capsules successives s’il préserve l’ordre des octets et la nature finale DATA ou FINAL_DATA.

Le contrat commun est donc volontairement étroit. Il transporte une séquence et une demi-fermeture. Il ne certifie pas la réception par le programme cible. Un client peut avoir écrit dans le flux HTTP alors que le proxy retient encore les données optimistes. Le proxy peut avoir écrit dans une socket sans que l’application ait traité le contenu. FINAL_DATA peut préserver un FIN tandis que le retour se termine par un reset.

En HTTP/2 ou HTTP/3, les données optimistes doivent rester en mémoire jusqu’à ce que la connexion choisie soit inscriptible et être supprimées si elle échoue. Lors d’une course entre plusieurs adresses, aucune charge utile ne doit partir vers les connexions perdantes. Il faut donc conserver séparément provenance du modèle, certificat du proxy, authentification, règle de destination, adresse choisie, tentative TCP, statut HTTP, ordre DATA/FINAL_DATA, TLS cible, compteurs d’octets et résultat applicatif.

La Last Call ne vaut pas publication

L’annonce de l’IESG ouvre les commentaires jusqu’au 1er octobre. Datatracker classe la révision 14 comme active, soumise à l’IESG et destinée au statut Proposed Standard.

Ces éléments décrivent une procédure en cours. Le document peut encore changer, être remplacé ou expirer. Même un futur RFC établirait un contrat d’interopérabilité, pas la présence du code, la compatibilité des passerelles, la bonne gestion des fermetures ni l’adoption d’une politique sûre.

La primauté du code en exécution impose de ne faire porter à chaque reçu que ce qu’il observe. Le principe de spécification initiale minimale indique où arrêter le commun : syntaxe, ordre, fermeture et erreurs. La confiance dans le provisionnement, l’admission des cibles et la définition du succès demeure locale.

Le proxy peut autoriser un tunnel. Il ne peut pas authentifier par procuration toute la réalité qui se trouve derrière.

Sources