curl: (35) TLS connect error: error:0A00010B:SSL routines::wrong version number

Versões recentes do curl (aqui, 8.14.1) colocam “TLS connect error: ” antes do motivo informado pelo OpenSSL; o curl 7.x imprimia só o motivo. Builds do OpenSSL 1.1.1 imprimem a forma longa “error:1408F10B:SSL routines:ssl3_get_record:wrong version number”; o OpenSSL 3.x imprime “error:0A00010B:SSL routines::wrong version number”.

curl (OpenSSL backend) — CURLE_SSL_CONNECT_ERROR, SSL_R_WRONG_VERSION_NUMBER

O que significa

O curl enviou um ClientHello TLS, e os primeiros bytes que voltaram não eram um registro TLS. O OpenSSL lê o campo de versão do cabeçalho do registro nessa resposta e encontra lixo, normalmente as letras de “HTTP/1.1 400” vindas de um servidor HTTP não criptografado. Apesar da mensagem, quase nunca se trata de versões de TLS: o outro lado não está falando TLS nessa porta.

Por que acontece

• https:// em uma porta que serve HTTP não criptografado

  comum

  Servidores de desenvolvimento nas portas 8080 ou 3000, um backend atrás de um balanceador de carga ou uma diretiva listen mal configurada respondem com HTTP. Inverter http e https na URL, ou usar o número da porta TLS com http://, é a origem mais comum dessa mensagem.

• A URL do proxy diz https://, mas o proxy fala HTTP

  comum

  HTTPS_PROXY=https://proxy:3128 faz o curl iniciar TLS com o próprio proxy. A maioria dos proxies de encaminhamento espera HTTP não criptografado do cliente e abre um túnel CONNECT criptografado até o destino, por isso a URL do proxy deve começar com http:// mesmo para tráfego HTTPS.

• TLS implícito em uma porta STARTTLS

  ocasional

  SMTP nas portas 25/587, IMAP na 143, POP3 na 110, LDAP na 389 e PostgreSQL/MySQL enviam a saudação em texto claro e só depois passam para TLS. Começar com um handshake TLS nessas portas falha imediatamente.

• Um portal cativo ou filtro responde no lugar do servidor

  ocasional

  Wi-Fi de hotéis e aeroportos, filtros de controle parental e alguns firewalls interceptam a porta 443 e respondem com uma página de redirecionamento HTTP antes de qualquer TLS acontecer.

Como corrigir

1. 1.

   Verificar qual protocolo a porta realmente usa

   Faça uma requisição para a mesma porta com http://. Se receber uma resposta HTTP, use http:// ou a porta TLS real; o openssl s_client confirma quais portas completam um handshake TLS.

   # What does the port speak? An HTTP status line means plain HTTP.
   curl -sS -i http://api.example.com:8080/ | head -1        # HTTP/1.1 200 OK  -> not TLS
   openssl s_client -connect api.example.com:8443 -brief </dev/null   # handshake summary -> TLS

2. 2.

   Usar http:// na URL do proxy

   A menos que seu proxy ofereça suporte explícito a TLS até o proxy, escreva o proxy como http://host:port. A conexão com o destino continua sendo TLS de ponta a ponta pelo túnel CONNECT.

   # Most corporate proxies accept plain HTTP from the client and tunnel HTTPS with CONNECT
   export HTTPS_PROXY=http://proxy.example.net:3128     # http:// even for HTTPS traffic
   curl -x http://proxy.example.net:3128 https://api.example.com/

3. 3.

   Usar STARTTLS em portas STARTTLS

   Para protocolos de e-mail, o curl passa para TLS com --ssl-reqd nas portas de submissão e IMAP, ou usa TLS implícito nas portas 465 e 993 com os esquemas smtps:// e imaps://.

   # Port 587/25 (SMTP) and 143 (IMAP) start in plain text and upgrade with STARTTLS
   curl --ssl-reqd smtp://mail.example.com:587 -v
   # Implicit TLS lives on 465 (SMTPS) and 993 (IMAPS)
   curl smtps://mail.example.com:465 -v

4. 4.

   Donos do servidor: ativar TLS no listener

   Se os clientes devem usar https:// nessa porta, o listener precisa estar com TLS ativado e um certificado configurado; caso contrário, informe a porta correta.

   # nginx: the port that clients reach with https:// needs the ssl flag
   server {
       listen 443 ssl;
       ssl_certificate     /etc/nginx/tls/fullchain.pem;
       ssl_certificate_key /etc/nginx/tls/privkey.pem;
   }

← Ver toda a base de erros de assinatura