Übersicht über TLS/SSL (Schannel SSP)
Gilt für: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows 10
In diesem Thema für IT-Spezialisten 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 der technischen Referenz zu TLS/SSL (2003).
Funktionen von TLS/SSL (Schannel SSP)
Im Folgenden werden die Funktionen von TLS im Schannel-SSP beschrieben.
TLS-Sitzungswiederaufnahme
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
Hinweis
Die Implementierung der clientseitigen RFC 5077 wurde in Windows 8 hinzugefügt.
Informationen zur statusfreien TLS-Sitzungswiederaufnahme finden Sie im IETF-Dokument RFC 5077.
Anwendungsprotokollverhandlung
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.
So funktioniert's
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.
Verwaltung vertrauenswürdiger Aussteller für die Clientauthentifizierung
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 R2 und Windows 8.1 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 R2 und Windows 8.1 wurden folgende Änderungen am zugrunde liegenden Authentifizierungsprozess vorgenommen:
Eine CTL-basierte Verwaltung der Liste vertrauenswürdiger Aussteller wird nicht mehr unterstützt.
Das standardmäßige Senden der Liste vertrauenswürdiger Aussteller ist deaktiviert: Der Standardwert des SendTrustedIssuerList-Registrierungsschlüssels ist jetzt 0 (standardmäßig deaktiviert) statt 1.
Die Kompatibilität mit früheren Versionen von Windows-Betriebssystemen wurde gewahrt.
Hinweis
Wenn System Mapper von der Clientanwendung aktiviert wird und Sie SendTrustedIssuers konfiguriert haben, wird dieser System Mapper CN=NT Authority zur Ausstellerliste hinzufügen.
Welchen Nutzen bietet dies?
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 SSP 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.
Funktionsweise
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. (Dies ist 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.
TLS-Unterstützung für SNI-Erweiterungen (Server Name Indicator, Servernamensanzeige)
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 Hostszenarien 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 dies?
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.
So funktioniert's
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.
Datagram Transport Layer Security (DTLS)
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 dies?
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.
So funktioniert's
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.
Veraltete Funktionen
Im Schannel SSP für Windows Server 2012 und Windows 8 gibt es keine veralteten Features oder Funktionen.