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

Les versions récentes de curl (ici 8.14.1) placent « TLS connect error: » devant la raison donnée par OpenSSL ; curl 7.x affichait la raison seule. Les builds liés à OpenSSL 1.1.1 affichent la forme longue « error:1408F10B:SSL routines:ssl3_get_record:wrong version number » ; OpenSSL 3.x affiche « error:0A00010B:SSL routines::wrong version number ».

curl (OpenSSL backend) — CURLE_SSL_CONNECT_ERROR, SSL_R_WRONG_VERSION_NUMBER

Ce que cela signifie

curl a envoyé un ClientHello TLS, et les premiers octets reçus en retour n’étaient pas un enregistrement TLS. OpenSSL lit dans cette réponse le champ de version de l’en-tête d’enregistrement et n’y trouve que des valeurs absurdes, généralement les lettres de « HTTP/1.1 400 » envoyées par un serveur HTTP en clair. Malgré le libellé, il ne s’agit presque jamais de versions de TLS : l’autre côté ne parle pas TLS sur ce port.

Pourquoi cela se produit

• https:// vers un port qui sert du HTTP en clair

  fréquente

  Les serveurs de développement sur le port 8080 ou 3000, un backend derrière un répartiteur de charge ou une directive listen mal configurée répondent en HTTP. Inverser http et https dans l’URL, ou utiliser le numéro du port TLS avec http://, est l’origine la plus fréquente de ce message.

• L’URL du proxy indique https://, mais le proxy parle HTTP

  fréquente

  HTTPS_PROXY=https://proxy:3128 amène curl à établir TLS avec le proxy lui-même. La plupart des proxys sortants attendent du HTTP en clair de la part du client et ouvrent un tunnel CONNECT chiffré vers la destination : l’URL du proxy devrait donc commencer par http://, même pour du trafic HTTPS.

• TLS implicite face à un port STARTTLS

  occasionnelle

  SMTP sur 25/587, IMAP sur 143, POP3 sur 110, LDAP sur 389 et PostgreSQL/MySQL commencent l’échange en clair et passent à TLS ensuite. Y démarrer directement par un handshake TLS échoue immédiatement.

• Un portail captif ou un filtre répond à la place du serveur

  occasionnelle

  Le Wi-Fi des hôtels et des aéroports, les filtres parentaux et certains pare-feu interceptent le port 443 et répondent par une page de redirection HTTP avant tout échange TLS.

Comment corriger l’erreur

1. 1.

   Vérifier le protocole que parle réellement le port

   Envoyez une requête au même port en http://. Si vous obtenez une réponse HTTP, utilisez soit http://, soit le vrai port TLS ; openssl s_client confirme quels ports mènent à bien un 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.

   Utiliser http:// dans l’URL du proxy

   Sauf si votre proxy prend explicitement en charge une connexion TLS jusqu’à lui, écrivez l’adresse du proxy sous la forme http://host:port. La connexion vers la destination reste chiffrée en TLS de bout en bout, à travers le tunnel 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.

   Utiliser STARTTLS sur les ports STARTTLS

   Pour les protocoles de messagerie, curl passe à TLS avec --ssl-reqd sur les ports de soumission et IMAP, ou utilise TLS implicite sur 465 et 993 avec les schémas smtps:// et 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.

   Propriétaires de serveurs : activer TLS sur l’écouteur

   Si les clients sont censés utiliser https:// sur ce port, il faut activer TLS sur l’écouteur et y configurer un certificat ; sinon, publiez le bon port.

   # 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;
   }

← Parcourir toute la base de données des erreurs de signature