Risposte:
Server 2008 R2 / Windows 7 ha introdotto il supporto TLS 1.1 e TLS 1.2 per Windows ed è stato rilasciato prima degli attacchi che rendevano TLS 1.0 vulnerabile, quindi probabilmente è solo una questione di TLS 1.0 come predefinito perché era la versione TLS più utilizzata al momento del rilascio di Server 2008 R2 (luglio 2009).
Non sei sicuro di come lo sapresti per certo, o scopri "perché" è stata presa una decisione di progettazione, ma dato che Windows 7 e Server 2008 R2 hanno introdotto la funzionalità nella famiglia Windows e Windows Server 2012 utilizza TLS 1.2 per impostazione predefinita, esso sembrerebbe suggerire che si trattasse di "il modo in cui le cose venivano fatte" in quel momento. TLS 1.0 era ancora "abbastanza buono", quindi era l'impostazione predefinita, ma TLS 1.1 e 1.2 erano supportati per il supporto in avanti e l'operatività in avanti.
Questo blog tecnico di un dipendente Microsoft consiglia di abilitare le versioni più recenti di TLS e osserva inoltre che (a partire da ottobre 2011):
Tra i server Web di nuovo, IIS 7.5 è l'unico che supporta TLS 1.1 e TLS 1.2. Al momento Apache non supporta questi protocolli in quanto OPENSSL non include il supporto per essi. Speriamo che raggiungano i nuovi standard del settore.
Ciò supporta ulteriormente l'idea che le versioni TLS più recenti non erano abilitate per impostazione predefinita in Server 2008 R2 per la semplice ragione che erano più recenti e non ampiamente supportate o utilizzate al momento - Apache e OpenSSL non le supportavano ancora, figuriamoci usali come predefiniti.
I dettagli su come abilitare e disabilitare le varie versioni SSL / TLS sono disponibili nell'articoloHow to restrict the use of certain cryptographic algorithms and protocols in Schannel.dll della Microsoft KB numero 245030, intitolato . Ovviamente, le Clientchiavi controllano Internet Explorer e le Serverchiavi coprono IIS.
Me lo stavo chiedendo da solo ... forse solo a causa di problemi di compatibilità noti al momento ... Ho trovato questo post sul blog MSDN (dal 24 marzo 2011):
Parla di alcuni server Web che si "comportano male" nel modo in cui rispondono a richieste di protocollo non supportate, il che ha fatto sì che il client non ricadesse su un protocollo supportato, con il risultato finale che gli utenti non potevano accedere ai siti Web.
Citando una parte di quel post di blog qui:
Il server non dovrebbe comportarsi in questo modo, ma dovrebbe invece semplicemente rispondere utilizzando l'ultima versione del protocollo HTTPS che supporta (ad es. "3.1" aka TLS 1.0). A questo punto, se il server avesse chiuso la connessione con garbo a questo punto, va bene-- il codice in WinINET eseguirà il fallback e ritenterà la connessione offrendo solo TLS 1.0. WinINET include un codice tale da TLS1.1 e 1.2 fallback a TLS1.0, quindi fallback su SSL3 (se abilitato) quindi SSL2 (se abilitato). l'aspetto negativo del fallback è rappresentato dalle prestazioni: i round trip extra richiesti per la nuova stretta di mano con versione inferiore comporteranno generalmente una penalità pari a decine o centinaia di millisecondi.
Tuttavia, questo server ha utilizzato un RST TCP / IP per interrompere la connessione, che disabilita il codice di fallback in WinINET e provoca l'abbandono dell'intera sequenza di connessione, lasciando all'utente il messaggio di errore "Internet Explorer non può visualizzare la pagina Web".