O erro diz “versão errada”, por isso é tentador começar a trocar versões de TLS. Com um proxy, verifique uma possibilidade anterior: o cliente enviou um handshake TLS para uma porta que esperava HTTP simples?

Um destino como https://example.com/ e um proxy como http://proxy.example:8080 são um par comum. Mudar a segunda URL para HTTPS diz ao cliente para criptografar sua conversa com o próprio proxy. Não é uma instrução para permitir sites HTTPS.

Localize a primeira conversa TLS

Com um proxy HTTP, o cliente pode primeiro enviar CONNECT e receber uma resposta HTTP. Só depois inicia o TLS do destino dentro do túnel. Com um proxy HTTPS, primeiro vem uma conexão TLS separada com o proxy.

Um analisador TLS que recebe uma página de erro HTTP ou outro texto simples pode relatar um erro de protocolo. A redação não estabelece quais versões de TLS o site suporta, nem sequer que o site tenha sido contatado.

  1. Anote a URL do proxy, incluindo o esquema, e o protocolo documentado do endpoint.
  2. Descubra se a falha ocorreu antes de uma resposta CONNECT, durante o TLS do destino ou ao verificar o certificado do próprio proxy.
  3. Verifique as versões reais do cliente e das dependências ao comparar uma solução antiga. Implementações anteriores de proxy às vezes tratavam um esquema de forma diferente.

Várias correções podem estar erradas por motivos diferentes. A lista de proxies HTTP oferece candidatos comuns de endpoint HTTP para solicitações públicas permitidas por essa rota. Um endpoint HTTP simples precisa do esquema de proxy HTTP; um endpoint realmente habilitado para TLS deve manter HTTPS e a verificação do certificado. Um proxy que rejeita CONNECT precisa de um serviço ou política suportados, não de um rebaixamento arbitrário da biblioteca.

Mantenha a primeira falha observável. Desativar a verificação de certificados não faz um receptor que só fala HTTP falar TLS, e escolher uma política de cifra antiga não explica uma rejeição HTTP enviada antes do handshake do site.

Artigos relacionados