Відповіді:
Сервер 2008 R2 / Windows 7 представив підтримку TLS 1.1 і TLS 1.2 для Windows, і був випущений до атак, які зробили TLS 1.0 вразливим, тому, мабуть, просто TLS 1.0 був типовим, тому що це найбільш широко використовувана версія TLS на момент виходу Server 2008 R2 (липень 2009 р.)
Не впевнений, як ви точно знаєте, або дізнайтеся "чому" рішення дизайну, але враховуючи, що Windows 7 та Server 2008 R2 ввели цю функцію в сім'ю Windows, а Windows Server 2012 використовує TLS 1.2 за замовчуванням, це Здавалося б, припускають, що це було питанням "того, як робилося все". TLS 1.0 все ще був "досить хорошим", тому він був за замовчуванням, але TLS 1.1 і 1.2 підтримувались для підтримки вперед та функціонування вперед.
Цей блог із технологій від співробітника Microsoft рекомендує включити новіші версії TLS, а також зазначає, що (станом на жовтень 2011 року):
Серед веб-серверів знову ж таки, IIS 7.5 є єдиним, який підтримує TLS 1.1 та TLS 1.2. На сьогодні Apache не підтримує ці протоколи, оскільки OPENSSL не підтримує їх. Сподіваємось, вони дотягнуть до галузей нові стандарти.
Це додатково підтримує думку про те, що нові версії TLS не були включені за замовчуванням у сервері 2008 R2 з тієї простої причини, що вони були новішими і не широко підтримувалися або використовувалися в той час - Apache і OpenSSL навіть не підтримували їх ще, не кажучи вже про використовувати їх за замовчуванням.
Детально про те, як увімкнути та вимкнути різні версії SSL / TLS, можна знайти в статті статті Microsoft KB 245030 під назвоюHow to restrict the use of certain cryptographic algorithms and protocols in Schannel.dll . Очевидно, що Clientключі керують Internet Explorer, а Serverклавіші охоплюють IIS.
Мені це було цікаво ... можливо, саме через відомі на той час проблеми сумісності ... Я знайшов цю запис у блозі MSDN (з 24 березня 2011 р.):
У ньому йдеться про те, що деякі веб-сервери «погано поводяться» у тому, як вони реагують на непідтримувані запити протоколу, через що клієнт не повертається до підтримуваного протоколу, в кінцевому результаті - користувачі не мають доступу до веб-сайтів.
Цитуючи частину цього запису в блозі тут:
Сервер не повинен вести себе таким чином - натомість очікується, що він просто відповість, використовуючи останню версію протоколу HTTPS, яку він підтримує (наприклад, "3.1" aka TLS 1.0). Якби сервер витончено закрив з'єднання в цей момент, це було б буде добре - код у WinINET буде резервним і повторює повторне з'єднання, пропонуючи лише TLS 1.0. WinINET включає код, такий, що TLS1.1 та 1.2 резервного копіювання до TLS1.0, потім резервний запас до SSL3 (якщо він включений), а потім SSL2 (якщо він включений). Недоліком резервного ефекту є продуктивність - додаткові зворотні переїзди, необхідні для нового рукостискання з нижчою версією, зазвичай призводять до штрафу в розмірі десятків або сотень мілісекунд.
Однак цей сервер використовував TCP / IP RST для припинення з'єднання, що вимикає резервний код у WinINET і приводить до відмови всієї послідовності з'єднань, залишаючи користувачу повідомлення про помилку "Internet Explorer не може відображати веб-сторінку".