O erro di “versión incorrecta”, así que é tentador comezar a cambiar versións de TLS. Cun proxy, comproba unha posibilidade anterior: enviou o cliente un handshake TLS a un porto que agardaba HTTP simple?

Un destino como https://example.com/ e un proxy como http://proxy.example:8080 son unha parella habitual. Cambiar a segunda URL a HTTPS dille ao cliente que cifre a súa conversa co propio proxy. Non é unha instrución para permitir sitios HTTPS.

Localiza a primeira conversa TLS

Cun proxy HTTP, o cliente pode enviar primeiro CONNECT e recibir unha resposta HTTP. Só despois inicia o TLS do destino dentro do túnel. Cun proxy HTTPS, primeiro chega unha conexión TLS separada ao proxy.

Un analizador TLS que recibe unha páxina de erro HTTP ou outro texto simple pode informar dun erro de protocolo. A redacción non establece que versións de TLS admite o sitio, nin sequera que se contactase co sitio.

  1. Anota a URL do proxy, incluído o seu esquema, e o protocolo documentado do extremo.
  2. Averigua se o fallo ocorreu antes dunha resposta CONNECT, durante o TLS do destino ou ao verificar o certificado do propio proxy.
  3. Comproba as versións reais do cliente e das dependencias ao comparar unha solución antiga. Implementacións anteriores de proxy ás veces trataban un esquema de forma distinta.

Varias correccións poden ser erróneas por motivos diferentes. A lista de proxies HTTP ofrece candidatos habituais de extremo HTTP para peticións públicas permitidas por esa ruta. Un extremo HTTP simple necesita o esquema de proxy HTTP; un extremo realmente habilitado para TLS debería conservar HTTPS e a verificación do seu certificado. Un proxy que rexeita CONNECT necesita un servizo ou unha política admitidos, non unha rebaixa arbitraria da biblioteca.

Queda co primeiro fallo observable. Desactivar a verificación de certificados non pode facer que un receptor só HTTP fale TLS, e escoller unha política de cifrado antiga non pode explicar un rexeitamento HTTP enviado antes do handshake do sitio.

Artigos relacionados