Un salto de línea extra puede romper TLS después de CONNECT
Inspeccione el encuadre de las cabeceras HTTP cuando un conector proxy escrito a mano abre un túnel y produce de inmediato un error de decodificación TLS.
Cuando CONNECT devuelve 200 y TLS falla de inmediato al decodificar, inspeccione los bytes de frontera del conector antes de cambiar certificados o cifrados.
Un valor de autorización generado puede terminar ya en un salto de línea. Añadir otro final de línea puede terminar las cabeceras HTTP antes de tiempo y dejar un campo Host previsto u otro texto plano detrás de la petición.
Una petición HTTP/1.1 CONNECT mínima usa CRLF entre líneas y una línea vacía al final:
b"CONNECT example.com:443 HTTP/1.1\r\nHost: example.com:443\r\n\r\n"Coloque cualquier campo de autorización antes de esa línea vacía final, sin salto de línea incrustado. En Python, "\n" representa un salto de línea; una cadena cruda con una barra invertida y la letra n no. Compruebe qué bytes produce un auxiliar de codificación antes de intentar eliminarlos—los auxiliares antiguos podían añadir saltos de línea.
Una vez que CONNECT tiene éxito, esos bytes restantes pertenecen al protocolo del túnel. Un texto plano extraviado puede llegar a un par que espera TLS. El estado exitoso no puede reparar bytes ya encolados tras una petición mal formada.
Inspeccione también la frontera de recepción. Lea la respuesta completa del proxy antes de entregar el socket a TLS, gestione lecturas parciales y conserve todo lo leído más allá de las cabeceras. Una lectura de socket no tiene por qué contener un mensaje entero.
Si este analizador es suyo, compare una representación redactada de los bytes con la gramática del cable; mantenga visibles las longitudes y los límites de línea mientras oculta la contraseña. Para una aplicación que solo necesita una conexión proxy, un conector mantenido evita tener que poseer este código de encuadre.