Zum Hauptinhalt springen

1. Introduction (Einführung)

Das Hauptziel des TLS-Protokolls ist es, Vertraulichkeit und Datenintegrität zwischen zwei kommunizierenden Anwendungen zu gewährleisten. Das Protokoll besteht aus zwei Schichten: dem TLS-Datensatzprotokoll (TLS Record Protocol) und dem TLS-Handshake-Protokoll (TLS Handshake Protocol). Auf der untersten Ebene, aufgesetzt auf ein zuverlässiges Transportprotokoll (z.B. TCP [TCP]), befindet sich das TLS-Datensatzprotokoll. Das TLS-Datensatzprotokoll bietet Verbindungssicherheit mit zwei grundlegenden Eigenschaften:

  • Die Verbindung ist privat. Symmetrische Kryptographie wird für die Datenverschlüsselung verwendet (z.B. AES [AES], RC4 [SCH]). Die Schlüssel für diese symmetrische Verschlüsselung werden für jede Verbindung eindeutig generiert und basieren auf einem Geheimnis, das von einem anderen Protokoll (wie dem TLS-Handshake-Protokoll) ausgehandelt wird. Das Datensatzprotokoll kann auch ohne Verschlüsselung verwendet werden.

  • Die Verbindung ist zuverlässig. Der Nachrichtentransport beinhaltet eine Nachrichtenintegritätsprüfung mittels eines schlüsselbasierten MAC. Sichere Hash-Funktionen (z.B. SHA-1 usw.) werden für MAC-Berechnungen verwendet. Das Datensatzprotokoll kann ohne MAC arbeiten, wird aber in der Regel nur in diesem Modus verwendet, während ein anderes Protokoll das Datensatzprotokoll als Transport zur Aushandlung von Sicherheitsparametern nutzt.

Das TLS-Datensatzprotokoll wird verwendet, um verschiedene Protokolle höherer Ebenen zu kapseln. Eines dieser gekapselten Protokolle, das TLS-Handshake-Protokoll, ermöglicht es dem Server und dem Client, sich gegenseitig zu authentifizieren und einen Verschlüsselungsalgorithmus sowie kryptographische Schlüssel auszuhandeln, bevor das Anwendungsprotokoll sein erstes Datenbyte überträgt oder empfängt. Das TLS-Handshake-Protokoll bietet Verbindungssicherheit mit drei grundlegenden Eigenschaften:

  • Die Identität des Peers kann mittels asymmetrischer oder Public-Key-Kryptographie authentifiziert werden (z.B. RSA [RSA], DSA [DSS]). Diese Authentifizierung kann optional gemacht werden, ist aber im Allgemeinen für mindestens einen der Peers erforderlich.

  • Die Aushandlung eines gemeinsamen Geheimnisses ist sicher: Das ausgehandelte Geheimnis ist für Lauscher nicht verfügbar, und für jede authentifizierte Verbindung kann das Geheimnis nicht erlangt werden, selbst wenn ein Angreifer sich in die Mitte der Verbindung platzieren kann.

  • Die Aushandlung ist zuverlässig: Kein Angreifer kann die Aushandlungskommunikation ändern, ohne von den Kommunikationsparteien entdeckt zu werden.

Ein Vorteil von TLS ist, dass es anwendungsprotokollunabhängig ist. Protokolle höherer Ebenen können transparent über das TLS-Protokoll geschichtet werden. Der TLS-Standard spezifiziert jedoch nicht, wie Protokolle mit TLS Sicherheit hinzufügen; die Entscheidungen darüber, wie der TLS-Handshake eingeleitet wird und wie die ausgetauschten Authentifizierungszertifikate interpretiert werden, bleiben dem Urteil der Designer und Implementierer von Protokollen überlassen, die auf TLS aufsetzen.

1.1. Requirements Terminology (Anforderungsterminologie)​

Die Schlüsselwörter „MUST" (muss), „MUST NOT" (darf nicht), „REQUIRED" (erforderlich), „SHALL" (muss), „SHALL NOT" (darf nicht), „SHOULD" (sollte), „SHOULD NOT" (sollte nicht), „RECOMMENDED" (empfohlen), „MAY" (kann) und „OPTIONAL" (optional) in diesem Dokument sind wie in RFC 2119 [REQ] beschrieben zu interpretieren.

1.2. Major Differences from TLS 1.1 (Hauptunterschiede zu TLS 1.1)​

Dieses Dokument ist eine Überarbeitung des TLS 1.1 [TLS1.1] Protokolls, die verbesserte Flexibilität enthält, insbesondere für die Aushandlung kryptographischer Algorithmen. Die Hauptänderungen sind:

  • Die MD5/SHA-1-Kombination in der Pseudozufallsfunktion (PRF) wurde durch cipher-suite-spezifische PRFs ersetzt. Alle Cipher Suites in diesem Dokument verwenden P_SHA256.

  • Die MD5/SHA-1-Kombination im digital signierten Element wurde durch einen einzelnen Hash ersetzt. Signierte Elemente enthalten nun ein Feld, das den verwendeten Hash-Algorithmus explizit spezifiziert.

  • Wesentliche Bereinigung der Fähigkeit des Clients und Servers, anzugeben, welche Hash- und Signaturalgorithmen sie akzeptieren werden. Beachten Sie, dass dies auch einige der Einschränkungen für Signatur- und Hash-Algorithmen aus früheren TLS-Versionen lockert.

  • Hinzufügung der Unterstützung für authentifizierte Verschlüsselungsmodi mit zusätzlichen Daten (authenticated encryption with additional data modes).

  • TLS-Erweiterungsdefinitionen und AES-Cipher-Suites wurden aus externen Quellen [TLSEXT] und [TLSAES] eingearbeitet.

  • Strengere Überprüfung der EncryptedPreMasterSecret-Versionsnummern.

  • Verschärfung einer Reihe von Anforderungen.

  • Die Länge von verify_data hängt nun von der Cipher Suite ab (Standardwert ist immer noch 12).

  • Bereinigte Beschreibung der Bleichenbacher/Klima-Angriffsabwehr.

  • Warnmeldungen (Alerts) müssen nun in vielen Fällen gesendet werden.

  • Nach einem certificate_request müssen Clients nun eine leere Zertifikatsliste senden, wenn keine Zertifikate verfügbar sind.

  • TLS_RSA_WITH_AES_128_CBC_SHA ist nun die obligatorisch zu implementierende Cipher Suite.

  • HMAC-SHA256-Cipher-Suites wurden hinzugefügt.

  • IDEA- und DES-Cipher-Suites wurden entfernt. Sie sind nun veraltet und werden in einem separaten Dokument dokumentiert.

  • Die Unterstützung für das SSLv2-rückwärtskompatible Hello ist nun ein MAY (kann), nicht ein SHOULD (sollte), und es zu senden ist ein SHOULD NOT (sollte nicht). Die Unterstützung wird wahrscheinlich in Zukunft zu einem SHOULD NOT (sollte nicht) werden.

  • Begrenzte "Fall-through"-Funktionalität wurde zur Präsentationssprache hinzugefügt, um mehreren Case-Zweigen die gleiche Kodierung zu ermöglichen.

  • Ein Abschnitt über Implementierungsfallen (Implementation Pitfalls) wurde hinzugefügt.

  • Die üblichen Klarstellungen und redaktionellen Arbeiten.

Letztes Update am