Markieren Sie das Kontrollkästchen Englisch, um die englische Version dieses Artikels anzuzeigen. Sie können den englischen Text auch in einem Popup-Fenster einblenden, indem Sie den Mauszeiger über den Text bewegen.
Übersetzung
Englisch

Neues in TLS/SSL (Schannel SSP)

 

Betrifft: Windows 8.1, Windows Server 2012 R2, Windows Server 2012, Windows 8

In diesem Thema für IT-Experten werden die Änderungen an der Funktionalität im Schannel Security Support Provider (SSP) beschrieben. Hierzu gehören TLS (Transport Layer Security), SSL (Secure Sockets Layer) und die DTLS-Authentifizierungsprotokolle (Datagram Transport Layer Security) für Windows Server 2012 R2, Windows Server 2012, Windows 8.1 und Windows 8.

Schannel ist ein Security Support Provider (SSP), der die standardmäßigen Internetauthentifizierungsprotokolle SSL, TLS und DTLS implementiert. Die Security Support Provider-Schnittstelle (Security Support Provider Interface, SSPI) ist eine API, die von Windows-Systemen verwendet wird, um sicherheitsbezogene Funktionen wie Authentifizierungen durchzuführen. Die SSPI dienst als gemeinsame Schnittstelle für mehrere SSPs (Security Support Providers), einschließlich des Schannel SSP.

Weitere Informationen zur Microsoft-Implementierung von TLS und SSL im Schannel SSP finden Sie in TLS/SSL Technical Reference (2003).

Inhalte dieses Themas:

Im Folgenden wird beschrieben, welche Änderungen an TLS im Schannel SSP vorgenommen wurden.

Das Transport Layer Security (TLS)-Protokoll, eine Komponente von Schannel-Security Support Provider, wird verwendet, um Daten zu schützen, die zwischen Programmen in einem nicht vertrauenswürdigen Netzwerk gesendet werden. Mit TLS/SSL können Server und Clientcomputer authentifiziert werden, und mit dem Protokoll können Nachrichten zwischen den authentifizierten Parteien verschlüsselt werden.

Geräte, die häufig eine TSL-Verbindung mit Servern aufbauen, müssen sich bei Ablauf einer Sitzung jeweils neu verbinden.Windows 8.1 und Windows Server 2012 R2 unterstützen jetzt RFC 5077 (Wiederaufnahme der TLS-Sitzung ohne serverseitigen Zustand). Diese Änderung bewirkt bei Windows Phone- und Windows RT-Geräten folgende Vorteile:

  • Reduzierter Ressourcenbedarf auf dem Server

  • Reduzierte Bandbreite und damit verbesserte Effizienz von Clientverbindungen

  • Geringere Dauer des TLS-Handshakes durch Wiederaufnahme der Verbindung

System_CAPS_noteHinweis

Die Implementierung der clientseitigen RFC 5077 wurde in Windows 8 hinzugefügt.

Informationen über die zustandslose Wiederaufnahme einer TLS-Sitzung finden Sie im IETF-Dokument RFC 5077.

Windows Server 2012 R2 und Windows 8.1 unterstützen die clientseitige Aushandlung des TLS-Anwendungsprotokolls, damit Anwendungen Protokolle aus dem noch in Entwicklung befindlichen HTTP 2.0-Standard nutzen können, um Benutzern den Zugriff auf Onlinedienste wie Google und Twitter mithilfe von Apps zu ermöglichen, die das SPDY-Protokoll ausführen.

Funktionsweise

Client- und Serveranwendungen aktivieren die Erweiterung zum Aushandeln des Anwendungsprotokolls durch das Bereitstellen von Listen unterstützter Anwendungsprotokoll-IDs in absteigender bevorzugter Reihenfolge. Der TLS-Client gibt an, dass er das Aushandeln des Anwendungsprotokolls unterstützt, indem er die ALPN-Erweiterung (Application Layer Protocol Negotiation) mit einer Liste clientseitig unterstützter Protokolle in der ClientHello-Nachricht mit einschließt.

Beim Empfang der TLS-Anfrage des Clients durch den Server wertet dieser die Liste unterstützter Protokolle aus, um ein bevorzugtes Protokoll zu finden, das auch der Client unterstützt. Wenn ein solches Protokoll gefunden wird, antwortet der Server mit der ausgewählten Protokoll-ID und führt den Handshake wie gewohnt fort. Ist kein gemeinsames Anwendungsprotokoll vorhanden, sendet der Server eine Meldung über einen kritischen Handshake-Fehler.

Wenn die Authentifizierung des Clientcomputers über SSL oder TLS erforderlich ist, kann der Server so konfiguriert werden, dass eine Liste vertrauenswürdiger Zertifikataussteller gesendet wird. Diese Liste enthält die Gruppe der Zertifikataussteller, denen der Server vertraut, und hilft dem Clientcomputer bei der Auswahl des Clientzertifikats, falls mehrere Zertifikate vorhanden sind. Darüber hinaus muss die Zertifikatkette, die der Clientcomputer an den Server sendet, anhand der Liste der konfigurierten vertrauenswürdigen Aussteller überprüft werden.

Vor Windows Server 2012 und Windows 8 konnten Anwendungen oder Prozesse, die das Schannel SSP (einschließlich HTTP.sys und IIS) verwendeten, eine Zertifikatvertrauensliste (CTL) der von ihnen für die Clientauthentifizierung verwendeten vertrauenswürdigen Herausgeber bereitstellen.

In Windows Server 2012 und Windows 8 wurden folgende Änderungen am zugrunde liegenden Authentifizierungsprozess vorgenommen:

  • Eine CTL-basierte Verwaltung der Liste vertrauenswürdiger Aussteller wird nicht mehr unterstützt.

  • Das Verhalten, die Liste vertrauenswürdiger Aussteller zu senden, ist standardmäßig deaktiviert: Der Standardwert des Registrierungsschlüssels SendTrustedIssuerList ist jetzt 0 (deaktiviert) anstatt 1.

  • Die Kompatibilität mit früheren Versionen von Windows-Betriebssystemen wurde gewahrt.

Welchen Nutzen bietet diese Änderung?

Ab Windows Server 2012 wurde die Verwendung der CTL durch eine Implementierung auf Basis des Zertifikatspeichers ersetzt. Dies ermöglicht eine vertrautere Verwaltung mithilfe der vorhandenen Cmdlets zur Zertifikatverwaltung des PowerShell-Anbieters und von Befehlszeilentools wie „certutil.exe“.

Obwohl die maximale Größe der Liste der von Schannel SPP unterstützten vertrauenswürdigen Zertifizierungsstellen (16 KB) gegenüber Windows Server 2008 R2 gleich geblieben ist, gibt es in Windows Server 2012 einen neuen, dedizierten Zertifikatspeicher für Clientauthentifizierungsaussteller, sodass die Nachricht keine nicht zugehörigen Zertifikate enthält.

Worin bestehen die Unterschiede?

In Windows Server 2012 wird die Liste vertrauenswürdiger Aussteller mithilfe von Zertifikatspeichern konfiguriert, einem standardmäßigen globalen Computerzertifikatspeicher und einem optional vorhandenen sitespezifischen Zertifikatspeicher. Die Quelle der Liste wird wie folgt bestimmt:

  • Wenn ein bestimmter Anmeldeinformationsspeicher für diese Site konfiguriert ist, wird dieser als Quelle verwendet.

  • Wenn keine Zertifikate in dem von der Anwendung definierten Speicher vorhanden sind, prüft Schannel den Speicher Clientauthentifizierungsaussteller auf dem lokalen Computer und verwendet diesen Speicher als Quelle, wenn Zertifikate vorhanden sind. Wenn in keinem der Speicher ein Zertifikat gefunden wird, wird der Speicher für vertrauenswürdige Stämme überprüft.

  • Wenn weder die globale noch die lokalen Speicher Zertifikate enthalten, verwendet der Schannel-Anbieter den Speicher Vertrauenswürdige Stammzertifizierungsstellen als Quelle der Liste vertrauenswürdiger Aussteller. (Beschreibt das Verhalten für Windows Server 2008 R2.)

Wenn der Speicher Vertrauenswürdige Stammzertifizierungsstellen verwendet wurde und eine Mischung aus (selbstsignierten) Zertifikaten von Rootausstellern und Zertifikaten von Zertifizierungsstellen enthält, werden standardmäßig nur die Zertifikate von Zertifizierungsstellen an den Server gesendet.

Konfigurieren von Schannel zur Verwendung des Zertifikatspeichers für vertrauenswürdige Aussteller

Bei der Schannel-SSP-Architektur in Windows Server 2012 wird standardmäßig der oben beschriebene Speicher zur Verwaltung der Liste vertrauenswürdiger Aussteller verwendet. Es können weiterhin die vorhandenen Cmdlets des PowerShell-Anbieters und von Befehlszeilentools wie „Certutil“ für die Zertifikatverwaltung verwendet werden.

Informationen zum Verwalten von Zertifikaten mithilfe des PowerShell-Anbieters finden Sie unter AD CS Administration Cmdlets in Windows.

Informationen zum Verwalten von Zertifikaten mithilfe des Zertifikatdienstprogramms finden Sie unter certutil.exe.

Informationen dazu, welche Daten einschließlich des anwendungsdefinierten Speichers als Anmeldeinformationen für Schannel definiert sind, finden Sie unter SCHANNEL_CRED structure (Windows).

Standardeinstellungen für Vertrauensstellungsmodi

Es gibt drei Vertrauensstellungsmodi für die Clientauthentifizierung durch den Schannel-Anbieter. Der Vertrauensstellungsmodus steuert, wie die Überprüfung der Zertifikatkette des Clients ausgeführt wird, und ist eine systemweite Einstellung, die durch den REG_DWORD-Wert „ClientAuthTrustMode“ unter „HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel“ konfiguriert wird.

Wert

Vertrauensstellungsmodus

Beschreibung

0

Maschinenvertrauensstellung (Standard)

Erfordert, dass das Clientzertifikat von einem Zertifikat in der Liste der vertrauenswürdigen Aussteller ausgestellt wurde.

1

Exklusive Stammvertrauensstellung

Erfordert, dass das Clientzertifikat in der Zertifikatkette auf ein Stammzertifikat zurückgeht, das in dem durch den Aufrufer festgelegten Speicher für vertrauenswürdige Aussteller enthalten ist. Das Zertifikat muss auch von einem Herausgeber in der Liste der vertrauenswürdigen Aussteller ausgestellt worden sein.

2

Exklusive Zertifizierungsstellen-Vertrauensstellung

Erfordert, dass das Clientzertifikat in der Zertifikatkette auf ein dazwischenliegendes Zertifizierungsstellenzertifikat oder ein Stammzertifikat zurückgeht, das in dem durch den Aufrufer festgelegten Speicher für vertrauenswürdige Aussteller enthalten ist.

Informationen zu Authentifizierungsfehlern aufgrund von Konfigurationsproblemen vertrauenswürdiger Aussteller finden Sie im Knowledge Base-Artikel 280256.

Das SNI-Feature stellt eine Erweiterung der Protokolle SSL und TLS dar und ermöglicht die richtige Identifizierung des Servers, wenn zahlreiche virtuelle Images auf einem einzelnen Server ausgeführt werden. Um die Sicherheit der Kommunikation zwischen einem Clientcomputer und einem Server herzustellen, fordert der Clientcomputer ein digitales Zertifikat beim Server an. Nachdem der Server auf die Anforderung geantwortet und das Zertifikat gesendet hat, prüft der Clientcomputer es, verwendet es zur Verschlüsselung der Kommunikation und fährt mit dem normalen Austausch von Anforderungen und Antworten fort. Bei virtuellen Hostszenarios werden jedoch mehrere Domänen, von denen jede über ein eigenes Zertifikat verfügt, auf einem Server gehostet. In diesem Fall kann der Server nicht im Voraus wissen, welches Zertifikat er an den Clientcomputer senden muss. Dank SNI kann der Clientcomputer die Zieldomäne zu einem früheren Zeitpunkt im Protokoll informieren, damit der Server das richtige Zertifikat auswählen kann.

Welchen Nutzen bietet diese Änderung?

Die folgende zusätzliche Funktionalität:

  • Sie können mehrere SSL-Websites mit einer einzelnen IP- und Portkombination hosten.

  • Der Speicherbedarf wird reduziert, wenn mehrere SSL-Websites auf einem einzelnen Webserver gehostet werden.

  • Mehr Benutzer können gleichzeitig die Verbindung zu SSL-Websites herstellen.

  • Sie können Endbenutzern über die Benutzeroberfläche des Computers Hinweise zur Auswahl des richtigen Zertifikats während eines Clientauthentifizierungsprozesses geben.

Worin bestehen die Unterschiede?

Schannel SSP unterhält einen speicherinternen Cache der Clientverbindungsstatus, die für Clients zulässig sind. Dadurch erhalten Clientcomputer die Möglichkeit, die Verbindung mit dem SSL-Server bei Folgeaufrufen schnell wieder aufzubauen, ohne einen vollständigen SSL-Handshake durchführen zu müssen. Durch effiziente Verwendung der Zertifikatverwaltung können im Vergleich zu vorherigen Betriebssystemversionen mehr Websites auf einem einzelnen Computer unter Windows Server 2012 gehostet werden.

Die Zertifikatauswahl durch den Endbenutzer wurde verbessert, indem Ihnen die Möglichkeit gegeben wird, eine Liste der Namen möglicher Zertifikataussteller zu erstellen, die Endbenutzern Anhaltspunkte bei der Auswahl liefert. Diese Liste kann mit einer Gruppenrichtlinie konfiguriert werden.

Das DTLS-Protokoll in der Version 1.0 wurde Schannel Security Support Provider hinzugefügt. Das DTLS-Protokoll sorgt bei der Kommunikation mit Datagrammprotokollen für Datenschutz. Das Protokoll ermöglicht es Client/Server-Anwendungen, so zu kommunizieren, dass Lauschangriffe, Manipulationen oder Nachrichtenfälschung vermieden werden. Das DTLS-Protokoll basiert auf dem TLS-Protokoll (Transport Layer Security) und bietet gleichwertige Sicherheitsgarantien. Daher wird die Notwendigkeit der Verwendung von IPsec oder der Erstellung eines benutzerdefinierten Sicherheitsprotokolls für die Anwendungsschicht verringert.

Welchen Nutzen bietet diese Änderung?

Datagramme werden häufig beim Medienstreaming eingesetzt, beispielsweise bei Spielen oder sicheren Videokonferenzen. Indem Sie das DTLS-Protokoll dem Schannel-Provider hinzufügen, können Sie das gewohnte Windows SSPI-Modell zur Sicherung der Kommunikation zwischen Clientcomputern und -servern nutzen. Zum Konzept von DTLS gehört es, TLS so ähnlich wie möglich zu sein, um einerseits weitere Sicherheitsvorkehrungen zu minimieren und andererseits den Umfang der Code- und Infrastrukturwiederverwendung zu maximieren.

Worin bestehen die Unterschiede?

Anwendungen, die DTLS über UDP nutzen, können das SSPI-Modell in Windows Server 2012 und Windows 8 verwenden. Bestimmte Verschlüsselungssammlungen sind für die Konfiguration verfügbar, die der Konfiguration von TLS ähnelt. Schannel nutzt weiterhin den CNG-Kryptografieanbieter, der die in Windows Vista eingeführte FIPS 140-Zertifizierung nutzt.

Im Schannel SSP für Windows Server 2012 und Windows 8 gibt es keine veralteten Features oder Funktionen.

Anzeigen: