Un salto de liña extra pode romper TLS despois de CONNECT
Inspeccione o enmarcado das cabeceiras HTTP cando un conector proxy escrito a man abre un túnel e produce de inmediato un erro de decodificación TLS.
Cando CONNECT devolve 200 e TLS falla de inmediato ao decodificar, inspeccione os bytes de fronteira no conector antes de cambiar certificados ou cifrados.
Un valor de autorización xerado pode rematar xa nun salto de liña. Engadir outro final de liña pode rematar as cabeceiras HTTP demasiado pronto, deixando un campo Host previsto ou outro texto plano detrás da petición.
Unha petición HTTP/1.1 CONNECT mínima usa CRLF entre liñas e unha liña baleira ao final:
b"CONNECT example.com:443 HTTP/1.1\r\nHost: example.com:443\r\n\r\n"Pon calquera campo de autorización antes desa liña baleira final, sen salto de liña incrustado. En Python, "\n" representa un salto de liña; unha cadea bruta cunha barra invertida e a letra n non. Comproba que bytes produce un axudante de codificación antes de tentar eliminalos—os axudantes antigos podían engadir saltos de liña.
Unha vez que CONNECT ten éxito, eses bytes restantes pertencen ao protocolo do túnel. Un texto plano extraviado pode chegar a un par que espera TLS. O estado exitoso non pode reparar bytes xa encolados tras unha petición mal formada.
Inspeccione tamén a fronteira de recepción. Lea a resposta completa do proxy antes de entregar o socket a TLS, xestione lecturas parciais e conserve todo o lido máis alá das cabeceiras. Unha lectura de socket non ten por que conter unha mensaxe enteira.
Se este analizador é seu, compare unha representación redactada dos bytes coa gramática do cable; manteña visibles as lonxitudes e os límites de liña mentres oculta o contrasinal. Para unha aplicación que só necesita unha conexión proxy, un conector mantido evita ter que posuír este código de enmarcado.