Received an unexpected EOF or 0 bytes from the transport stream.

HttpClient l’enveloppe dans « The SSL connection could not be established, see inner exception. » Les journaux des applications .NET Framework présentent couramment la même situation sous la forme « Authentication failed because the remote party has closed the transport stream. »

.NET SslStream / HttpClient — IOException: the peer closed the connection during the TLS handshake

Ce que cela signifie

L’autre côté (ou un équipement intermédiaire) a fermé la connexion TCP alors que SslStream était en plein handshake TLS, sans envoyer d’alerte TLS. .NET n’a rien d’autre à signaler que la fermeture du flux. Le plus souvent, le serveur a refusé le handshake sans rien dire, ou un proxy ou un pare-feu l’a interrompu.

Pourquoi cela se produit

• Le serveur ferme les handshakes qu’il n’accepte pas

  fréquente

  Aucune version de protocole ni suite de chiffrement commune, un nom SNI manquant ou inconnu, ou un serveur qui exige quelque chose que le client n’a pas proposé, le tout avec un serveur qui ferme la connexion au lieu d’envoyer une alerte.

• Un proxy ou un pare-feu interrompt la connexion

  fréquente

  Les réseaux qui imposent un proxy, les pare-feu à filtrage TLS et les clients VPN mettent fin aux connexions bloquées sans rien signaler.

• Applications .NET Framework qui ne proposent que d’anciennes versions de TLS

  occasionnelle

  Les applications qui ciblent .NET Framework 4.5 ou une version antérieure sans les paramètres TLS par défaut du système d’exploitation peuvent ne proposer que TLS 1.0, que les serveurs modernes rejettent.

Comment corriger l’erreur

1. 1.

   Tester le handshake depuis la même machine

   Si openssl s_client est lui aussi coupé, le problème vient du réseau ou du serveur ; s’il réussit, comparez les versions de protocole et le SNI avec le client .NET.

   # Does a plain TLS handshake from the same host work?
   openssl s_client -connect api.example.com:443 -servername api.example.com -brief </dev/null
   openssl s_client -connect api.example.com:443 -servername api.example.com -tls1_2 -brief </dev/null

2. 2.

   Utiliser le proxy requis

   Configurez le proxy sur le gestionnaire HTTP (ou via HTTPS_PROXY sous Linux) lorsque le réseau n’autorise pas les connexions directes.

   // Use the corporate proxy explicitly (HttpClient also honours HTTPS_PROXY / system settings)
   var handler = new SocketsHttpHandler { Proxy = new WebProxy("http://proxy.example.net:3128"), UseProxy = true };
   using var client = new HttpClient(handler);

3. 3.

   .NET Framework : activer TLS 1.2

   Reciblez vers la version 4.7 ou ultérieure pour que le système d’exploitation choisisse le protocole, ou ajoutez TLS 1.2 à ServicePointManager.SecurityProtocol en attendant de pouvoir le faire.

   // .NET Framework 4.x apps compiled for old targets may still offer only TLS 1.0:
   // target 4.7+ (OS defaults) or, as a stop-gap, enable TLS 1.2 explicitly
   System.Net.ServicePointManager.SecurityProtocol |= System.Net.SecurityProtocolType.Tls12;

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