HTTP CONNECT : comment un proxy HTTP transporte HTTPS
Suivez une requête HTTPS à travers un proxy HTTP, distinguez la réponse CONNECT de celle du serveur d'origine et repérez l'étape où le tunnel échoue.
« 200 Connection Established » signifie que le proxy accepte un tunnel. Le site web n'a pas encore renvoyé de page. Viennent ensuite TLS avec la destination, puis la requête HTTPS proprement dite.
De la connexion au proxy à la réponse du site
- Le client se connecte au point de terminaison du proxy.
- Il demande au proxy de se connecter à un hôte et à un port de destination.
- Le proxy accepte ou refuse cette demande.
- Après acceptation, le client négocie TLS avec la destination à travers le tunnel.
- Le client envoie la requête HTTPS et reçoit la réponse du site à l'intérieur de TLS.
Un refus de connexion au proxy, un rejet du tunnel et une erreur de certificat surviennent à des étapes différentes. Repérez la dernière étape achevée avant de modifier les paramètres.
L'échange CONNECT
En HTTP/1.1, un échange simplifié se présente ainsi :
CONNECT example.com:443 HTTP/1.1
Host: example.com:443
HTTP/1.1 200 Connection Established
La cible de la requête est un hôte et un port, sans chemin ni paramètres de requête du site. Après une réponse CONNECT réussie, la connexion transporte les octets du tunnel. Pour une destination HTTPS, le prochain échange du client est la négociation TLS.
Lisez le code numérique plutôt que de chercher une formulation anglaise précise. Les proxies peuvent employer des textes différents pour le même statut.
Observer avec curl
Pour un proxy HTTP sur le port local 8080 :
curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/Remplacez l'adresse d'écoute par votre point de terminaison ; si vous cherchez des candidats, parcourez la liste de proxys HTTP et testez l'entrée retenue. La liste d'exclusion vide garantit que cet appel choisit le proxy. Dans l'ordre chronologique, cherchez la connexion au proxy, la réponse CONNECT, la vérification du certificat de destination et la réponse du site. Le libellé exact du journal dépend de la compilation de curl.
La destination peut renvoyer 404, 429 ou 500 après l'acceptation du tunnel par le proxy. Elle peut aussi échouer pendant TLS, avant toute réponse HTTP.
Où l'échange s'est-il arrêté ?
| Observation | Prochaine vérification |
|---|---|
| La connexion au proxy est refusée | Adresse du proxy, port d'écoute, processus et accès réseau. |
| Le proxy renvoie 407 | Le compte du proxy et le mécanisme d'authentification. |
| Le proxy refuse une destination ou un port | Politique d'accès et destinations CONNECT autorisées. |
| Le tunnel s'ouvre, puis la vérification TLS échoue | Nom de destination, magasin de confiance, horloge et éventuelle interception TLS administrée. |
| TLS réussit et le site renvoie une erreur | La réponse du site. |
Pour comparer, gardez un côté inchangé : essayez une autre destination avec le même proxy, ou comparez la même destination par une connexion directe autorisée.
Le tunnel a toujours un opérateur
Le proxy connaît la destination CONNECT et gère le rythme et le volume du trafic. Un TLS de bout en bout classique protège le contenu applicatif du site contre un proxy qui ne termine pas cette session TLS. Un proxy d'interception administré auquel le client fait confiance repose sur un autre modèle de confiance.