Vue d’ensemble de TLS/SSL (SSP Schannel)
Cette rubrique destinée aux professionnels de l’informatique décrit les modifications apportées aux fonctionnalités dans le fournisseur SSP (Security Support Provider) Schannel, lesquelles incluent les protocoles d’authentification TLS (Transport Layer Security), SSL (Secure Sockets Layer) et DTLS (Datagram Transport Layer Security), pour Windows Server 2012 R2, Windows Server 2012, Windows 8.1 et Windows 8.
Schannel est un fournisseur de service de sécurité (SSP) qui implémente les protocoles d’authentification standard Internet SSL, TLS et DTLS. L’interface SSPI (Security Support Provider Interface) est une API utilisée par les systèmes Windows pour exécuter des fonctions relatives à la sécurité, dont notamment l’authentification. L’interface SSPI fonctionne comme une interface commune à plusieurs fournisseurs SSP, y compris le fournisseur SSP Schannel.
Pour plus d’informations sur l’implémentation par Microsoft de TLS et SSL dans le fournisseur SSP Schannel, voir Informations techniques de référence sur TLS/SSL (2003).
Fonctionnalités de TLS/SSL (SSP Schannel)
Les informations suivantes décrivent les fonctionnalités de TLS dans le SSP Schannel.
Reprise de session TLS
Le protocole TLS (Transport Layer Security), composant du fournisseur SSP (Security Support Provider) Schannel, est utilisé pour sécuriser les données envoyées entre les applications via un réseau non approuvé. Vous pouvez utiliser TLS/SSL pour authentifier les serveurs et les ordinateurs clients et pour crypter les messages entre les parties authentifiées.
En raison de l’expiration de session, les appareils qui connectent fréquemment TLS aux serveurs doivent se reconnecter. Windows 8.1 et Windows Server 2012 R2 prennent désormais en charge RFC 5077 (reprise de session TLS sans état Server-Side). Cette modification apporte aux appareils Windows Phone et Windows RT les avantages suivants :
Utilisation des ressources sur le serveur réduite
Bande passante réduite, ce qui améliore l’efficacité des connexions client
Temps consacré aux négociations TLS réduit grâce aux reprises de connexion.
Notes
L’implémentation côté client de RFC 5077 a été ajoutée dans Windows 8.
Pour plus d’informations sur la reprise de session TLS sans état, consultez le document IETF RFC 5077.
Négociation de protocole d’application
Windows Server 2012 R2 et Windows 8.1 prennent en charge la négociation de protocole d’application TLS côté client afin que les applications puissent exploiter les protocoles dans le cadre du développement standard HTTP 2.0, et que les utilisateurs puissent accéder à des services en ligne (comme Google et Twitter) à l’aide d’applications qui exécutent le protocole SPDY.
Fonctionnement
Les applications serveur et client permettent l’extension de négociation de protocole d’application en fournissant des listes d’ID de protocoles d’application pris en charge par ordre de préférence décroissant. Le client TLS indique qu’il prend en charge la négociation de protocole d’application en incluant l’extension ALPN (Application Layer Protocol Negotiation) avec une liste de protocoles pris en charge par les clients dans le message ClientHello.
Lorsque le client TLS effectue la demande auprès du serveur, le serveur TLS lit sa liste de protocoles pris en charge pour trouver le protocole d’application favori également pris en charge par le client. Si ce protocole est trouvé, le serveur répond avec l’ID de protocole sélectionné et poursuit avec la négociation comme d’habitude. S’il n’existe aucun protocole d’application commun, le serveur envoie une alerte d’échec de négociation irrécupérable.
Gestion des émetteurs approuvés pour l’authentification du client
Lorsque l’authentification de l’ordinateur client avec SSL ou TLS est requise, le serveur peut être configuré pour envoyer une liste d’émetteurs de certificats approuvés. Cette liste contient l’ensemble des émetteurs de certificats qui seront approuvés par le serveur. En présence de plusieurs certificats, elle renseigne l’ordinateur client sur le certificat client à sélectionner. De plus, la chaîne de certificat que l’ordinateur client envoie au serveur doit être validée par rapport à la liste d’émetteurs approuvés configurée.
Avant Windows Server 2012 et Windows 8, les applications ou les processus utilisant le fournisseur SSP Schannel (y compris IIS et HTTP.sys) pouvaient fournir une liste des émetteurs approuvés qu’ils prenaient en charge pour l’authentification du client via une liste de certificats de confiance (CTL, Certificate Trust List).
Dans Windows Server 2012 et Windows 8, des modifications ont été apportées au processus d’authentification sous-jacent, de sorte que :
La gestion de la liste d’émetteurs approuvés CTL n’est plus prise en charge.
Le comportement d’envoi de la liste d’émetteurs approuvés par défaut est désactivé : la valeur par défaut de la clé de Registre SendTrustedIssuerList est désormais 0 (désactivée par défaut) au lieu de 1.
La compatibilité avec les versions précédentes des systèmes d’exploitation Windows est préservée.
Notes
Si le mappeur système est activé par l’application cliente et que vous avez configuré SendTrustedIssuers, ce mappeur système ajoute CN=NT Authority à la liste des émetteurs.
Quelle valeur cela ajoute-t-il ?
Introduite dans Windows Server 2012, l’utilisation de la liste CTL a été remplacée par une implémentation basée sur le magasin de certificats. Cela rend la gestion plus facile et conviviale grâce aux applets de commande de gestion de certificat existantes du fournisseur PowerShell et aux outils en ligne de commande, comme certutil.exe.
Bien que la taille maximale de la liste d’autorités de certification approuvées prise en charge par le SSP Schannel (16 Ko) reste identique à celui de Windows Server 2008 R2, dans Windows Server 2012, un magasin de certificats dédié a été ajouté pour les émetteurs d’authentification de client, pour que les certificats sans lien ne soient pas inclus dans le message.
Fonctionnement ?
Dans Windows Server 2012, la liste des émetteurs approuvés est configurée à l’aide des magasins de certificats : un magasin de certificats d’ordinateur global par défaut et un magasin facultatif par site. La source de la liste est déterminée comme suit :
Si un magasin d’informations d’identification spécifique est configuré pour le site, il sera utilisé comme source.
Si le magasin défini par l’application ne contient aucun certificat, Schannel vérifie le magasin Émetteurs d’authentification de client sur l’ordinateur local. Si ce magasin contient des certificats, Schannel l’utilise comme source. Si aucun certificat n’est trouvé dans les deux magasins, le magasin Racines de confiance est vérifié.
Si ni les magasins locaux, ni les magasins globaux ne contiennent les certificats adéquats, le fournisseur Schannel utilise le magasin Autorités de certification racines de confiance comme source de la liste d’émetteurs approuvés. (Il s’agit du comportement pour Windows Server 2008 R2.)
Si le magasin Autorités de certification racines de confiance utilisé contient un mélange de certificats d’émetteur d’autorité de certification (CA) et racine (auto-signé), seuls les certificats de l’émetteur d’autorité de certification seront envoyés au serveur par défaut.
Comment configurer Schannel pour utiliser le magasin de certificats pour émetteurs approuvés
Par défaut, l’architecture du SSP Schannel dans Windows Server 2012 utilise les magasins comme décrit précédemment pour gérer la liste des émetteurs approuvés. Vous pouvez toujours utiliser les applets de commande de gestion des certificats existantes du fournisseur PowerShell et les outils en ligne de commande comme Certutil pour gérer les certificats.
Pour plus d’informations sur la gestion des certificats avec le fournisseur PowerShell, consultez Applets de commande d’administration AD CS dans Windows.
Pour plus d’informations sur la gestion des certificats à l’aide de l’utilitaire de certificat, consultez certutil.exe.
Pour plus d’informations sur les données (y compris celles du magasin défini par l’application) définies pour les informations d’identification d’un Schannel, consultez Structure SCHANNEL_CRED (Windows).
Valeurs par défaut des modes d’approbation
Le fournisseur Schannel prend en charge trois modes de confiance pour l’authentification du client. Le mode de confiance contrôle la façon dont la chaîne de certificats du client est validée. Il s’agit d’un paramètre système contrôlé par le REG_DWORD « ClientAuthTrustMode » sous HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel.
| Valeur | Mode de confiance | Description |
|---|---|---|
| 0 | Approbation de machine (par défaut) | Requiert que le certificat client soit émis par un certificat de la liste des émetteurs approuvés. |
| 1 | Approbation de racine exclusive | Requiert qu’un certificat client soit chaîné vers un certificat racine contenu dans le magasin d’émetteurs approuvés spécifié par l’appelant. Le certificat doit également être émis par un émetteur figurant dans la liste des émetteurs approuvés. |
| 2 | Approbation de l’autorité de certification exclusive | Requiert qu’un certificat client soit chaîné vers un certificat d’autorité de certification intermédiaire ou un certificat racine du magasin d’émetteurs approuvés spécifié par l’appelant. |
Pour plus d’informations sur les échecs d’authentification dus aux problèmes de configuration des émetteurs approuvés, consultez l’article 280256 de la Base de connaissances.
Prise en charge de TLS pour les extensions SNI (Server Name Indicator)
La fonctionnalité d’indication du nom de serveur étend les protocoles SSL et TLS pour permettre l’identification correcte du serveur lorsque de nombreuses images virtuelles s’exécutent sur un serveur unique. Pour sécuriser correctement les communications entre un ordinateur client et un serveur, l’ordinateur client demande un certificat numérique au serveur. Une fois que le serveur a répondu à la demande et envoyé le certificat, l’ordinateur client l’examine, l’utilise pour chiffrer les communications et poursuit avec l’échange de type demande-réponse normal. Toutefois, dans un scénario d’hébergement virtuel, plusieurs domaines, chacun avec son propre certificat potentiellement distinct, sont hébergés sur un seul serveur. Dans ce cas, le serveur n’a aucun moyen de savoir au préalable quel certificat envoyer à l’ordinateur client. La fonctionnalité SNI permet à l’ordinateur client d’informer le domaine cible plus tôt dans le protocole et cela permet au serveur de sélectionner correctement le certificat approprié.
Quelle valeur cela ajoute-t-il ?
Ces fonctionnalités supplémentaires :
vous permettent d’héberger plusieurs sites Web SSL sur une combinaison de port et d’adresse IP unique ;
réduisent l’utilisation de la mémoire lorsque plusieurs sites Web SSL sont hébergés sur un serveur Web unique ;
permettent à plusieurs utilisateurs de se connecter simultanément à des sites Web SSL ;
vous permettent de fournir des indications aux utilisateurs finaux par le biais de l’interface de l’ordinateur pour qu’ils sélectionnent le certificat correct au cours d’un processus d’authentification client.
Fonctionnement
Le fournisseur SSP Schannel maintient un cache en mémoire des états de connexion client autorisés pour les clients. Cela permet aux ordinateurs clients de se reconnecter rapidement au serveur SSL sans faire l’objet d’une négociation SSL complète lors des visites suivantes. Cette utilisation efficace de la gestion des certificats permet d’héberger plus de sites sur un système d’exploitation Windows Server 2012 individuel par rapport aux précédentes versions de système d’exploitation.
La sélection de certificat par l’utilisateur final a été améliorée en vous permettant d’établir une liste de noms d’émetteurs de certificats probables afin de fournir à l’utilisateur final des indications quant au certificat à choisir. Cette liste peut être configurée à l’aide d’une stratégie de groupe.
Sécurité de la couche de transport de datagrammes
Le protocole DTLS version 1.0 a été ajouté au fournisseur SSP Schannel. Le protocole DTLS assure la confidentialité des communications pour les protocoles de datagrammes. Le protocole permet aux applications client/serveur de communiquer d’une manière conçue pour empêcher toute tentative d’écoute clandestine, de falsification ou de contrefaçon de message. Le protocole DTLS s’appuie sur le protocole TLS (Transport Layer Security) et fournit des garanties de sécurité équivalentes, réduisant le besoin d’utiliser IPsec ou concevant un protocole personnalisé de sécurité de la couche Application.
Quelle valeur cela ajoute-t-il ?
Les datagrammes sont communs dans la diffusion multimédia en continu, telle que les jeux ou la vidéoconférence sécurisée. L’ajout du protocole DTLS au fournisseur Schannel vous permet d’utiliser le modèle Windows SSPI familier pour la sécurisation des communications entre les ordinateurs clients et les serveurs. Le protocole DTLS a été délibérément conçu pour être aussi similaire que possible au protocole TLS, à la fois pour réduire au maximum les innovations en termes de sécurité et pour augmenter au maximum le degré de réutilisation de code et d’infrastructure.
Fonctionnement
Les applications qui utilisent DTLS sur UDP peuvent utiliser le modèle SSPI dans Windows Server 2012 et Windows 8. Certaines suites de chiffrement sont disponibles pour être configurées de façon similaire à TLS. Schannel continue à utiliser le fournisseur de services de chiffrement CNG qui tire profit de la certification FIPS 140, laquelle a été introduite pour la première fois dans Windows Vista.
Fonctionnalités dépréciées
Dans le fournisseur SSP Schannel pour Windows Server 2012 et Windows 8, aucune fonctionnalité ni aucune fonction n’est déconseillée.