Odpowiedzi:
Server 2008 R2 / Windows 7 wprowadził obsługę TLS 1.1 i TLS 1.2 dla Windows i został wydany przed atakami, które spowodowały podatność TLS 1.0, więc prawdopodobnie jest to tylko kwestia domyślnego ustawienia TLS 1.0, ponieważ była to najczęściej używana wersja TLS w momencie wydania Server 2008 R2 (lipiec 2009).
Nie jestem pewien, skąd na pewno wiesz, ani nie dowiesz się „dlaczego” podjęto decyzję projektową, ale biorąc pod uwagę, że Windows 7 i Server 2008 R2 wprowadziły tę funkcję do rodziny Windows, a Windows Server 2012 domyślnie używa TLS 1.2, to sugeruje, że w tamtym czasie była to kwestia „sposobu, w jaki rzeczy zostały zrobione”. Protokół TLS 1.0 był nadal „wystarczająco dobry”, więc był domyślny, ale TLS 1.1 i 1.2 były obsługiwane w celu obsługi i przesyłania dalej.
Ten blog technet od pracownika Microsoft zaleca włączenie nowszych wersji TLS, a także zauważa, że (od października 2011 r.):
Spośród serwerów internetowych IIS 7.5 jest jedynym, który obsługuje TLS 1.1 i TLS 1.2. Na razie Apache nie obsługuje tych protokołów, ponieważ OPENSSL nie obejmuje ich obsługi. Mamy nadzieję, że nadążą za nowymi standardami branżowymi.
To dodatkowo wspiera ideę, że nowsze wersje TLS nie były domyślnie włączone w Server 2008 R2 z tego prostego powodu, że były nowsze i nie były powszechnie obsługiwane lub używane w tym czasie - Apache i OpenSSL nawet ich nie obsługiwały , nie mówiąc już użyj ich jako domyślnych.
Szczegółowe informacje na temat dokładnego włączania i wyłączania różnych wersji SSL / TLS można znaleźć w artykule Microsoft KB o numerze 245030, zatytułowanymHow to restrict the use of certain cryptographic algorithms and protocols in Schannel.dll . Oczywiście Clientklucze kontrolują Internet Explorera, a Serverklucze obejmują IIS.
Zastanawiałem się nad tym sam ... może właśnie ze względu na znane problemy ze zgodnością w tym czasie ... Znalazłem ten wpis na blogu MSDN (z 24 marca 2011):
Mówi o tym, że niektóre serwery internetowe „źle zachowują się” w sposobie, w jaki odpowiadają na nieobsługiwane żądania protokołu, co spowodowało, że klient nie powrócił do obsługiwanego protokołu, w wyniku czego użytkownicy nie mogli uzyskać dostępu do stron internetowych.
Cytując tutaj część tego wpisu na blogu:
Serwer nie powinien zachowywać się w ten sposób - zamiast tego powinien po prostu odpowiedzieć przy użyciu najnowszej obsługiwanej wersji protokołu HTTPS (np. „3.1”, inaczej TLS 1.0). Gdyby serwer w tym momencie z wdziękiem zamknął połączenie, bądź w porządku - kod w WinINET spowodowałby awarię i ponowiłby połączenie oferujące tylko TLS 1.0 WinINET zawiera kod taki, że TLS1.1 i 1.2 zastępują TLS1.0, następnie powrót do SSL3 (jeśli jest włączony), a następnie SSL2 (jeśli jest włączony). Minusem spadku jest wydajność - dodatkowe obchody wymagane dla nowego uścisku dłoni o niższej wersji zwykle skutkują karą w wysokości dziesiątek lub setek milisekund.
Jednak ten serwer użył protokołu RST protokołu TCP / IP do przerwania połączenia, co wyłącza kod rezerwowy w programie WinINET i powoduje porzucenie całej sekwencji połączeń, pozostawiając użytkownikowi komunikat o błędzie „Internet Explorer nie może wyświetlić strony internetowej”.