Windows Server 2008 R2 semble prendre en charge TLS 1.1 et 1.2 mais ils sont désactivés par défaut.
Pourquoi sont-ils désactivés par défaut?
Ont-ils des inconvénients?
17
Windows Server 2008 R2 semble prendre en charge TLS 1.1 et 1.2 mais ils sont désactivés par défaut.
Pourquoi sont-ils désactivés par défaut?
Ont-ils des inconvénients?
Server 2008 R2 / Windows 7 a introduit la prise en charge de TLS 1.1 et TLS 1.2 pour Windows, et a été publié avant les attaques qui ont rendu TLS 1.0 vulnérable, il est donc probablement juste une question de TLS 1.0 étant la valeur par défaut car il s'agissait de la version TLS la plus largement utilisée au moment de la sortie de Server 2008 R2 (juillet 2009).
Je ne sais pas exactement comment vous le sauriez, ou découvrez «pourquoi» une décision de conception a été prise, mais étant donné que Windows 7 et Server 2008 R2 ont introduit la fonctionnalité dans la famille Windows et que Windows Server 2012 utilise TLS 1.2 par défaut, il semble suggérer que c'était une question de "la façon dont les choses étaient faites" à l'époque. TLS 1.0 était toujours "assez bon", donc c'était la valeur par défaut, mais TLS 1.1 et 1.2 étaient pris en charge pour la prise en charge directe et l'opérabilité directe.
Ce blog technet d'un employé de Microsoft recommande d'activer les nouvelles versions de TLS et note également que (à partir d'octobre 2011):
Parmi les serveurs Web, IIS 7.5 est le seul à prendre en charge TLS 1.1 et TLS 1.2. Pour l'instant, Apache ne prend pas en charge ces protocoles car OPENSSL ne les prend pas en charge. Espérons qu'ils rattraperont les nouvelles normes de l'industrie.
Cela soutient également l'idée que les nouvelles versions TLS n'étaient pas activées par défaut dans Server 2008 R2 pour la simple raison qu'elles étaient plus récentes et n'étaient pas largement prises en charge ou utilisées à l'époque - Apache et OpenSSL ne les prenaient même pas encore en charge , encore moins utilisez-les par défaut.
Des détails sur la manière d'activer et de désactiver les différentes versions SSL / TLS peuvent être trouvés dans le numéro d'article Microsoft KB 245030, intituléHow to restrict the use of certain cryptographic algorithms and protocols in Schannel.dll . De toute évidence, les Clientclés contrôlent Internet Explorer et les Serverclés couvrent IIS.
Je me le demandais moi-même ... peut-être simplement en raison de problèmes de compatibilité connus à l'époque ... J'ai trouvé cette entrée de blog MSDN (du 24 mars 2011):
Il parle de certains serveurs Web qui se comportent mal dans la façon dont ils répondent aux demandes de protocole non prises en charge, ce qui a ensuite empêché le client de recourir à un protocole pris en charge, le résultat final étant que les utilisateurs ne pouvaient pas accéder aux sites Web.
Citant une partie de cette entrée de blog ici:
Le serveur n'est pas censé se comporter de cette façon - il devrait plutôt simplement répondre en utilisant la dernière version du protocole HTTPS qu'il prend en charge (par exemple, "3.1" aka TLS 1.0). Maintenant, si le serveur avait gracieusement fermé la connexion à ce stade, il aurait être correct - le code dans WinINET se replierait et réessayerait la connexion en n'offrant que TLS 1.0. WinINET inclut un code tel que TLS1.1 et 1.2 se replier sur TLS1.0, puis se replier sur SSL3 (si activé) puis SSL2 (si activé). L'inconvénient du repli est la performance - les allers-retours supplémentaires requis pour la nouvelle poignée de main de version inférieure entraîneront généralement une pénalité s'élevant à des dizaines ou des centaines de millisecondes.
Cependant, ce serveur a utilisé un TCP / IP RST pour abandonner la connexion, ce qui désactive le code de secours dans WinINET et entraîne l'abandon de la séquence de connexion entière, laissant à l'utilisateur le message d'erreur «Internet Explorer ne peut pas afficher la page Web».