Uma linha nova extra pode quebrar o TLS após o CONNECT
Inspecione o enquadramento dos cabeçalhos HTTP quando um conector de proxy escrito à mão abre um túnel e produz imediatamente um erro de decodificação TLS.
Quando o CONNECT retorna 200 e o TLS falha imediatamente ao decodificar, inspecione os bytes de fronteira no conector antes de trocar certificados ou cifras.
Um valor de autorização gerado pode já terminar com uma nova linha. Acrescentar outro fim de linha pode terminar os cabeçalhos HTTP cedo demais, deixando um campo Host pretendido ou outro texto simples atrás da requisição.
Uma requisição HTTP/1.1 CONNECT mínima usa CRLF entre as linhas e uma linha vazia no final:
b"CONNECT example.com:443 HTTP/1.1\r\nHost: example.com:443\r\n\r\n"Coloque qualquer campo de autorização antes dessa linha vazia final, sem quebra de linha embutida. Em Python, "\n" representa uma nova linha; uma string bruta contendo uma barra invertida e a letra n não. Verifique quais bytes um auxiliar de codificação produz antes de tentar removê-los—auxiliares antigos podiam adicionar quebras de linha.
Depois que o CONNECT é bem-sucedido, esses bytes restantes pertencem ao protocolo do túnel. Texto simples extraviado pode chegar a um par que espera TLS. O status de sucesso não pode reparar bytes já enfileirados após uma requisição malformada.
Inspecione também a fronteira de recebimento. Leia a resposta completa do proxy antes de entregar o socket ao TLS, trate leituras parciais e preserve tudo o que for lido além dos cabeçalhos. Uma leitura de socket não precisa conter uma mensagem inteira.
Se este analisador é seu, compare uma representação redigida dos bytes com a gramática do fio; mantenha comprimentos e fronteiras de linha visíveis enquanto oculta a senha. Para uma aplicação que só precisa de uma conexão proxy, um conector mantido evita ter de possuir este código de enquadramento.