Un saut de ligne supplémentaire peut casser TLS après CONNECT
Examinez le cadrage des en-têtes HTTP lorsqu'un connecteur proxy écrit à la main ouvre un tunnel et produit immédiatement une erreur de décodage TLS.
Lorsque CONNECT renvoie 200 et que TLS échoue aussitôt à décoder, examinez les octets de frontière dans le connecteur avant de changer de certificats ou de chiffrements.
Une valeur d'autorisation générée peut déjà se terminer par un saut de ligne. Ajouter une autre fin de ligne peut terminer les en-têtes HTTP trop tôt, laissant un champ Host prévu ou d'autre texte en clair derrière la requête.
Une requête HTTP/1.1 CONNECT minimale utilise CRLF entre les lignes et une ligne vide à la fin :
b"CONNECT example.com:443 HTTP/1.1\r\nHost: example.com:443\r\n\r\n"Placez tout champ d'autorisation avant cette dernière ligne vide, sans saut de ligne incorporé. En Python, "\n" représente un saut de ligne ; une chaîne brute contenant une barre oblique inverse et la lettre n non. Vérifiez quels octets un assistant d'encodage produit avant d'essayer de les supprimer—les anciens assistants pouvaient ajouter des sauts de ligne.
Une fois CONNECT réussi, ces octets restants appartiennent au protocole tunnelisé. Un texte en clair égaré peut atteindre un pair qui attend TLS. Le statut de succès ne peut pas réparer des octets déjà mis en file après une requête mal formée.
Examinez aussi la frontière de réception. Lisez la réponse complète du proxy avant de remettre la socket à TLS, gérez les lectures partielles et conservez tout ce qui est lu au-delà des en-têtes. Une lecture de socket ne doit pas nécessairement contenir un message entier.
Si ce parseur est le vôtre, comparez une représentation d'octets expurgée avec la grammaire du fil ; gardez les longueurs et les frontières de ligne visibles tout en masquant le mot de passe. Pour une application qui n'a besoin que d'une connexion proxy, un connecteur maintenu évite de posséder ce code de cadrage.