TLS-Protokoll (Transport Layer Security)
In diesem Thema für IT-Fachleute wird beschrieben, wie das TLS-Protokoll (Transport Layer Security) funktioniert und Links zu den IETF-RFCs für TLS 1.0, TLS 1.1 und TLS 1.2 bereitstellt.
Hinweis
In einer zukünftigen Version von Windows Server wird TLS 1.0 und 1.1 standardmäßig deaktiviert. Weitere Informationen finden Sie unter TLS-Version 1.0- und 1.1-Deaktivierungsressourcen.
Die TLS-Protokolle (und auch die SSL-Protokolle) befinden sich zwischen der Anwendungsprotokollschicht und der TCP/IP-Schicht, wo sie Anwendungsdaten schützen und an die Transportschicht senden können. Da die Protokolle zwischen der Anwendungsschicht und der Transportschicht angesiedelt sind, können TLS und SSL mehrere Anwendungsschichtprotokolle unterstützen.
Bei TLS und SSL wird davon ausgegangen, dass eine verbindungsorientierte Transportmethode – in der Regel TCP – verwendet wird. Das Protokoll ermöglicht Client- und Serveranwendungen, die folgenden Sicherheitsrisiken zu erkennen:
Manipulation von Nachrichten
Abfangen von Nachrichten
Fälschung von Nachrichten
Die TLS- und SSL-Protokolle können in zwei Schichten unterteilt werden. Die erste Schicht besteht aus dem Anwendungsprotokoll und den drei Handshakingprotokollen: dem Handshakeprotokoll, dem Protokoll für die Änderung der Verschlüsselungsspezifikation und dem Warnungsprotokoll. Die zweite Schicht ist das Datensatzprotokoll.
TLS- und SSL-Protokollschichten
Der Schannel-SSP implementiert die TLS- und SSL-Protokolle ohne Änderung. Das SSL-Protokoll ist proprietär, aber die Internet Engineering Task Force erstellt die öffentlichen TLS-Spezifikationen. Informationen dazu, welche TLS- oder SSL-Version in Windows-Versionen unterstützt wird, finden Sie unter Protokolle in TLS/SSL (Schannel-SSP). Jede Spezifikation enthält Informationen zu:
TLS-Datensatzprotokoll
TLS-Handshakingprotokolle: Protokoll für die Änderung der Verschlüsselungsspezifikation und Warnungsprotokoll
Kryptografische Berechnungen
Obligatorische Suites mit Verschlüsselungsverfahren
Anwendungsdatenprotokoll
RFC 5246 – The Transport Layer Security (TLS) Protocol Version 1.2
RFC 4346 - Die Transport Layer Security-Protokollversion (TLS) 1.1
RFC 2246 – Die TLS-Protokollversion 1.0
TLS-Sitzungswiederaufnahme
Der Schannel-SSP wurde in Windows Server 2012 R2 eingeführt und implementiert den serverseitigen Teil der Wiederaufnahme einer TLS-Sitzung. Die Implementierung der clientseitigen RFC 5077 wurde in Windows 8 hinzugefügt.
Geräte, die TLS-Verbindungen mit Servern herstellen, müssen die Verbindung häufig wiederherstellen. Die Wiederaufnahme einer TLS-Sitzung reduziert die Kosten für die Herstellung von TLS-Verbindungen, da ein abgekürzter TLS-Handshake verwendet wird. Dies ermöglicht eine größere Anzahl von Wiederaufnahmeversuchen, indem zugelassen wird, dass eine Gruppe von TLS-Servern die TLS-Sitzungen der jeweils anderen Server wiederaufnehmen kann. Diese Änderung bietet die folgenden Einsparmöglichkeiten für jeden TLS-Client, der RFC 5077 unterstützt, einschließlich Windows Phone- und Windows RT-Geräten:
Reduzierter Ressourcenbedarf auf dem Server
Reduzierte Bandbreite und damit verbesserte Effizienz von Clientverbindungen
Geringerer Zeitaufwand für den TLS-Handshake durch Wiederaufnahme der Verbindung
Informationen zur statusfreien TLS-Sitzungswiederaufnahme finden Sie im IETF-Dokument RFC 5077.
Anwendungsprotokollverhandlung
In Windows Server 2012 R2 und Windows 8.1 wurde eine Unterstützung eingeführt, die eine clientseitige Aushandlung von TLS-Anwendungsprotokollen ermöglicht. Anwendungen können Protokolle im Rahmen der HTTP 2.0-Standardentwicklung nutzen, und Benutzer*innen können mithilfe von Apps, in denen das SPDY-Protokoll ausgeführt wird, auf Onlinedienste wie Google und Twitter zugreifen.
Informationen zur Funktionsweise der Anwendungsprotokollverhandlung finden Sie unter Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension.
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 Abbilder auf einem einzelnen Server ausgeführt werden. In virtuellen Hostszenarien werden mehrere Domänen (die jeweils über ein eigenes Zertifikat verfügen) auf einem Server gehostet. In diesem Fall kann der Server nicht im Voraus wissen, welches Zertifikat er an den Client senden muss. Dank SNI kann der Client die Zieldomäne zu einem früheren Zeitpunkt im Protokoll informieren, damit der Server das richtige Zertifikat auswählen kann.
Dies bietet die folgende zusätzliche Funktionalität:
Sie können mehrere SSL-Websites mit einer einzigen Kombination aus Internetprotokoll und Port hosten.
Der Speicherbedarf wird reduziert, wenn mehrere SSL-Websites auf einem einzelnen Webserver gehostet werden.
Eine größere Anzahl Benutzer*innen kann gleichzeitig eine Verbindung zu SSL-Websites herstellen.