[SSL: UNEXPECTED_EOF_WHILE_READING] EOF occurred in violation of protocol

Avec OpenSSL 3, Python affiche le code de raison « [SSL: UNEXPECTED_EOF_WHILE_READING] » ; avec OpenSSL 1.1.1, le texte est simplement « EOF occurred in violation of protocol ». Un emplacement dans le code source, comme « (_ssl.c:1082) », suit le message.

Python ssl module (OpenSSL) — ssl.SSLEOFError, SSL_R_UNEXPECTED_EOF_WHILE_READING

Ce que cela signifie

L’autre côté a fermé la connexion TCP alors que Python était encore dans le handshake TLS (ou en pleine lecture de données), sans envoyer d’alerte TLS ni close_notify. OpenSSL traite cette fermeture silencieuse comme une violation du protocole. Python ne peut pas savoir pourquoi le pair est parti ; la raison se trouve du côté du serveur, d’un proxy ou d’un pare-feu situé entre les deux.

Pourquoi cela se produit

• Le serveur abandonne les handshakes qui ne lui conviennent pas

  fréquente

  Certains serveurs et répartiteurs de charge ferment la connexion au lieu d’envoyer une alerte lorsque le ClientHello ne contient pas de SNI ou ne propose aucune version ni aucun algorithme de chiffrement acceptable, ou lorsque le nom n’est pas configuré.

• Un proxy, un pare-feu ou un VPN coupe la connexion

  fréquente

  Des paramètres de proxy erronés (HTTPS_PROXY qui pointe vers un port de proxy TLS, NO_PROXY absent pour les hôtes internes), une inspection approfondie des paquets qui bloque la destination ou des clients VPN mettent souvent fin à la connexion TCP sans rien signaler.

• Limitation de débit ou protection contre les bots

  occasionnelle

  Les API et les CDN sous forte charge, ou les systèmes anti-bots qui n’apprécient pas l’empreinte TLS de Python, peuvent réinitialiser les connexions au lieu de renvoyer une erreur HTTP.

• Le serveur a fermé la connexion en pleine réponse

  occasionnelle

  Lorsque l’erreur survient pendant la lecture d’une réponse, le serveur ou un proxy a mis fin à la connexion sans close_notify, par exemple après l’expiration d’un délai ou le plantage d’un worker.

Comment corriger l’erreur

1. 1.

   Reproduire le handshake avec openssl s_client

   Si s_client est lui aussi déconnecté, faites varier le SNI et la version de TLS pour voir ce que le serveur refuse ; si s_client fonctionne, comparez ses paramètres avec ceux de votre client Python (proxy, SNI, versions).

   # Does a plain OpenSSL handshake work from the same machine?
   openssl s_client -connect api.example.com:443 -servername api.example.com -brief </dev/null
   # Without SNI, and pinned to TLS 1.2, to see what the server objects to
   openssl s_client -connect api.example.com:443 -noservername -brief </dev/null
   openssl s_client -connect api.example.com:443 -servername api.example.com -tls1_2 -brief </dev/null

2. 2.

   Vérifier les variables d’environnement de proxy

   requests, urllib et pip tiennent compte de HTTPS_PROXY et de NO_PROXY. Corrigez le schéma de l’URL du proxy et excluez les hôtes internes qui doivent être joints directement.

   env | grep -i -E '^(https?|no|all)_proxy='
   # Proxy URLs should normally be http:// (CONNECT tunnel), and internal hosts listed in NO_PROXY
   export HTTPS_PROXY=http://proxy.example.net:3128
   export NO_PROXY=localhost,127.0.0.1,.internal.example.com

3. 3.

   Réessayer quand la cause est passagère

   En cas de limitation de débit ou de réseau instable, de nouvelles tentatives espacées par des délais croissants transforment des réinitialisations sporadiques en réussites, simplement plus lentes ; elles ne corrigent pas un serveur qui refuse systématiquement le handshake.

   import requests
   from requests.adapters import HTTPAdapter
   from urllib3.util.retry import Retry
   
   session = requests.Session()
   session.mount("https://", HTTPAdapter(max_retries=Retry(total=3, backoff_factor=1)))
   session.get("https://api.example.com/")

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