Transport Layer Security TLS (1.0 bis 1.3)

© Copyright Shutterstock / Profit_Image

Was ist TLS (1.0 bis 1.3)?

Ziel

Das Protokoll von Transport Layer Security soll in erster Linie die Privatsphäre und Datenintegrität zwischen zwei oder mehr kommunizierenden Computeranwendungen bereitstellen. Liegt solche eine Sicherung durch vor, besitzt die Verbindung zwischen einem Client (z. B. einem Webbrowser) und einem Server folgende Eigenschaften:

Sichere Verbindung

Die Verbindung ist privat (bzw. gesichert), da zur Verschlüsselung der übertragenen Daten eine symmetrische Kryptografie verwendet wird. Die Schlüssel für diese symmetrische Verschlüsselung werden für jede Verbindung eindeutig generiert und basieren auf einem “gemeinsamen Geheimnis” (Shared Secret), das zu Beginn der Sitzung ausgehandelt wurde.

Der Server und der Client verhandeln die Details, welcher Verschlüsselungsalgorithmus und welche kryptografischen Schlüssel verwendet werden sollen, bevor das erste Byte der Daten übertragen wird.

Die Aushandlung eines gemeinsamen Geheimnisses ist sowohl sicher (das ausgehandelte Geheimnis ist für Lauscher nicht zugänglich und kann nicht erreicht werden, auch nicht von einem Angreifer, der sich in der Mitte der Verbindung befindet) als auch zuverlässig (kein Angreifer kann die Kommunikation während der Aushandlung ändern, ohne entdeckt zu werden).

Die Identität der kommunizierenden Parteien

Die Identität der kommunizierenden Parteien kann mithilfe der Public-Key-Kryptographie authentifiziert werden. Diese Authentifizierung kann optimal erfolgen, ist aber im Allgemeinen für mindestens einen der Beteiligten (typischerweise den Server) erforderlich. Die Verbindung ist zuverlässig, da jede übertragende Nachricht eine Nachrichtenintegrität beinhaltet.

Zuverlässige Verbindung

Die Verbindung ist zuverlässig, da jede übertragende Nachricht eine Überprüfung der Nachrichtenintegrität unter Verwendung eines Nachrichten-Authentifizierungs-Codes beinhaltet, um unentdeckten Verlust oder Änderung der Daten während der Übertragung zu verhindern.

Zusätzlich zu den drei genannten Eigenschaften kann eine sorgfältige Konfiguration von Transport Layer Security weitere datenschutzbezogene Eigenschaften bieten, wie z. B. die Geheimhaltungspflicht, sodass sichergestellt ist, dass eine zukünftige Offenlegung von Schlüsseln nicht zur Entschlüsselung von in der Vergangenheit aufgezeichneten TSL-Kommunikationen verwendet werden kann.

Transport Layer Security unterstützt viele verschiedene Methoden zum Austausch von Schlüsseln, zur Verschlüsselung von Daten und zur Authentifizierung der Nachrichtenintegrität. Infolgedessen beinhaltet die sichere Konfiguration von TLS viele konfigurierbare Parameter – aber nicht alle Optionen bieten alle in der obigen Liste beschriebenen datenschutzrelevante Eigenschaften.

Es wurden Versuche unternommen, Aspekte der Kommunikationssicherheit, die TLS bieten soll, zu untergraben und das Protokoll wurde daher mehrmals überarbeitet, um diese Sicherheitsbedrohungen zu beheben. Entwickler von Webbrowsern haben auch ihre Produkte überarbeitet, um mögliche Sicherheitslücken zu beseitigen.

Beschreibung

Das Transport Layer Security-Protokoll besteht aus zwei Layer: dem TLS-Record und Datenflusssicherungs-Protokoll. TLS ist ein vorgeschlagener Standard der Internet Engineering Task Force (IETF), der 1999 erstmals definiert und in RFC 5246 und RFC 6176 aktualisiert wurde. Es baut auf den früheren SSL-Spezifikationen auf, die von Netscape Communications entwickelt wurden, um das HTTPS-Protokoll zu ihrem Navigator-Webbrowser hinzuzufügen.

Client-Server-Anwendungen verwenden das Transport Layer Security-Protokoll, um über ein Netzwerk auf eine Weise zu kommunizieren, die das Abhören und Manipulieren verhindert. Da Anwendungen entweder mit oder ohne TLS kommunizieren können, ist es notwendig, dass der Client dem Server den Aufbau einer TLS-Verbindung mitteilt.

Eine der wichtigen Möglichkeiten, dies zu erreichen, ist die Verwendung einer anderen Portnummer für TLS-Verbindungen, beispielsweise Port 443 für HTTPS. Ein weiterer Mechanismus besteht darin, dass der Client eine protokollspezifische Anforderung an den Server richtet, um die Verbindung zu TLS umzustellen, z. B. durch eine sog. STARTTLS-Anfrage bei Verwendung des E-Mail- und News-Protokolls.

Nachdem sich der Client und der Server bereit erklärt haben, Transport Layer Security zu verwenden, verhandeln sie ein zustandsbehaftete Verbindung mithilfe eines Datenflusssteuerung-Verfahrens (“Handshake”).

Die Protokolle verwenden diese mit asymmetrischer Verschlüsselung, um nicht nur Verschlüsselungseinstellungen, sondern auch einen sitzungsspezifischen gemeinsamen Schlüssel festzulegen, mit dem die weitere Kommunikation mit einer symmetrischen Verschlüsselung verschlüsselt wird. Während dieses Handshakes vereinbaren Client und Server verschiedene Parameter, mit denen die Sicherheit der Verbindung hergestellt wird.

Die Datenflusssteuerung beginnt, wenn sich ein Client mit einem Transport Layer Security-fähigen Server verbindet, der eine sichere Verbindung anfordert und der Client eine Liste der unterstützenden Verschlüsselungssuiten (Verschlüsselungen und Hash-Funktionen) präsentiert. Aus dieser Liste wählt der Server eine Verschlüsselungs- und Hash-Funktion aus, die er ebenfalls unterstützt und dem Client die Entscheidung mitteilt.

In der Regel stellt der Server dann die Identifikation in Form eines digitalen Zertifikats zur Verfügung. Das Zertifikat enthält den Servernamen, die vertrauenswürdige Zertifizierungsstelle (CA), die für die Authentizität des Zertifikats bürgt und den öffentlichen Schlüssel des Servers.

Der Kunde bestätigt die Gültigkeit des Zertifikats, bevor er fortfahren kann.

Entwicklung

Transport Layer Security 1.0

Diese Version wurde erstmals im Januar 1999 in RFC 2246 als Upgrade der SSL-Version 3.0 definiert und von Christopher Allen und Tim Dierks von Consensus Development geschrieben. Wie im RFC erwähnt, “sind die Unterschiede zwischen diesem Protokoll und SSL 3.0 nicht dramatisch, aber sie sind signifikant genug, um die Interoperabilität zwischen TLS 1.0 und SSL 3.0 auszuschließen”. TLS 1.0 beinhaltet ein Mittel, mit dem eine TLS-Implementierung die Verbindung auf SSL 3.0 herabstufen und damit die Sicherheit schwächen kann.

Transport Layer Security 1.1

Das Upgrade wurde im April 2006 in RFC 4346 definiert, ein Upgrade der Version 1.0. Zu den wesentlichen Unterschieden in dieser Version gehören der zusätzliche Schutz gegen Cipher-Block-Chaining (CBC-)Angriffe. Der implizierte Initialisierungsvektor (IV) wurde durch einen expliziten IV ersetzt. Des Weiteren wurden Änderungen in der Behandlung von Padding-Fehlern behoben.

Transport Layer Security 1.2

Version 1.2 wurde im August 2008 in RFC 5246 definiert. Es basiert auf den Spezifikationen der Vorgänger-Version. Zu den Änderungen gehören:

• Die MD5-SHA-1-Kombination in der Pseudozufallsfunktion (PRF) wurde durch SHA-256 ersetzt, mit der Option, bestimmte PRFs der Cipher Suite zu verwenden.
• Die MD5-SHA-1-Kombination im fertigen Nachrichtenhash wurde durch SHA-256 ersetzt, mit der Option, spezifische Hash-Algorithmen der Chiffriersuite zu verwenden. Die Größe des Hash in der fertigen Nachricht muss jedoch noch mindestens 96 Bit betragen.
• Die MD5-SHA-1-Kombination im digital signierten Element wurde durch einen einzigen Hash ersetzt, der während der Datenflusssteuerung ausgehandelt wurde und standardmäßig SHA-1 lautet.
• Verbesserung der Fähigkeit des Clients und Servers, festzulegen, welche Hashes und Signaturalgorithmen er akzeptiert.
• Erweiterung der Unterstützung für authentifizierte Verschlüsselungschiffren, die hauptsächlich für Galois/Counter Mode (GCM) und CCM-Modus der Advanced Encryption Standard (AES) Verschlüsselung verwendet werden.
• TLS Extensions Definition und AES-Chriffe-Suiten wurden hinzugefügt.

Alle TLS-Versionen wurden im März 2011 in RFC 6176 weiterentwickelt und ihre Abwärtskompatibilität mit SSL aufgehoben, sodass TLS-Sitzungen nie über die Verwendung von SSL Version 2.0 verhandeln.

Transport Layer Security 1.3

TLS 1.3 wurde im August 2018 in RFC 8446 definiert. Es basiert auf der Spezifikation der Version 1.2. Die wesentlichen Top-Unterschiede:

• Trennung von Schlüsselvereinbarungen und Authentifizierungsalgorithmen von den Verschlüsselungssuiten.
• Entfernen der Unterstützung für schwache und weniger verwendete benannte elliptische Kurven.
• Entfernen der Unterstützung für MD5 und SHA-224 kryptografische Hash-Funktionen.
• Erfordern digitaler Signaturen, auch wenn eine frühere Konfiguration verwendet wird.
• Integration von HKDF und dem semi-ephemeren DH-Vorschlag.
• Ersetzen der Wiederaufnahme durch PSK und Tickets.
• Unterstützung von 1-RTT Datenflusssteuerungen und Erstunterstützung für 0-RTTT.
• Vollständige Geheimhaltung durch die Verwendung von ephemeren Schlüsseln.