Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
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).
- Utiliser 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
SslStreamqui accepte un paramètreSslProtocolsexplicite.- 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
SslStreamqui prennent un paramètreSslProtocolsexplicite, passezSslProtocols.SystemDefaultcomme 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 seront ajoutés à l'avenir.
- Le système d’exploitation bloque les protocoles qui ne sont 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.
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 vous ne trouvez pas les protocoles spécifiés dans l'énumération, 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)
Les sections suivantes montrent comment configurer votre application pour qu’elle utilise des « versions sécurisées » de TLS (à savoir TLS 1.2 et TLS 1.3) si elle cible .NET Framework 4.7 ou version ultérieure.
Pour HttpClient et HttpWebRequest
ServicePointManager utilise 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.
Étant donné que le SecurityProtocolType.SystemDefault paramètre entraîne l’utilisation 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 est défini par défaut sur le protocole de sécurité et la version choisis par le système d’exploitation. 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 meilleures pratiques recommandées.
Pour les applications WCF
Les sections suivantes montrent comment configurer votre application pour utiliser des « versions sécurisées actuellement considérées » de TLS (à savoir TLS 1.2 et TLS 1.3).
Utilisation du transport TCP avec sécurité de transport et des certificats d’authentification.
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 le code source de votre application.
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. Vous pouvez le définir sur 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 AppContextSwitchSwitch.System.ServiceModel.DisableUsingServicePointManagerSecurityProtocols est défini sur true, WCF choisit le meilleur protocole, jusqu'à TLS 1.0.
Configurer la sécurité via des commutateurs AppContext
Les commutateurs AppContext décrits dans cette section sont pertinents si votre application cible ou s’exécute sur .NET Framework 4.6.2 ou une version ultérieure. 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 de protocole de sécurité dans votre code ; cela remplace les commutateurs.
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.
Configurer des protocoles Schannel dans le Registre Windows
Vous pouvez utiliser le Registre pour un contrôle précis sur les protocoles négociés par votre application cliente 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
Lorsqu’il est activé (par défaut ou par AppContext commutateur), .NET Framework utilise l’indicateur SCH_USE_STRONG_CRYPTO lorsque votre application lance une connexion TLS à 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.