Bonnes pratiques du protocole TLS (Transport Layer Security) avec le .NET Framework

Article
04/15/2024

Remarque

Cette page contient des informations TLS .NET Framework. Si vous recherchez des informations TLS .NET, consultez : Meilleures pratiques TLS/SSL

.NET Framework prend en charge l’utilisation du protocole TLS (Transport Layer Security) pour sécuriser les communications réseau.

Qu’est-ce que le protocole TLS (Transport Layer Security) ?

Avertissement

Les protocoles TLS 1.0 et 1.1 ont été déconseillés par RFC8996. Ce document couvre uniquement TLS 1.2 et TLS 1.3.

Le protocole TLS (Transport Layer Security) est la version la plus récente d’une norme conçue pour aider à protéger la confidentialité des informations communiquées sur Internet. TLS 1.3 est une norme qui fournit des améliorations de sécurité par rapport aux versions précédentes. Cet article présente les recommandations visant à sécuriser les applications .NET Framework qui utilisent le protocole TLS.

Qui peut profiter de ce document ?

utilisent directement les System.Net API (par exemple, System.Net.Http.HttpClient et System.Net.Security.SslStream).
utilisent directement des clients et des services WCF à l’aide de l’espace de noms System.ServiceModel.

Prise en charge de TLS dans .NET Framework

Étant donné que .NET Framework dépend de Schannel sur Windows, les versions pouvant être négociées et la version utilisée dépendra du système d’exploitation.

Voici un exemple de tableau à jour montrant la version TLS la plus élevée prise en charge pour différentes combinaisons de versions du système d’exploitation et de versions cibles .NET Framework :

Version cible de .NET Framework	Windows 10	Windows 11
3,5	TLS 1.2	TLS 1.2
4.6.2	TLS 1.2	TLS 1.3
4.7	TLS 1.2	TLS 1.3
4.7.1	TLS 1.2	TLS 1.3
4.7.2	TLS 1.2	TLS 1.3
4.8	TLS 1.2	TLS 1.3
4.8.1	TLS 1.2	TLS 1.3

Pour plus d’informations, consultez Prise en charge de la version du protocole TLS dans Schannel.

Recommandations

Pour TLS 1.3, ciblez .NET Framework 4.8 ou ultérieur. Consultez la section Auditer votre code pour savoir comment vérifier votre target framework.
Ne spécifiez pas la version TLS explicitement, par exemple n’utilisez pas les surcharges de méthode de SslStream qui accepte un paramètre SslProtocols explicite.
- Ainsi, votre code laisse le système d’exploitation décider de la version TLS.
- Si vous devez définir ServicePointManager.SecurityProtocol, définissez-le sur SecurityProtocolType.SystemDefault. Cela permet également d’utiliser la valeur par défaut du système d’exploitation.
- Si vous devez utiliser les surcharges de méthode de SslStream qui prennent un paramètre SslProtocols explicite, passez SslProtocols.SystemDefault comme argument. Cela permet également d’utiliser la valeur par défaut du système d’exploitation.
Effectuez un audit complet du code pour vérifier que vous n’indiquez pas explicitement une version SSL ou TLS.

Avertissement

N’utilisez pas SslProtocols.Default parce qu’il définit la version TLS sur SSL3 et TLS 1.0 qui sont obsolètes.

Lorsque votre application permet au système d’exploitation de choisir la version TLS :

Il tire automatiquement avantage des nouveaux protocoles TLS qui sont ajoutés.
Le système d’exploitation bloque les protocoles qui sont découverts comme n’étant pas sécurisés (par exemple, SSL3 et TLS 1.0).

Cet article explique comment activer la sécurité maximale disponible pour la version de .NET Framework que votre application cible et sur laquelle elle s’exécute. Lorsqu’une application définit explicitement une version et un protocole de sécurité, il refuse toute autre solution et le comportement de .NET Framework et du système d’exploitation par défaut. Si vous souhaitez que votre application soit en mesure de négocier une connexion TLS 1.3, la définition explicite d’une version antérieure de TLS empêche une connexion TLS 1.3.

Si vous n’avez pas le choix et devez indiquer explicitement une version de protocole, nous vous recommandons vivement de spécifier TLS 1.1.2 ou TLS 1.3 (currently considered secure). Pour obtenir des conseils sur l’identification et la suppression des dépendances de TLS 1.0, téléchargez le livre blanc Résolution du problème de TLS 1.0.

WCF prend en charge TLS 1.2 par défaut dans .NET Framework 4.7. À compter de .NET Framework 4.7.1, WCF passe à la version configurée du système d’exploitation par défaut. Si une application est explicitement configurée avec SslProtocols.None, WCF utilise le paramètre par défaut du système d’exploitation lors de l’utilisation du transport NetTcp.

Vous pouvez poser des questions concernant ce document dans le problème GitHub Meilleures pratiques TLS (Transport Layer Security) avec .NET Framework.

Auditez votre code et apportez-lui des modifications

Pour les applications ASP.NET, inspectez l’élément <system.web><httpRuntime targetFramework> de web.config pour vérifier que vous utilisez la version cible du .NET Framework.

Pour les Windows Forms et d’autres applications, consultez Comment : cibler une version du .NET Framework.

Utilisez les sections suivantes pour vérifier que vous n’utilisez pas une version spécifique de SSL ou TLS.

Si vous devez définir explicitement un protocole de sécurité

Si vous devez définir explicitement un protocole de sécurité au lieu de laisser .NET Framework ou le système d’exploitation le sélectionner, choisissez ces protocoles :

Pour .NET Framework 3.5: TLS 1.2
Pour .NET Framework 4.6.2 ou version ultérieure : TLS 1.3

Si les protocoles indiqués ne sont pas énumérés, vous pouvez les ajouter en tant que fichier d’extension. Voir ci-dessous :

SslProtocolExtensions.cs

namespace System.Security.Authentication
{
    public static class SslProtocolsExtensions
    {
        // For .NET Framework 3.5
        public const SslProtocols Tls12 = (SslProtocols)3072;
        // For .NET Framework 4.6.2 and later
        public const SslProtocols Tls13 = (SslProtocols)12288;
    }
}

SecurityProtocolExtensions.cs

using System.Security.Authentication;

namespace System.Net
{
    public static class SecurityProtocolTypeExtensions
    {
        // For .NET Framework 3.5
        public const SecurityProtocolType Tls12 = (SecurityProtocolType)SslProtocolsExtensions.Tls12;
        // For .NET Framework 4.6.2 and later
        public const SecurityProtocolType Tls13 = (SecurityProtocolType)SslProtocolsExtensions.Tls13;
    }
}

Pour plus d’informations, consultez Prise en charge des versions par défaut du système TLS, inclues dans .NET Framework 3.5 sur Windows 8.1 et Windows Server 2012 R2.

Pour les API System.Net (HttpClient, SslStream)

Si votre application cible .NET Framework 4.7 ou versions ultérieures

Les sections suivantes montrent comment configurer votre application pour qu’elle utilise currently considered secure versions de TLS. (TLS 1.2, TLS 1.3)

Pour HttpClient et HttpWebRequest

ServicePointManager, avec .NET Framework 4.7 et ultérieur, va utiliser le protocole de sécurité par défaut configuré dans le système d’exploitation. Pour obtenir le choix du système d’exploitation par défaut, si possible, ne définissez pas de valeur pour la propriété ServicePointManager.SecurityProtocol, qui est définie par défaut sur SecurityProtocolType.SystemDefault.

Comme la valeur SecurityProtocolType.SystemDefault entraîne l’utilisation par ServicePointManager du protocole de sécurité par défaut configuré par le système d’exploitation, votre application peut s’exécuter différemment en fonction du système d’exploitation sur lequel elle est exécutée. Par exemple, Windows 10 utilise TLS 1.2, tandis que Windows 11 utilise TLS 1.3.

Pour SslStream

SslStream, à l’aide de .NET Framework 4.7 et versions ultérieures, la valeur par défaut est le système d’exploitation en choisissant le meilleur protocole de sécurité et la meilleure version. Pour obtenir le meilleur système d’exploitation par défaut, si possible, n’utilisez pas les surcharges de méthode de SslStream qui accepte un paramètre SslProtocols explicite. Sinon, passez SslProtocols.None. Nous vous recommandons de ne pas utiliser Default ; le paramètre SslProtocols.Default force l’utilisation de SSL 3.0 /TLS 1.0 et empêche celle de TLS 1.2.

Ne définissez pas une valeur pour la propriété SecurityProtocol (pour la mise en réseau HTTP).

N’utilisez pas les surcharges de méthode de SslStream qui accepte un paramètre SslProtocols explicite (pour la mise en réseau des sockets TCP). Lorsque vous reciblez votre application vers .NET Framework 4.7 ou versions ultérieures, vous suivez les recommandations de meilleures pratiques.

Pour les applications WCF

Si votre application cible .NET Framework 4.7 ou versions ultérieures

Les sections suivantes montrent comment configurer votre application pour qu’elle utilise currently considered secure versions de TLS. (TLS 1.2, TLS 1.3)

Utilisation du transport TCP utilisant la sécurité de transport avec des informations d’identification de certificat

WCF utilise la même pile de mise en réseau que le reste de .NET Framework.

Si vous ciblez 4.7.1, WCF est configuré pour autoriser le système d’exploitation à choisir le meilleur protocole de sécurité par défaut, sauf s’il est configuré de manière explicite :

Dans votre fichier de configuration de l'application.
Ou, dans votre application du code source.

Par défaut, .NET Framework 4.7 et versions ultérieures est configuré pour utiliser TLS 1.2 et autoriser les connexions utilisant TLS 1.1 ou TLS 1.0. Configurez WCF pour autoriser le système d’exploitation à choisir le meilleur protocole de sécurité en configurant votre liaison pour utiliser SslProtocols.None. Sa valeur définie peut être SslProtocols. SslProtocols.None est accessible à partir de Transport. NetTcpSecurity.Transport est accessible à partir de Security.

Si vous utilisez une liaison personnalisée :

Configurez WCF pour autoriser le système d’exploitation à choisir le meilleur protocole de sécurité en configurant SslProtocols pour utiliser SslProtocols.None.
Ou configurez le protocole utilisé avec le chemin d’accès à la configuration system.serviceModel/bindings/customBinding/binding/sslStreamSecurity:sslProtocols.

Si vous n’utilisez pas de liaison personnalisée et que vous définissez votre liaison WCF à l’aide de la configuration, définissez le protocole utilisé avec le chemin d’accès à configuration system.serviceModel/bindings/netTcpBinding/binding/security/transport:sslProtocols.

Utilisation de la sécurité des messages avec des informations d’identification de certificat

.NET Framework 4.7 et versions ultérieures utilise par défaut le protocole spécifié dans la propriété SecurityProtocol. Lorsque AppContextSwitch Switch.System.ServiceModel.DisableUsingServicePointManagerSecurityProtocols est défini sur true, WCF choisit le meilleur protocole, jusqu'à TLS 1.0.

Si votre application cible une version de .NET Framework antérieure à 4.7

Les sections suivantes montrent comment configurer votre application pour qu’elle utilise currently considered secure versions de TLS. (TLS 1.2, TLS 1.3)

Utilisation de .NET Framework 4.6.2 à l’aide de la sécurité de transport TCP avec des informations d’identification de certificat

L’infrastructure WCF choisit automatiquement le protocole le plus élevé disponible, jusque TLS 1.2, à moins de configurer explicitement une version de protocole. Pour plus d’informations, consultez la section précédente Pour le transport TCP de WCF utilisant la sécurité de transport avec les informations d’identification de certificat.

Utilisation de .NET Framework 3.5 à l’aide de la sécurité de transport TCP avec des informations d’identification de certificat

Il est indiqué explicitement à ces versions de l’infrastructure WCF d’utiliser les valeurs SSL 3.0 et TLS 1.0. Ces valeurs ne peuvent pas être modifiées. Vous devez mettre à jour et recibler vers NET Framework 4.6.2 ou des versions ultérieures pour utiliser TLS 1.2.

Configurer la sécurité via des commutateurs AppContext (pour .NET Framework 4.6.2 ou versions ultérieures)

Les commutateurs AppContext décrits dans cette section s’appliquent si votre application cible ou s’exécute sur .NET Framework 4.6.2 ou versions ultérieures. Par défaut ou s’ils sont définis explicitement, les commutateurs doivent être false si possible. Si vous souhaitez configurer la sécurité via un ou les deux commutateurs, ne spécifiez pas de valeur du protocole de sécurité dans votre code ; ceci pourrait écraser le ou les commutateurs.

Pour les API System.Net (HttpClient, SslStream)

Les commutateurs ont le même effet, que vous procédiez à la mise en réseau HTTP (ServicePointManager) ou à la mise en réseau des sockets TCP (SslStream).

Switch.System.Net.DontEnableSchUseStrongCrypto

La valeur de false pour Switch.System.Net.DontEnableSchUseStrongCrypto incite votre application à utiliser un chiffrement fort. La valeur de false pour DontEnableSchUseStrongCrypto utilise des protocoles réseau plus sécurisés (TLS 1.2 et TLS 1.1) et bloque les protocoles qui ne sont pas sécurisés. Pour plus d’informations, consultez L’indicateur SCH_USE_STRONG_CRYPTO. La valeur de true désactive le chiffrement fort pour votre application. Ce commutateur affecte seulement les connexions clientes (sortantes) dans votre application.

Si votre application cible .NET Framework 4.6.2 ou des versions ultérieures, la valeur par défaut de ce commutateur est false. Il s’agit d’une valeur par défaut sécurisée, que nous vous recommandons. Si votre application s’exécute sur .NET Framework 4.6.2, mais cible une version antérieure, la valeur par défaut du commutateur est true. Dans ce cas, vous devez le définir explicitement sur false.

DontEnableSchUseStrongCrypto doit uniquement avoir une valeur de true si vous avez besoin de vous connecter à d’anciens services qui ne prennent pas en charge le chiffrement fort et ne peuvent pas être mis à niveau.

Switch.System.Net.DontEnableSystemDefaultTlsVersions

La valeur de false pour Switch.System.Net.DontEnableSystemDefaultTlsVersions incite votre application à autoriser le système d’exploitation à choisir le protocole. Une valeur de true incite votre application à utiliser des protocoles sélectionnés par .NET Framework.

Si votre application cible .NET Framework 4.7 ou versions ultérieures, la valeur par défaut de ce commutateur est false. Il s’agit d’une valeur par défaut sécurisée, que nous vous recommandons. Si votre application s’exécute sur .NET Framework 4.7 ou versions ultérieures, mais cible une version antérieure, la valeur par défaut du commutateur est true. Dans ce cas, vous devez le définir explicitement sur false.

Pour les applications WCF

Switch.System.ServiceModel.DisableUsingServicePointManagerSecurityProtocols

La valeur de false pour Switch.System.ServiceModel.DisableUsingServicePointManagerSecurityProtocols incite votre application à utiliser la valeur définie dans ServicePointManager.SecurityProtocols pour la sécurité du message à l’aide des informations d’identification du certificat. La valeur de true utilise le protocole le plus élevé disponible, jusque TLS1.0

Pour les applications ciblant le .NET Framework 4.7 et versions ultérieures, cette valeur par défaut est false. Pour les applications ciblant .NET Framework 4.6.2 et versions antérieures, cette valeur par défaut est true.

Switch.System.ServiceModel.DontEnableSystemDefaultTlsVersions

La valeur de false pour Switch.System.ServiceModel.DontEnableSystemDefaultTlsVersions incite la configuration par défaut à autoriser le système d’exploitation à choisir le protocole. La valeur de true utilise le protocole le plus élevé disponible par défaut, jusque TLS1.2.

Pour les applications ciblant le .NET Framework 4.7.1 et versions ultérieures, cette valeur par défaut est false. Pour les applications ciblant .NET Framework 4.7 et versions antérieures, cette valeur par défaut est true.

Pour plus d’informations sur les protocoles TLS, consultez Atténuation : protocoles TLS. Pour plus d'informations sur les commutateurs AppContext, consultez <AppContextSwitchOverrides> Element.

Configurer la sécurité via le Registre Windows

Avertissement

La définition des clés de Registre affecte toutes les applications sur le système. Utilisez cette option uniquement si vous contrôlez entièrement l’ordinateur et pouvez contrôler les modifications apportées au Registre.

Si la définition d’un ou des deux commutateurs AppContext n’est pas possible, vous pouvez contrôler les protocoles de sécurité utilisés par votre application avec les clés de Registre Windows décrites dans cette section. Vous ne pourrez peut-être pas utiliser un ou les deux commutateurs AppContext si votre application s’exécute sur .NET Framework 3.5 ou une version antérieure, ou si vous ne pouvez pas modifier le fichier de configuration. Si vous souhaitez configurer la sécurité avec le registre, ne spécifiez pas de valeur du protocole de sécurité dans votre code ; ceci écrase le paramètre du registre.

Les noms des clés de Registre sont similaires aux noms des commutateurs AppContext correspondants, mais sans un DontEnable ajouté au nom. Par exemple, le AppContext commutateur DontEnableSchUseStrongCrypto est la clé de Registre appelée SchUseStrongCrypto.

Ces clés sont disponibles dans toutes les versions du .NET Framework.

Toutes les clés de Registre décrites ci-dessous ont le même effet, que vous procédiez à la mise en réseau HTTP (ServicePointManager) ou à la mise en réseau des sockets TCP (SslStream).

SchUseStrongCrypto

L’entrée de Registre HKEY_LOCAL_MACHINE\SOFTWARE\[Wow6432Node\]Microsoft\.NETFramework\<VERSION>: SchUseStrongCrypto a une valeur de type DWORD. La valeur de 1 incite votre application à utiliser un chiffrement fort. Le chiffrement fort utilise des protocoles réseau plus sécurisés (TLS 1.2 et TLS 1.1) et bloque les protocoles qui ne sont pas sécurisés. La valeur de 0 désactive le chiffrement fort. Pour plus d’informations, consultez L’indicateur SCH_USE_STRONG_CRYPTO. Ce paramètre du Registre affecte seulement les connexions clientes (sortantes) dans votre application.

Si votre application cible .NET Framework 4.6 ou versions ultérieures, la valeur par défaut de cette clé est 1. Il s’agit d’une valeur par défaut sécurisée, que nous vous recommandons. Si votre application cible .NET Framework 4.5.2 ou antérieur, la valeur par défaut de cette clé est 0. Dans ce cas, vous devez le définir explicitement sa valeur sur 1.

Cette clé doit uniquement avoir une valeur de 0 si vous avez besoin de vous connecter à d’anciens services qui ne prennent pas en charge le chiffrement fort et ne peuvent pas être mis à niveau.

SystemDefaultTlsVersions

L’entrée de Registre HKEY_LOCAL_MACHINE\SOFTWARE\[Wow6432Node\]Microsoft\.NETFramework\<VERSION>: SystemDefaultTlsVersions a une valeur de type DWORD. La valeur de 1 incite votre application à autoriser le système d’exploitation à choisir le protocole. Une valeur de 0 incite votre application à utiliser des protocoles sélectionnés par .NET Framework.

<VERSION> doit être v4.0.30319 (pour .NET Framework 4 et versions ultérieures) ou v2.0.50727 (pour .NET Framework 3.5).

Si votre application cible .NET Framework 4.7 ou versions ultérieures, la valeur par défaut de cette clé est 1. Il s’agit d’une valeur par défaut sécurisée, que nous vous recommandons. Si votre application cible .NET Framework 4.6.1 ou antérieur, la valeur par défaut de cette clé est 0. Dans ce cas, vous devez le définir explicitement sa valeur sur 1.

Pour plus d’informations, consultez Mise à jour cumulative pour Windows 10 Version 1511 et Windows Server 2016 Technical Preview 4 : 10 mai 2016.

Pour plus d’informations sur .NET Framework 3.5.1, consultez Prise en charge des versions par défaut du système TLS, inclues dans .NET Framework 3.5.1 sur Windows 7 SP1 et Windows Server 2008 R2 SP1.

Le fichier .REG suivant définit les entrées de Registre et leurs variantes sur leurs valeurs les plus sûres :

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v2.0.50727]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001

Configurer des protocoles Schannel dans le Registre Windows

Vous pouvez utiliser le Registre pour un contrôle affiné sur les protocoles négociés par votre application client et/ou serveur. La mise en réseau de votre application passe par Schannel (autre nom pour Canal sécurisé). En configurant Schannel, vous pouvez configurer le comportement de votre application.

Démarrez avec la clé de Registre HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols. Sous cette clé, vous pouvez créer toutes les sous-clés dans l’ensemble TLS 1.2, TLS 1.3. Sous chacune de ces sous-clés, vous pouvez créer des sous-clés Client et/ou Server. Sous Client et Server, vous pouvez créer des valeurs DWORD DisabledByDefault (0 ou 1) et Enabled (0 ou 1).

Pour plus d’informations, consultez Paramètres du Registre TLS – Schannel

L’indicateur SCH_USE_STRONG_CRYPTO

Quand elle est activée (par défaut, par un commutateur AppContext ou par le Registre Windows), .NET Framework utilise l’indicateur SCH_USE_STRONG_CRYPTO quand votre application lance une connexion TLS vers un serveur. Le .NET Framework passe l’indicateur à Schannel pour lui demander de désactiver les algorithmes de chiffrement faibles connus, les suites de chiffrement et les versions du protocole TLS/SSL qui peuvent être activées pour une meilleure interopérabilité. Pour plus d'informations, consultez les pages suivantes :

L’indicateur SCH_USE_STRONG_CRYPTO est également transmis à Schannel pour les connexions clientes (sortantes) quand vous utilisez explicitement les valeurs énumérées Tls11 ou Tls12 de SecurityProtocolType ou SslProtocols. L’indicateur SCH_USE_STRONG_CRYPTO est utilisé seulement pour les connexions où votre application joue le rôle du client. Vous pouvez désactiver les protocoles et algorithmes faibles quand vos applications jouent le rôle de serveur en configurant les paramètres du Registre Schannel à l’échelle de l’ordinateur.

Partager via

Bonnes pratiques du protocole TLS (Transport Layer Security) avec le .NET Framework

Qu’est-ce que le protocole TLS (Transport Layer Security) ?

Qui peut profiter de ce document ?

Prise en charge de TLS dans .NET Framework

Recommandations

Auditez votre code et apportez-lui des modifications

Si vous devez définir explicitement un protocole de sécurité

Pour les API System.Net (HttpClient, SslStream)

Si votre application cible .NET Framework 4.7 ou versions ultérieures

Pour HttpClient et HttpWebRequest

Pour SslStream

Pour les applications WCF

Si votre application cible .NET Framework 4.7 ou versions ultérieures

Utilisation du transport TCP utilisant la sécurité de transport avec des informations d’identification de certificat

Utilisation de la sécurité des messages avec des informations d’identification de certificat

Si votre application cible une version de .NET Framework antérieure à 4.7

Utilisation de .NET Framework 4.6.2 à l’aide de la sécurité de transport TCP avec des informations d’identification de certificat

Utilisation de .NET Framework 3.5 à l’aide de la sécurité de transport TCP avec des informations d’identification de certificat

Configurer la sécurité via des commutateurs AppContext (pour .NET Framework 4.6.2 ou versions ultérieures)

Pour les API System.Net (HttpClient, SslStream)

Switch.System.Net.DontEnableSchUseStrongCrypto

Switch.System.Net.DontEnableSystemDefaultTlsVersions

Pour les applications WCF

Switch.System.ServiceModel.DisableUsingServicePointManagerSecurityProtocols

Switch.System.ServiceModel.DontEnableSystemDefaultTlsVersions

Configurer la sécurité via le Registre Windows

SchUseStrongCrypto

SystemDefaultTlsVersions

Configurer des protocoles Schannel dans le Registre Windows

L’indicateur SCH_USE_STRONG_CRYPTO

Ressources supplémentaires