Modifications du protocole TLS (SSP Schannel) dans Windows 10 et Windows Server 2016
Modifications de la suite de chiffrement
Windows 10, version 1511 et Windows Server 2016 ajoutent la prise en charge de la configuration de l’ordre de la suite de chiffrement à l’aide de la gestion des périphériques mobiles (MDM).
Pour connaître les modifications de l’ordre de priorité de la suite de chiffrement, consultez Suites de chiffrement dans Schannel.
Ajout de la prise en charge des suites de chiffrement suivantes :
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (RFC 5289) dans Windows 10, version 1507 et Windows Server 2016
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (RFC 5289) dans Windows 10, version 1507 et Windows Server 2016
Modification de DisabledByDefault pour les suites de chiffrement suivantes :
- TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 (RFC 5246) dans Windows 10, version 1703
- TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 (RFC 5246) dans Windows 10, version 1703
- TLS_DHE_DSS_WITH_AES_256_CBC_SHA (RFC 5246) dans Windows 10, version 1703
- TLS_DHE_DSS_WITH_AES_128_CBC_SHA (RFC 5246) dans Windows 10, version 1703
- TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (RFC 5246) dans Windows 10, version 1703
- TLS_RSA_WITH_RC4_128_SHA dans Windows 10, version 1709
- TLS_RSA_WITH_RC4_128_MD5 dans Windows 10, version 1709
À compter de Windows 10, version 1507 et Windows Server 2016, les certificats SHA 512 sont pris en charge par défaut.
Modifications de la clé RSA
Windows 10, version 1507 et Windows Server 2016 ajoutent des options de configuration du Registre pour les tailles de clés RSA du client.
Pour plus d’informations, consultez Tailles de clé KeyExchangeAlgorithm.
Modifications des clés Diffie-Hellman
Windows 10, version 1507 et Windows Server 2016 ajoutent des options de configuration du Registre pour les tailles de clés Diffie-Hellman.
Pour plus d’informations, consultez Tailles de clé KeyExchangeAlgorithm.
Modifications de l’option SCH_USE_STRONG_CRYPTO
Avec Windows 10, version 1507 et Windows Server 2016, l’option SCH_USE_STRONG_CRYPTO désactive désormais NULL, MD5, DES et exporte les chiffrements.
Changements liés aux courbes elliptiques
Windows 10, version 1507 et Windows Server 2016 ajoutent la configuration de stratégie de groupe pour les courbes elliptiques dans les paramètres Configuration ordinateur > Modèles d’administration > Réseau> Paramètres de configuration SSL. La liste de l’ordre des courbes ECC spécifie l’ordre de préférence des courbes elliptiques et active les courbes prises en charge qui ne sont pas activées.
Ajout de la prise en charge des courbes elliptiques suivantes :
- BrainpoolP256r1 (RFC 7027) dans Windows 10, version 1507 et Windows Server 2016
- BrainpoolP384r1 (RFC 7027) dans Windows 10, version 1507 et Windows Server 2016
- BrainpoolP512r1 (RFC 7027) dans Windows 10, version 1507 et Windows Server 2016
- Curve25519 (RFC draft-ietf-tls-curve25519) dans Windows 10, version 1607 et Windows Server 2016
Prise en charge au niveau de la distribution pour SealMessage et UnsealMessage
Windows 10, version 1507 et Windows Server 2016 ajoutent la prise en charge de SealMessage/UnsealMessage au niveau de la distribution.
DTLS 1.2
Windows 10, version 1607 et Windows Server 2016 ajoutent la prise en charge de DTLS 1.2 (RFC 6347).
Pool de threads HTTP.SYS
Windows 10, version 1607 et Windows Server 2016 ajoutent une configuration du Registre de la taille du pool de threads utilisé pour gérer les établissements de liaisons TLS pour HTTP.SYS.
Chemin d’accès au Registre :
HKLM\SYSTEM\CurrentControlSet\Control\LSA
Pour spécifier une taille maximale du pool de threads par cœur de processeur, créez une entrée MaxAsyncWorkerThreadsPerCpu. Par défaut, cette entrée n’existe pas dans le Registre. Une fois l’entrée créée, remplacez la valeur DWORD par la taille souhaitée. Si le paramètre n’est pas configuré, la valeur maximum est 2 threads par cœur de processeur.
Prise en charge du protocole NPN (Next Protocol Negotiation)
À compter de Windows 10 version 1703, le protocole NPN (Next Protocol Negotiation) a été supprimé et n’est plus pris en charge.
Clé prépartagée (PSK)
Windows 10, version 1607 et Windows Server 2016 ajoutent la prise en charge de l’algorithme d’échange de clés PSK (RFC 4279).
Ajout de la prise en charge des suites de chiffrement PSK suivantes :
- TLS_PSK_WITH_AES_128_CBC_SHA256 (RFC 5487) dans Windows 10, version 1607 et Windows Server 2016
- TLS_PSK_WITH_AES_256_CBC_SHA384(RFC 5487) dans Windows 10, version 1607 et Windows Server 2016
- TLS_PSK_WITH_NULL_SHA256 (RFC 5487) dans Windows 10, version 1607 et Windows Server 2016
- TLS_PSK_WITH_NULL_SHA384 (RFC 5487) dans Windows 10, version 1607 et Windows Server 2016
- TLS_PSK_WITH_AES_128_GCM_SHA256 (RFC 5487) dans Windows 10, version 1607 et Windows Server 2016
- TLS_PSK_WITH_AES_256_GCM_SHA384 (RFC 5487) dans Windows 10, version 1607 et Windows Server 2016
Reprise de session sans amélioration des performances côté serveur sans état côté serveur
Windows 10, version 1507 et Windows Server 2016 fournissent 30 % de reprises de session en plus par seconde avec des tickets de session par rapport à Windows Server 2012.
Hachage de session et extension EMS (Extended Master Secret)
Windows 10, version 1507 et Windows Server 2016 ajoutent la prise en charge de RFC 7627 : hachage de session TLS (Transport Layer Security) et extension EMS (Extended Master Secret)
En raison de cette modification, Windows 10 et Windows Server 2016 nécessitent des mises à jour du fournisseur SSL CNG tiers pour prendre en charge NCRYPT_SSL_INTERFACE_VERSION_3 et décrire cette nouvelle interface.
Prise en charge de SSL
À compter de Windows 10, version 1607 et Windows Server 2016, le protocole SSL 3.0 est désactivé par défaut pour le client TLS et le serveur. Cela signifie que, sauf si l’application ou le service demande spécifiquement le protocole SSL 3.0 via l’interface SSPI, le client ne propose jamais ni n’accepte le protocole SSL 3.0 et que le serveur ne sélectionne jamais le protocole SSL 3.0.
À compter de Windows 10, version 1607 et Windows Server 2016, le protocole SSL 2.0 a été supprimé et il n’est plus pris en charge.
Modifications apportées à la conformité de Windows TLS concernant les exigences TLS 1.2 pour les connexions avec des clients TLS non conformes
Avec le protocole TLS 1.2, le client utilise l’extension « signature_algorithms » pour indiquer au serveur quelles paires d’algorithmes de signature/hachage peuvent être utilisées dans les signatures numériques (c’est-à-dire les certificats de serveur et d’échange de clés de serveur). Le document RFC TLS 1.2 exige également que le message de certificat du serveur respecte l’extension « signature_algorithms » :
« Si le client a fourni une extension « signature_algorithms », tous les certificats fournis par le serveur DOIVENT être signés par une paire d’algorithmes de hachage/signature qui apparaît dans cette extension. »
Dans la pratique, certains clients TLS tiers ne sont pas conformes au document RFC TLS 1.2. Ils ne parviennent pas à inclure toutes les paires d’algorithmes de hachage/signature qu’ils sont prêts à accepter dans l’extension « signature_algorithms » ou ils omettent complètement l’extension (dans ce cas, cela indique au serveur que le client prend en charge uniquement SHA1 avec RSA, DSA ou ECDSA).
Souvent, un seul certificat est configuré par point de terminaison d’un serveur TLS, ce qui signifie que le serveur ne peut pas toujours fournir un certificat conforme aux exigences du client.
Avant Windows 10 et Windows Server 2016, la pile TLS Windows respectait strictement les exigences du document RFC TLS 1.2, ce qui entraînait des échecs de connexion avec les clients TLS non conformes au document RFC et des problèmes d’interopérabilité. Dans Windows 10 et Windows Server 2016, les contraintes sont assouplies et le serveur peut envoyer un certificat qui n’est pas conforme au document RFC TLS 1.2, s’il s’agit de la seule option du serveur. Le client peut ensuite continuer ou mettre fin à l’établissement d’une liaison.
Lors de la validation des certificats serveur et client, la pile TLS Windows est strictement conforme au document RFC TLS 1.2 et autorise uniquement les algorithmes de signature et de hachage négociés dans les certificats serveur et client.