Antworten:
Server 2008 R2 / Windows 7 führte die TLS 1.1- und TLS 1.2-Unterstützung für Windows ein und wurde vor den Angriffen veröffentlicht, die TLS 1.0 anfällig machten. Daher ist TLS 1.0 wahrscheinlich nur die Standardversion, da es die am häufigsten verwendete TLS-Version war Zum Zeitpunkt der Veröffentlichung von Server 2008 R2 (Juli 2009).
Sie sind sich nicht sicher, woher Sie das wissen oder warum Sie eine Entwurfsentscheidung getroffen haben. Angesichts der Tatsache, dass Windows 7 und Server 2008 R2 die Funktion in die Windows-Produktfamilie eingeführt haben und Windows Server 2012 standardmäßig TLS 1.2 verwendet, ist dies jedoch der Fall Anscheinend war es eine Frage der damaligen "Art und Weise, wie die Dinge gemacht wurden". TLS 1.0 war immer noch "gut genug", daher war es die Standardeinstellung, aber TLS 1.1 und 1.2 wurden aus Gründen der Vorwärtsunterstützung und der Vorwärtsoperabilität unterstützt.
In diesem Technet-Blog eines Microsoft-Mitarbeiters wird empfohlen, die neueren TLS-Versionen zu aktivieren, und es wird Folgendes angegeben (Stand: Oktober 2011):
Unter den Webservern ist IIS 7.5 der einzige, der TLS 1.1 und TLS 1.2 unterstützt. Derzeit unterstützt Apache diese Protokolle nicht, da OPENSSL sie nicht unterstützt. Hoffentlich werden sie die neuen Standards der Branche einholen.
Dies stützt auch die Idee, dass neuere TLS-Versionen in Server 2008 R2 nicht standardmäßig aktiviert wurden, weil sie neuer waren und zu diesem Zeitpunkt nicht allgemein unterstützt oder verwendet wurden - Apache und OpenSSL haben sie noch nicht einmal unterstützt , geschweige denn benutze sie als Standard.
Ausführliche InformationenHow to restrict the use of certain cryptographic algorithms and protocols in Schannel.dll zum Aktivieren und Deaktivieren der verschiedenen SSL / TLS-Versionen finden Sie in der Microsoft KB-Artikelnummer 245030 mit dem Titel . Offensichtlich Clientsteuern die Schlüssel den Internet Explorer und die ServerSchlüssel decken IIS ab.
Ich habe mich das selbst gefragt ... vielleicht nur aufgrund bekannter Kompatibilitätsprobleme zu der Zeit ... Ich fand diesen MSDN-Blogeintrag (vom 24.03.2011):
Einige Webserver reagieren auf nicht unterstützte Protokollanforderungen "schlecht", was dazu führte, dass der Client nicht auf ein unterstütztes Protokoll zurückgriff. Das Endergebnis war, dass Benutzer nicht auf die Website (n) zugreifen konnten.
Zitiere einen Teil dieses Blogeintrags hier:
Der Server sollte sich nicht so verhalten. Stattdessen wird erwartet, dass er einfach mit der neuesten unterstützten HTTPS-Protokollversion antwortet (z. B. "3.1" oder TLS 1.0). Wenn der Server die Verbindung zu diesem Zeitpunkt ordnungsgemäß geschlossen hätte, würde dies der Fall sein In Ordnung sein - Code in WinINET würde auf TLS 1.0 zurückgreifen und die Verbindung erneut versuchen. WinINET enthält Code, bei dem TLS 1.1 und 1.2 auf TLS 1.0 zurückgreifen, dann auf SSL3 (falls aktiviert) und dann auf SSL2 (falls aktiviert) Nachteil des Rückfalls ist die Leistung - die zusätzlichen Roundtrips, die für den neuen Handshake mit niedrigerer Version erforderlich sind, führen normalerweise zu einer Zeitstrafe in Höhe von zehn oder hundert Millisekunden.
Dieser Server hat jedoch eine TCP / IP-RST zum Abbrechen der Verbindung verwendet, wodurch der Fallback-Code in WinINET deaktiviert wird und die gesamte Verbindungssequenz abgebrochen wird, sodass der Benutzer die Fehlermeldung "Internet Explorer kann die Webseite nicht anzeigen" erhält.