Se connecter avec Microsoft
S'identifier ou créer un compte.
Bonjour,
Sélectionnez un autre compte.
Vous avez plusieurs comptes
Choisissez le compte avec lequel vous voulez vous connecter.

Résumé

Il existe une vulnérabilité de divulgation d'informations au niveau du protocole TLS (Transport Layer Security) et du protocole SSL (Secure Sockets Layer), tel qu'intégrés dans le composant de chiffrement de Microsoft .NET Framework. Un attaquant qui parviendrait à exploiter cette vulnérabilité pourrait déchiffrer le trafic TLS/SSL chiffré.

Pour exploiter la vulnérabilité, un attaquant devrait d'abord insérer des données non chiffrées dans le canal sécurisé cible, puis procéder à une attaque d'interception (MiTM) entre le client visé et le serveur légitime. Cette mise à jour corrige la vulnérabilité en modifiant la façon dont le composant de chiffrement de .NET envoie et reçoit des paquets réseau chiffrés.

Cette vulnérabilité est résolue dans le bulletin de sécurité Microsoft MS16-065. Cette mise à jour modifie la façon dont le composant de chiffrement .NET Framework envoie et reçoit des paquets réseau chiffrés.

Le tableau suivant contient des liens vers l'entrée standard correspondant à chaque vulnérabilité dans la liste Common Vulnerabilities and Exposures (CVE).

Titre de la vulnérabilité

Numéro CVE

Révélée publiquement

Exploitée

Vulnérabilité d'usurpation TLS/SSL

CVE-2016-0149

Oui

Non

Résolution de la vulnérabilité

Le changement intégré dans le bulletin de sécurité Microsoft MS16-065 divise le premier enregistrement TLS après le transfert. Cela fait en sorte que les flux SslStream, WebRequest (HttpWebRequest, FtpWebRequest), SmtpClient et HttpClient (si basé sur HttpWebRequest) reviennent à un seul octet pour la première lecture, immédiatement suivie par les octets restants (n-1) lors de lectures successives. Ce changement de comportement n'a lieu que pour les applications qui utilisent TLS 1.0 + Cipher Block Chaining, sauf lorsqu'elles utilisent TLS 1.1 ou TLS 1.2.

Remarque Comme prérequis, vous devez installer Le bulletin de sécurité Microsoft MS12-006 pour activer cette mise à jour.

Cette modification peut entraîner l'arrêt de certaines applications basées sur .NET Framework. Cet article décrit deux approches pour la mise à jour de votre application afin que celle-ci fonctionne correctement après application du bulletin de sécurité Microsoft MS16-065.

Résolution des problèmes de compatibilité

Option 1 : Passage au protocole TLS 1.2

Cette option permet à l'application d'utiliser le protocole TLS 1.2 en modifiant le Registre ou en configurant par programme la version du protocole.

  • Modification du Registre

    Important
    Suivez attentivement les étapes de cette section. Des problèmes graves peuvent se produire si vous modifiez le Registre de façon incorrecte. Avant de modifier celui-ci, sauvegardez le Registre pour une restauration en cas de problèmes.

    Les applications .NET Framework 4.0 et .NET Framework 4.5.x qui fonctionnent sur NET Framework 4.5 et des versions ultérieures peuvent passer du protocole par défaut vers TLS 1.2, TLS 1.1 et TLS 1.0 en activant la clé de Registre SchUseStrongCrypto. Cette clé de Registre est abordée dans la section Actions suggérées de la rubrique Avis de sécurité Microsoft 2960358 sur le site web de Microsoft TechNet.

    Important Cette modification du Registre ne fonctionnera que si les conditions suivantes sont remplies :

    • Les applications qui utilisent des API basées sur ServicePointManager ne définissent pas explicitement la valeur ServicePointManager.SecurityProtocol. Parmi les exemples de telles classes figurent System.Net.Http.HttpClient, System.Net.FtpWebRequest, System.Net.HttpWebRequest et System.Net.Mail.SmtpClient. La définition du ServicePointManager.SecurityProtocol dans le code a la priorité sur le Registre.

    • Les applications utilisent la surcharge SslStream AuthenticateAsClient(String).


  • Configurez la version du protocole par programme

    Les applications .NET Framework 4.0 et 4.5 exécutées sur .NET Framework 4.5 et des versions ultérieures et qui utilisent la surcharge SslStream AuthenticateAsClient(String, X509CertificateCollection, SslProtocols, Boolean) doivent être recompilées, en spécifiant SslProtocols.Tls12, SslProtocols.Tls11 et SslProtocols.Tls comme troisième paramètre. Pour obtenir une description complète de l'utilisation de la classe SslStream, reportez-vous à la rubrique SslStream Class sur le site web des développeurs Microsoft (MSDN).

    Remarque NET Framework 4.6 et les versions ultérieures utilisent TLS 1.2, TLS 1.1 et TLS 1.0 comme des protocoles par défaut. Cette question est abordée dans l'avis de sécurité Microsoft 2960358 sur le site web Microsoft TechNet.


Option 2 : Traitement des paquets fractionnés

Cette mise à jour fait en sorte qu'un seul enregistrement est divisé en plusieurs. Toutefois, si une application s'attend à ce que l'enregistrement complet soit disponible dans un seul appel Read, de telles applications peuvent s'interrompre. Pour vous assurer que l'application se comporte correctement, vérifiez que l'application traite des paquets fractionnés en effectuant correctement l'appel Stream.Read. Vous pouvez utiliser l'exemple de code disponible ici comme référence pour déterminer comment corriger l'application afin d'effectuer correctement l'appel Read.

Pour obtenir un exemple de requête HTTP qui affiche la différence de comportement avant (avec résolution) et après (sans résolution) les mises à jour 3147461 et 3147458 ont été installées, consultez la section « Plus d'informations ».

Pour obtenir un exemple complet de la méthode Stream.Read, consultez la rubrique Stream.Read Method (Byte[], Int32, Int32) sur le site web pour développeurs Microsoft (MSDN).

Solutions de contournement des problèmes de compatibilité de l'application

Avertissement Ces solutions de contournement peuvent rendre un ordinateur ou un réseau plus vulnérable aux attaques d'utilisateurs malintentionnés ou de logiciels nuisibles tels que des virus. Ces solutions de contournement ne sont pas recommandées ; nous vous indiquons toutefois la marche à suivre si vous souhaitez les appliquer. Vous assumez l'ensemble des risques liés à ces solutions de contournement.

Méthode 1 : Mettre à jour les clés de Registre (disponible pour toutes les versions de .NET Framework)

Désactiver la structure SCH_SEND_AUX_RECORD (globalement)

Désactiver la structure SCH_SEND_AUX_RECORD pour des applications individuelles

Désactiver la structure SCH_SEND_AUX_RECORD (globalement)

Pour toutes les applications, ajoutez la sous-clé de Registre suivante :

Emplacement du Registre :HKEY_LOCAL_MACHINE\Software\Microsoft\.NETFramework\<version_number>
Nom DWORD : SchSendAuxRecord
Données de la valeur : 0
Remarque L'espace réservé <version_number> est soit v4.0.30319 ou v2.0.50727, selon la version.

Pour les applications 32 bits exécutées sur des ordinateurs 64 bits, vous devez également ajouter la sous-clé de Registre suivante :

Emplacement du Registre :HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\.NETFramework\<version_number>
Nom DWORD : SchSendAuxRecord
Données de la valeur : 0
Remarque L'espace réservé <version_number> est soit v4.0.30319 ou v2.0.50727, selon la version.

Solution de contournement

Pour désactiver temporairement le mode sécurisé décrit dans cet article, cliquez sur le lien approprié pour télécharger un fichier .reg, puis double-cliquez sur le fichier .reg téléchargé pour apporter les modifications au Registre.

Pour les applications ciblant Microsoft .NET Framework 3.5 :

Téléchargez maintenant ManualOptOutSchSendAuxRecord20.reg.
Pour les applications ciblant Microsoft .NET Framework 4.0 et des versions ultérieures :

Téléchargez maintenant le fichier ManualOptOutSchSendAuxRecord40.reg
Pour réactiver le mode sécurisé décrit dans cet article, cliquez sur le lien approprié pour télécharger un fichier .reg, puis double-cliquez sur le fichier .reg téléchargé pour apporter les modifications au Registre.

Pour les applications ciblant Microsoft .NET Framework 3.5 :

Téléchargez maintenant le fichier ManualOptInSchSendAuxRecord20.reg.
Pour les applications ciblant Microsoft .NET Framework 4.0 et des versions ultérieures :

Téléchargez maintenant le fichier ManualOptInSchSendAuxRecord40.reg.
Pour plus d'informations sur la procédure de téléchargement des fichiers du support technique Microsoft, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :

119591 Comment faire pour obtenir des fichiers de support technique Microsoft auprès des services en ligneMicrosoft a analysé ce fichier en vue de détecter la présence de virus. Microsoft a utilisé les logiciels de détection de virus les plus récents disponibles à la date de publication de ce fichier. Le fichier est conservé sur des serveurs sécurisés, ce qui empêche toute modification non autorisée du fichier.


Désactivez la structure SCH_SEND_AUX_RECORD pour les applications individuelles

Pour toutes les applications, ajoutez la sous-clé de Registre suivante :

Emplacement du Registre :HKEY_LOCAL_MACHINE\Software\Microsoft\.NETFramework\<version_number>\System.Net.ServicePointManager.SchSendAuxRecord
Nom DWORD : Chemin pleinement qualifié pour l'application .exe (par exemple, C:\MyApp\MyApp.exe)
Données de la valeur : 0
Remarque L'espace réservé <version_number> est soit v4.0.30319 ou v2.0.50727, selon la version.

Pour les applications 32 bits exécutées sur des ordinateurs 64 bits, vous devez également ajouter la sous-clé de Registre suivante :

Emplacement du Registre :HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\.NETFramework\<version_number>\System.Net.ServicePointManager.SchSendAuxRecord
Nom DWORD : Chemin pleinement qualifié pour l'application .exe (par exemple, C:\MyApp\MyApp.exe)
Données de la valeur : 0 (La seule valeur valide est 0. Toute autre valeur sera ignorée.)
Remarque L'espace réservé <version_number> est soit v4.0.30319 ou v2.0.50727, selon la version.

Méthode 2 : Modifier la configuration au niveau de l'application (disponible uniquement pour .NET Framework version 4.6 ou des versions ultérieures)

À partir de .NET Framework 4.6, vous pouvez modifier la configuration au niveau de l'application via la configuration du code ou de l'application ainsi que par l'intermédiaire de modifications au niveau du Registre.

Dans .NET Framework 4.6, vous pouvez effectuer la transition en utilisant l'une des méthodes suivantes. Ces exemples désactivent la fonctionnalité de sécurité.

  • Par programme

    En premier lieu, l'application doit exécuter le code suivant. En effet, le gestionnaire de points de service ne s'initialisera qu'une seule fois.

    chaîne constante privée DisableCachingName = @"TestSwitch.LocalAppContext.DisableCaching"; 
    chaîne constante privée DontEnableSchSendAuxRecordName = @"Switch.System.Net.DontEnableSchSendAuxRecord";
    AppContext.SetSwitch(DisableCachingName, true);
    AppContext.SetSwitch(DontEnableSchSendAuxRecordName , true);
  • Configuration de l'application

    Pour modifier la configuration de l'application, ajoutez l'entrée suivante :

    <runtime>
    <AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchSendAuxRecord=true"/>
    </runtime>
  • Clé de Registre (à l'échelle de l'ordinateur)

    Emplacements du Registre :HKEY_LOCAL_MACHINE\Software\Microsoft\.NETFramework\AppContextHKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\AppContext
    Valeur : Switch.System.Net.DontEnableSchSendAuxRecord
    Type : Chaîne
    Valeur : True

    Remarque Switch.System.Net.DontEnableSchSendAuxRecord = False pour toutes les applications.

Plus d'informations

Vous trouverez ci-après un exemple de modèle de communication Client/Serveur avant et après l'installation de cette mise à jour. Ces informations sont fournies à des fins d'illustration pour identifier n'importe quel arrêt d'application découlant de l'installation de ce correctif.

Sans résolution

Avec résolution

[Serveur] en attente de connexions (127.0.0.1:4431)
[Client] Connexion à localhost:4431
[Serveur] Client connecté.
[Client] Connecté. Authentification...
[Serveur] Client authentifié.
[Client] Envoi de la demande (94 octets)
[Client] En attente de réponse...

[Serveur] 94 octets reçus : <<<GET / HTTP/1.0
Hôte : contoso.com
Agent utilisateur : Application de test

>>>
[Serveur] Répondu avec 476 octets.

[Client 1 : 476 octets] Réponse : <<<<<HTTP/1.1 200 OK

>>>>>

[Serveur] en attente de connexions (127.0.0.1:4431)
[Client] Connexion à localhost:4431
[Serveur] Client connecté.
[Client] Connecté. Authentification...
[Serveur] Client authentifié.
[Client] Envoi de la demande (94 octets)
[Client] En attente de réponse...
[Serveur] 1 octet reçu : <<<G>>>
[Serveur] 93 octets reçus : <<<ET / HTTP/1.0
Hôte : contoso.com
Agent utilisateur : Application de test

>>>
[Serveur] Répondu avec 476 octets.
[Client 1 : 1 octet] Réponse : <<<<<H>>>>>
[Client 2 : 475 octets] Réponse : <<<<<TTP/1.1 200 OK

>>>>>


Besoin d’aide ?

Vous voulez plus d’options ?

Explorez les avantages de l’abonnement, parcourez les cours de formation, découvrez comment sécuriser votre appareil, etc.

Les communautés vous permettent de poser des questions et d'y répondre, de donner vos commentaires et de bénéficier de l'avis d'experts aux connaissances approfondies.

Ces informations vous ont-elles été utiles ?

Dans quelle mesure êtes-vous satisfait(e) de la qualité de la langue ?
Qu’est-ce qui a affecté votre expérience ?
En cliquant sur Envoyer, vos commentaires seront utilisés pour améliorer les produits et services de Microsoft. Votre administrateur informatique sera en mesure de collecter ces données. Déclaration de confidentialité.

Nous vous remercions de vos commentaires.

×