Paramètres du Registre protocole TLS

Cet article décrit les informations de paramètre de Registre prises en charge pour l’implémentation Windows des protocoles TLS (Transport Layer Security) et SSL (Secure Sockets Layer) par le biais du fournisseur SSP (Security Support Provider) Schannel. Les sous-clés et entrées de Registre couvertes dans cet article vous aident à administrer et à dépanner le SSP Schannel, en particulier avec les protocoles TLS et SSL.

Journalisation Schannel

Il existe huit niveaux de journalisation pour les événements Schannel enregistrés dans le journal des événements système et visibles à l’aide de l’observateur d’événements. Ce chemin de Registre est stocké HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL sous la clé EventLogging avec une valeur DWORD définie sur 1.

CertificateMappingMethods

Quand une application serveur nécessite une authentification du client, SChannel tente automatiquement de mapper le certificat fourni par l’ordinateur client à un compte d’utilisateur. Vous pouvez authentifier les utilisateurs qui se connectent avec un certificat client en créant des mappages qui lient les informations de certificat à un compte d’utilisateur Windows.

Après avoir créé et activé un mappage de certificat, chaque fois qu’un client présente un certificat client, votre application serveur associe automatiquement cet utilisateur au compte d’utilisateur Windows approprié.

Dans la plupart des cas, un certificat est mappé avec un compte d’utilisateur de deux manières :

• Un seul certificat est mappé avec un compte d’utilisateur (mappage un-à-un).
• Plusieurs certificats sont mappés avec un compte d’utilisateur (mappage plusieurs-à-un).

Le fournisseur SChannel utilise quatre méthodes de mappage de certificats :

1. Mappage S4U (service-for-user) Kerberos (activé par défaut)
2. Mappage du nom principal de l’utilisateur
3. Mappage un-à-un (également appelé mappage objet/émetteur)
4. Mappage plusieurs-à-un

Chemin du registre : HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

Versions applicables : comme indiqué dans la liste s’applique au début de cet article.

Chiffrements

Les chiffrements TLS/SSL doivent être contrôlés en configurant l’ordre de la suite de chiffrement. Pour plus d’informations, consultez Configuration de l’ordre de la suite de chiffrement TLS.

Pour plus d’informations sur les ordres de la suite de chiffrement par défaut utilisés par le fournisseur SSP SChannel, consultez Suites de chiffrement dans TLS/SSL (SSP SChannel).

CipherSuites

La configuration des suites de chiffrement TLS/SSL doit être effectuée à l’aide de la stratégie de groupe, mdm ou PowerShell, consultez Configuration de l’ordre de suite de chiffrement TLS pour plus d’informations.

Pour plus d’informations sur les ordres de la suite de chiffrement par défaut utilisés par le fournisseur SSP SChannel, consultez Suites de chiffrement dans TLS/SSL (SSP SChannel).

ClientCacheTime

Cette entrée spécifie la durée de vie de l’élément de cache de session TLS du client en millisecondes. À compter de Windows Server 2008 et de Windows Vista, la valeur par défaut est de 10 heures. La valeur 0 désactive la mise en cache de session TLS sur le client.

La première fois qu’un client se connecte à un serveur via le fournisseur SSP SChannel, une liaison TLS/SSL complète est établie. Ensuite, le secret principal, la suite de chiffrement et les certificats sont stockés dans le cache de session sur le client et le serveur correspondants.

Chemin du registre : HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

EnableOcspStaplingForSni

L’association OCSP (Online Certificate Status Protocol) permet à un serveur web, par exemple IIS (Internet Information Services), de fournir l’état de révocation actuel d’un certificat de serveur lorsqu’il envoie le certificat de serveur à un client pendant l’établissement d’une liaison TLS. Cette fonctionnalité réduit la charge des serveurs OCSP, car le serveur web peut mettre en cache l’état OCSP actuel du certificat de serveur et l’envoyer à plusieurs clients web. Sans cette fonctionnalité, chaque client web tenterait de récupérer l’état OCSP actuel du certificat de serveur auprès du serveur OCSP, ce qui générerait une charge élevée sur ce serveur OCSP.

En dehors d’IIS, les services web sur http.sys peuvent également tirer parti de ce paramètre, notamment les services de fédération Active Directory (AD FS) et le Proxy d’application web (WAP).

Par défaut, la prise en charge d’OCSP est activée pour les sites web IIS comportant une liaison sécurisée (SSL/TLS) simple. Cependant, cette prise en charge n’est pas activée par défaut si le site web IIS utilise l’un des types de liaisons SSL/TLS suivants ou les deux :

• Exiger l'indication de nom de serveur
• Utiliser le magasin de certificats centralisés

Dans ce cas, la réponse hello du serveur pendant l’établissement de liaison TLS n’inclut pas par défaut un état d’agrafage OCSP. Ce comportement améliore les performances : l’implémentation de l’association OCSP Windows s’adapte à des centaines de certificats de serveur. Toutefois, l’indication de nom de serveur (SNI) et le magasin de certificats central (CCS) permettent à IIS de s’adapter à des milliers de sites web qui ont potentiellement des milliers de certificats de serveur, ce qui permet l’enregistrement OCSP pour les liaisons CCS peut entraîner des problèmes de performances.

Versions applicables : toutes les versions à compter de Windows Server 2012 et Windows 8.

Chemin du registre : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

Ajoutez la clé suivante :

"EnableOcspStaplingForSni"=dword:00000001

Pour désactiver l’option, définissez la valeur DWORD sur 0 :

"EnableOcspStaplingForSni"=dword:00000000

Codes de hachage

Les algorithmes de hachage TLS/SSL doivent être contrôlés en configurant l’ordre de la suite de chiffrement. Pour plus d’informations, consultez Configuration de l’ordre de la suite de chiffrement TLS.

IssuerCacheSize

Cette entrée contrôle la taille du cache de l’émetteur et est utilisée avec le mappage d’émetteur. Le fournisseur SSP SChannel tente de mapper tous les émetteurs de la chaîne de certificats du client, et pas seulement l’émetteur direct du certificat du client. Lorsque les émetteurs ne correspondent pas à un compte (cas classique), le serveur peut tenter de mapper le même nom d’émetteur à plusieurs reprises, des centaines de fois par seconde.

Pour éviter cela, le serveur a un cache négatif. Par conséquent, si un nom d’émetteur n’est pas mappé à un compte, il est ajouté au cache et le SSP SChannel ne tente pas de mapper à nouveau le nom de l’émetteur tant que l’entrée du cache n’expire pas. Cette entrée de Registre spécifie la taille du cache. Par défaut, cette entrée n’existe pas dans le Registre. La valeur par défaut est 100.

Versions applicables : toutes les versions à compter de Windows Server 2008 et Windows Vista.

Chemin du registre : HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

IssuerCacheTime

Cette entrée contrôle l’intervalle de temps d’expiration du cache en millisecondes. Le fournisseur SSP SChannel tente de mapper tous les émetteurs de la chaîne de certificats du client, et pas seulement l’émetteur direct du certificat du client. Lorsque les émetteurs ne correspondent pas à un compte (cas classique), le serveur peut tenter de mapper le même nom d’émetteur à plusieurs reprises, des centaines de fois par seconde.

Pour éviter cela, le serveur a un cache négatif. Par conséquent, si un nom d’émetteur n’est pas mappé à un compte, il est ajouté au cache et le SSP SChannel ne tente pas de mapper à nouveau le nom de l’émetteur tant que l’entrée du cache n’expire pas. Ce cache est conservé pour des raisons de performances, afin que le système ne continue pas de tente de mapper les mêmes émetteurs. Par défaut, cette entrée n’existe pas dans le Registre. La valeur par défaut est 10 minutes.

Versions applicables : toutes les versions à compter de Windows Server 2008 et Windows Vista.

Chemin du registre : HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

Tailles de clés KeyExchangeAlgorithm

Ces entrées suivantes peuvent ne pas exister dans le Registre par défaut et doivent être créées manuellement. L’utilisation d’algorithmes d’échange de clés doit être contrôlée en configurant l’ordre de la suite de chiffrement. Pour en savoir plus sur les algorithmes cryptographiques de la suite de chiffrement TLS/SSL, voir Suites de chiffrement dans TLS/SSL (SChannel SSP).

MaximumCacheSize

Cette entrée contrôle le nombre maximal de sessions TLS à mettre en cache. Définition de MaximumCacheSize pour 0 désactiver le cache de session côté serveur pour empêcher la reprise de session. L’augmentation de MaximumCacheSize au-dessus des valeurs par défaut entraîne Lsass.exe consommer de la mémoire supplémentaire. Chaque élément du cache de session exige généralement 2 à 4 Ko de mémoire. Par défaut, cette entrée n’existe pas dans le Registre. La valeur par défaut est 20 000 éléments.

Versions applicables : toutes les versions à compter de Windows Server 2008 et Windows Vista.

Chemin du registre : HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

Messagerie : analyse de fragments

Cette entrée contrôle la taille maximale autorisée d'un message de liaison TLS qui est accepté. Les messages supérieurs à la taille autorisée ne sont pas acceptés et l’établissement d’une liaison TLS échoue. Par défaut, ces entrées n’existent pas dans le Registre.

Lorsque vous définissez la valeur 0x0sur , les messages fragmentés ne sont pas traités et provoquent l’échec de l’établissement d’une liaison TLS. Les clients ou serveurs TLS de la machine active se retrouvent donc en non-conformité avec les RFC TLS.

La taille maximale autorisée peut être augmentée jusqu’à 2^16 octets. Autoriser un client ou un serveur à lire et stocker de grandes quantités de données non vérifiées à partir du réseau n’est pas une bonne idée et consomme de la mémoire supplémentaire pour chaque contexte de sécurité.

Ajout dans Windows 7 et Windows Server 2008 R2 : une mise à jour permettant à Internet Explorer dans Windows XP, Windows Vista et Windows Server 2008 d’analyser des messages fragmentés d’établissement d’une liaison TLS/SSL est disponible.

Chemin du registre : HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Messaging

Pour spécifier une taille maximale autorisée de messages de négociation TLS fragmentés acceptés par le client TLS, créez une MessageLimitClient entrée. Après avoir créé l’entrée, remplacez la valeur DWORD par la longueur de bits souhaitée. S’il n’est pas configuré, la valeur par défaut est 0x8000 octets.

Pour spécifier une taille maximale autorisée de messages de négociation TLS fragmentés que le serveur TLS accepte lorsqu’il n’y a pas d’authentification client, créez une MessageLimitServer entrée. Après avoir créé l’entrée, remplacez la valeur DWORD par la longueur de bits souhaitée. Si elle n’est pas configurée, la valeur par défaut est de 0x4000 octets.

Pour spécifier une taille maximale autorisée de messages de négociation TLS fragmentés que le serveur TLS accepte lorsqu’il existe une authentification cliente, créez une MessageLimitServerClientAuth entrée. Après avoir créé l’entrée, remplacez la valeur DWORD par la longueur de bits souhaitée. Si elle n’est pas configurée, la valeur par défaut est de 0x8000 octets.

SendTrustedIssuerList

Les serveurs TLS peuvent envoyer une liste des noms uniques des autorités de certification acceptables lors de la demande d’authentification du client. Cela peut aider les clients TLS à sélectionner un certificat client TLS approprié. Les serveurs TLS basés sur SChannel n’envoient pas cette liste d’émetteurs approuvés par défaut, car les autorités de certification approuvées par le serveur se trouvent exposées à des observateurs passifs et la quantité de données échangées au cours de l’établissement de la liaison TLS s’en trouve également augmentée. Si vous définissez cette valeur sur 1, les serveurs basés sur SChannel envoient leurs listes d’émetteurs approuvés.

L’envoi d’une liste d’émetteurs approuvés peut affecter ce que le client envoie lorsqu’il est demandé un certificat client. Par exemple, lorsque Microsoft Edge reçoit une requête d'authentification du client, il n'affiche que les certificats du client qui s'enchaînent à l'une des autorités de certification envoyées par le serveur. Si le serveur n'a pas envoyé de liste, Microsoft Edge affiche tous les certificats clients installés sur le client.

Ce comportement peut être souhaitable. Par exemple, lorsque les environnements PKI incluent des certificats croisés, les certificats client et serveur n’ont pas la même autorité de certification racine. Par conséquent, Microsoft Edge ne peut pas choisir un certificat qui s'enchaîne à l'une des autorités de certification du serveur. Les clients TLS peuvent proposer n’importe quel certificat client disponible lorsqu’un serveur n’envoie pas la liste des émetteurs approuvés. Par défaut, cette entrée n’existe pas dans le Registre.

Comportement d’envoi de la liste par défaut des émetteurs approuvés

Versions applicables : toutes les versions à compter de Windows Server 2008 et Windows Vista.

Chemin du registre : HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

ServerCacheTime

Cette entrée spécifie la durée de vie de l’élément de cache de session TLS du serveur en millisecondes. La valeur par défaut est 10 heures. La valeur 0 désactive la mise en cache de session TLS sur le serveur et empêche la reprise de session. Lorsque la valeur de cette entrée est supérieure aux valeurs par défaut, Lsass.exe consomme plus de mémoire. Chaque élément de cache de session nécessite en général entre 2 et 4 Ko de mémoire. Par défaut, cette entrée n’existe pas dans le Registre.

Versions applicables : toutes les versions à compter de Windows Server 2008 et Windows Vista.

Chemin du registre : HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

Durée du cache du serveur par défaut : 10 heures

Paramètres de version des protocoles TLS, DTLS et SSL

Le fournisseur SSP SChannel implémente différentes versions des protocoles TLS, DTLS et SSL. Les versions des protocoles prises en charge varient selon les versions de Windows. L’ensemble des versions des protocoles (D)TLS et SSL disponibles à l’échelle du système peut être restreint (mais pas étendu) par les appelants SSPI qui spécifient la structure SCH_CREDENTIALS dans l’appel AcquireCredentialsHandle. Il est recommandé aux appelants SSPI d’utiliser les valeurs par défaut du système, plutôt que d’imposer des restrictions sur la version des protocoles.

Une version prise en charge des protocoles (D)TLS et SSL peut se trouver dans les états suivants :

• Activé : sauf si l’appelant SSPI désactive explicitement cette version de protocole à l’aide de SCH_CREDENTIALS structure, SChannel SSP peut négocier cette version de protocole avec un homologue de prise en charge.
• Désactivé : SSP SChannel ne négocie pas cette version de protocole, quels que soient les paramètres que l’appelant SSPI peut spécifier.

Ces valeurs de Registre sont configurées séparément pour les rôles client et serveur de protocole sous les sous-clés de Registre nommées au format suivant :

<SSL/TLS/DTLS> <major version number>.<minor version number><Client\Server>

Ces sous-clés propres à la version peuvent être créées sous le chemin de Registre suivant :

• HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols

Par exemple, voici quelques chemins de Registre valides avec des sous-clés propres à la version :

• HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client

• HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server

• HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\DTLS 1.2\Client

Pour remplacer une valeur système par défaut et définir une version de protocole TLS ou SSL prise en charge sur l’état Enabled , créez une valeur de Registre DWORD nommée Enabled avec une valeur d’entrée de « 1 » sous la sous-clé spécifique à la version correspondante.

L’exemple suivant montre un client TLS 1.0 défini sur l’état Activé :

Pour remplacer une valeur par défaut système et définir une version de protocole TLS ou SSL prise en charge par l’état Disabled , remplacez la valeur de Registre DWORD par Enabled « 0 » sous la sous-clé spécifique à la version correspondante.

L’exemple suivant montre le protocole DTLS 1.2 désactivé dans le Registre :

Le basculement d’une version de protocole TLS ou SSL vers Disabled l’état peut entraîner l’échec des appels AcquireCredentialsHandle en raison de l’absence de versions de protocole activées à l’échelle du système et en même temps autorisées par des appelants SSPI particuliers. En outre, la réduction de l’ensemble de versions ( Enabled D)TLS et SSL peut interrompre l’interopérabilité avec les homologues distants.

Une fois que les paramètres de la version du protocole (D)TLS ou SSL sont modifiés, ils prennent effet sur les connexions établies à l'aide de gestionnaires d'informations d'identification ouverts par des appels AcquireCredentialsHandle ultérieurs. Les applications et services client et serveur (D)TLS et SSL ont tendance, pour des raisons de performances, à réutiliser les handles d’informations d’identification sur plusieurs connexions. Pour permettre à ces applications de réactiver leurs handles d’informations d’identification, une application ou un redémarrage du service peut être nécessaire.

Ces paramètres de Registre s’appliquent uniquement au fournisseur SSP SChannel et n’affectent pas les implémentations TLS et SSL tierces qui peuvent être installées sur le système.

Pour en savoir plus sur la gestion de la suite de chiffrement TLS à l'aide de PowerShell, consultez la référence de la commande TLS. Si vous souhaitez gérer les paramètres TLS à l'aide d'une stratégie de groupe, consultez Configuration de l'ordre de la suite de chiffrement TLS à l'aide d'une stratégie de groupe.