Respuestas:
Server 2008 R2 / Windows 7 introdujo la compatibilidad con TLS 1.1 y TLS 1.2 para Windows, y se lanzó antes de los ataques que hicieron vulnerable a TLS 1.0, por lo que probablemente sea solo cuestión de que TLS 1.0 sea el valor predeterminado porque era la versión de TLS más utilizada en el momento en que se lanzó Server 2008 R2 (julio de 2009).
No estoy seguro de cómo saberlo con certeza, o averiguar "por qué" se tomó una decisión de diseño, pero dado que Windows 7 y Server 2008 R2 introdujeron la función en la familia de Windows, y Windows Server 2012 usa TLS 1.2 de forma predeterminada, parecería sugerir que era una cuestión de "la forma en que se hacían las cosas" en ese momento. TLS 1.0 todavía era "suficientemente bueno", por lo que era el valor predeterminado, pero TLS 1.1 y 1.2 eran compatibles con el soporte directo y la operabilidad directa.
Este blog de technet de un empleado de Microsoft recomienda habilitar las versiones más recientes de TLS y también señala que (a partir de octubre de 2011):
Entre los servidores web nuevamente, IIS 7.5 es el único que admite TLS 1.1 y TLS 1.2. A partir de ahora, Apache no admite estos protocolos, ya que OPENSSL no incluye soporte para ellos. Con suerte, alcanzarán los nuevos estándares de la industria.
Eso respalda aún más la idea de que las versiones más recientes de TLS no estaban habilitadas de manera predeterminada en Server 2008 R2 por la simple razón de que eran más nuevas y no eran ampliamente compatibles o utilizadas en ese momento: Apache y OpenSSL ni siquiera las admitían todavía, y mucho menos utilízalos por defecto.
Los detalles sobre cómo habilitar y deshabilitar las diversas versiones SSL / TLS se pueden encontrar en el artículo de Microsoft KB número 245030, tituladoHow to restrict the use of certain cryptographic algorithms and protocols in Schannel.dll . Obviamente, las Clientteclas controlan Internet Explorer y las Serverteclas cubren IIS.
Me preguntaba esto ... tal vez solo debido a problemas de compatibilidad conocidos en ese momento ... Encontré esta entrada del blog de MSDN (del 24 de marzo de 2011):
Habla sobre algunos servidores web que "se comportan mal" en la forma en que responden a solicitudes de protocolos no compatibles, lo que luego provocó que el cliente no recurriera a un protocolo compatible, con el resultado final de que los usuarios no podían acceder a los sitios web.
Citando parte de esa entrada de blog aquí:
No se supone que el servidor se comporte de esta manera; en cambio, se espera que simplemente responda utilizando la última versión del protocolo HTTPS que admite (por ejemplo, "3.1”, también conocido como TLS 1.0). Ahora, si el servidor hubiera cerrado la conexión con gracia en este punto, lo haría esté bien: el código en WinINET se restituiría y volvería a intentar la conexión ofreciendo solo TLS 1.0 WinINET incluye un código tal que TLS1.1 y 1.2 recurren a TLS1.0, luego recurren a SSL3 (si está habilitado) y luego a SSL2 (si está habilitado). La desventaja del retroceso es el rendimiento: los viajes de ida y vuelta adicionales necesarios para el nuevo apretón de manos de versión inferior generalmente generarán una penalización de decenas o cientos de milisegundos.
Sin embargo, este servidor usó un TCP / IP RST para cancelar la conexión, lo que deshabilita el código de recuperación en WinINET y hace que se abandone toda la secuencia de conexión, dejando al usuario con el mensaje de error "Internet Explorer no puede mostrar la página web".