CONNECT

Utilisation

Une requête CONNECT demande à un proxy HTTP d’établir une connexion TCP vers l’hôte et le port indiqués, puis de relayer les octets bruts dans les deux sens. La cible de la requête utilise la forme authority (host:port) plutôt qu’un chemin.

Le principal usage de CONNECT est le tunnel HTTPS. Lorsqu’un client situé derrière un proxy doit atteindre un site HTTPS, la séquence se déroule ainsi :

Comme le proxy transmet des octets bruts une fois le tunnel établi, il n’a aucune visibilité sur le trafic chiffré. C’est le mécanisme qu’utilisent les proxys d’entreprise et de réseau pour autoriser l’accès HTTPS à des serveurs externes.

Si le proxy exige une authentification, le client inclut un en-tête Proxy-Authorization dans la requête CONNECT. Des identifiants manquants ou invalides donnent lieu à une réponse 407 Proxy Authentication Required.

Le standard WHATWG Fetch classe CONNECT parmi les méthodes interdites, ce qui empêche JavaScript d’émettre des requêtes CONNECT via les API du navigateur.

En HTTP/2 et HTTP/3, CONNECT crée un tunnel sur un flux unique plutôt que sur l’ensemble de la connexion TCP. La spécification HTTP/2 définit le CONNECT de base pour des flux individuels. La mise à niveau de protocole extended CONNECT ajoute un pseudo-en-tête :protocol qui permet d’utiliser WebSockets et d’autres protocoles sur une connexion multiplexée, avec une prise en charge à la fois en HTTP/2 et en HTTP/3. Le tunnel de flux de base et le extended CONNECT sont complémentaires : l’un fournit le tunnel brut, l’autre permet des protocoles non-TCP sur des connexions multiplexées.

Tunnel HTTPS à travers un proxy

Un client demande un tunnel TLS vers example.com sur le port 443 à travers un proxy. Le proxy authentifie le client grâce à l’en-tête Proxy-Authorization, ouvre la connexion TCP et confirme par un 200 OK.

Requête

CONNECT example.com:443 HTTP/1.1
Host: example.com:443
Proxy-Authorization: Basic dXNlcjpwYXNz

Réponse

HTTP/1.1 200 Connection Established

Après réception de la réponse 200, le client entame la négociation TLS avec example.com à travers le tunnel ouvert. Le proxy relaie toutes les données suivantes sans inspecter ni modifier le contenu.

Tunnel sans authentification

Lorsque le proxy n’exige pas d’identifiants, la requête ne contient que l’hôte et le port cibles.

Requête

CONNECT example.com:443 HTTP/1.1
Host: example.com:443

Réponse

HTTP/1.1 200 Connection Established

CORS

CONNECT est une méthode interdite par CORS. Les navigateurs bloquent toute tentative d’envoi de CONNECT via des API du navigateur telles que fetch() et XMLHttpRequest.

Tunnel HTTP

Le tunnel HTTP encapsule du trafic non HTTP dans des messages HTTP, ce qui permet à des protocoles comme HTTPS, SSH et FTP de traverser les proxys HTTP. CONNECT est le mécanisme principal pour établir ces tunnels. Le proxy ouvre une connexion TCP brute vers l’hôte et le port cibles, puis relaie les octets dans les deux sens sans inspecter le contenu.

En l’absence de proxy entre le client et le serveur, CONNECT est inutile. Les clients se connectent directement aux serveurs en utilisant le protocole cible.

Sécurité

Les proxys ouverts qui acceptent CONNECT vers des ports arbitraires ouvrent la voie aux abus : relais de spam via SMTP (port 25), balayage de ports de réseaux internes et contournement des contrôles d’accès réseau. Les proxys en production limitent CONNECT au port 443 (HTTPS) ou à une liste blanche de destinations approuvées.

L’OWASP identifie un CONNECT non restreint comme un risque de sécurité. Le standard WHATWG Fetch classe CONNECT parmi les méthodes interdites, ce qui empêche les navigateurs d’envoyer directement des requêtes CONNECT via fetch() ou XMLHttpRequest.