TLS Protokoll: Unterschied zwischen den Versionen

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
 
(22 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 2: Zeile 2:
 
= Funktionsweise =
 
= Funktionsweise =
 
*Client baut eine Verbindung zum Server auf.  
 
*Client baut eine Verbindung zum Server auf.  
−
*Server authentifiziert sich gegenüber dem Client mit einem [[Digitales Zertifikat|Zertifikat]]
+
*Server authentifiziert sich gegenüber dem Client mit einem Zertifikat
 
*Client überprüft hierbei die Vertrauenswürdigkeit X.509-Zertifikats und ob der Servername mit dem Zertifikat übereinstimmt.
 
*Client überprüft hierbei die Vertrauenswürdigkeit X.509-Zertifikats und ob der Servername mit dem Zertifikat übereinstimmt.
 
*Optional kann sich der Client mit einem eigenen Zertifikat auch gegenüber dem Server authentifizieren.
 
*Optional kann sich der Client mit einem eigenen Zertifikat auch gegenüber dem Server authentifizieren.
Zeile 30: Zeile 30:
 
|}
 
|}
  
−
=== TLS Record Protocol ===
+
== TLS Record Protocol ==
 +
*TLS Record Protocol ist die untere der beiden Schichten und dient zur Absicherung der Verbindung.
 +
*setzt direkt auf der Transportschicht auf und bietet zwei verschiedene Dienste
 +
*Diese können einzeln oder gemeinsam genutzt werden
 +
===Ende-zu-Ende-Verschlüsselung===
 +
*mittels Symmetrisches Kryptosystem
 +
*verwendeteR Schlüssel wird dabei im Voraus über ein weiteres Protokoll (zum Beispiel das TLS Handshake Protocol) ausgehandelt
 +
*kann nur einmal für die jeweilige Verbindung verwendet werden.
 +
*Es wird symmetrische Verschlüsselung unterstützt (DES, 3DES und AES)
 +
===Sicherung der Integrität und Authentizität===
 +
*durch einen Message Authentication Codein der Regel HMAC
 +
==Aufbau einer TLS-Record-Nachrich==
 +
*1 Byte:  Change Cipher Spec = 20 Alert = 21, Handshake = 22, Application Data = 23
 +
*1 Byte:  Protokollversion Major
 +
*1 Byte:  Protokollversion Minor
 +
*2 Byte:  Länge
  
−
Das TLS Record Protocol ist die untere der beiden Schichten und dient zur Absicherung der Verbindung. Es setzt direkt auf der Transportschicht auf und bietet zwei verschiedene Dienste, die einzeln oder gemeinsam genutzt werden können:
+
= TLS Handshake Protocol =
−
* [[Ende-zu-Ende-Verschlüsselung]] mittels [[Symmetrisches Kryptosystem|symmetrischer Algorithmen]]. Der verwendete Schlüssel wird dabei im Voraus über ein weiteres Protokoll (zum Beispiel das TLS Handshake Protocol) ausgehandelt und kann nur einmal für die jeweilige Verbindung verwendet werden. TLS unterstützt für die [[symmetrische Verschlüsselung]] unter anderem [[Data Encryption Standard|DES]], [[Triple DES]] und [[Advanced Encryption Standard|AES]]
 
−
* Sicherung der [[Integrität (Informationssicherheit)|Nachrichten-Integrität]] und [[Authentizität]] durch einen [[Message Authentication Code]], in der Regel [[Keyed-Hash Message Authentication Code|HMAC]].
 
  
−
Außerdem werden zu sichernde Daten in Blöcke von maximal 16.384 (2<sup>14</sup>) Byte fragmentiert und beim Empfänger wieder zusammengesetzt. Dabei schreibt der Standard vor, dass die Blockgröße diesen Wert nicht übersteigt, außer der Block ist komprimiert oder verschlüsselt – dann darf die Blockgröße um 1024 Byte (bei Kompression) bzw. 2048 Byte (bei Verschlüsselung) größer sein. Auch können die Daten vor dem Verschlüsseln und vor dem Berechnen der kryptografischen Prüfsumme komprimiert werden. Das Komprimierungsverfahren wird ebenso wie die kryptografischen Schlüssel mit dem TLS Handshake-Protokoll ausgehandelt.
+
[[Datei:tls-31.png|1400px]]
  
−
Der Aufbau einer TLS-Record-Nachricht lautet wie folgt: ''Content Type'' (1 Byte: ''Change Cipher Spec'' = 20, ''Alert'' = 21, ''Handshake'' = 22, ''Application Data'' = 23) | ''Protokollversion Major'' (1 Byte) | ''Protokollversion Minor'' (1 Byte) | ''Länge'' (1 Short bzw. zwei Byte)
+
*Baut auf dem TLS Record Protocol auf und erfüllt die folgenden Funktionen
 +
*Aushandeln zu benutzender kryptografischer Algorithmen und Schlüssel.
 +
*Identifikation und Authentifizierung der Kommunikationspartner
 +
*Basis sind Asymmetrischer Verschlüsselungsverfahren und Public-Key-Infrastruktur
 +
*Server authentifiziert sich gegenüber dem Client
 +
*Optional authentifiziert sich auch der Client gegenüber dem Server
 +
==Handshake selbst kann in vier Phasen unterteilt werden==
 +
*Client schickt zum Server ein ClientHello, und der Server antwortet dem Client mit einem ServerHello. Die Parameter der Nachrichten sind:
 +
** die höchste vom Client unterstützte TLS-Protokoll-Version
 +
** eine 32 Byte lange Zufallsinformation wird später verwendet pre-master-secret, zum Schutz vor Replay-Attackenm  zu bilden
 +
** eine Session-ID
 +
** die zu verwendende Cipher Suite (Algorithmen für Schlüsselaustausch, Verschlüsselung und Authentifizierung)
 +
** Optional den gewünschten FQDN für die Unterstützung von Server Name Indication
 +
** in der TLS 1.3 Version (mit Diffie-Hellman-Schlüsselaustausch) werden die Key-Shares übertragen, die den gemeinsamen Schlüssel definieren.
 +
*Der Server identifiziert sich gegenüber dem Client.
 +
**Hierzu wird per Certificate'' ein Zertifikat an den Client geschickt, gefolgt von einem CertificateVerify
 +
**CertificateVerify'' Nachricht enthält eine Unterschrift von zuvor ausgetauschten Nachrichten.
 +
**Server beweist, dass er einen Secret-Key besitzt, der zu dem auf dem Server-Zertifikat enthaltenen passt.
 +
**Client prüft das Zertifikat und die Unterschrift. Bei Misserfolg bricht der Client die Verbindung ab.
 +
*Das zuvor erhaltene Server-Zertifikat enthält den öffentlichen Schlüssel des Servers
 +
**Wird eine Cipher Suite mit RSA-Schlüsselaustausch verwendet
 +
***so wird das vom Client generierte pre-master-secret mit diesem öffentlichen Schlüssel verschlüsselt
 +
****und kann vom Server mit dem nur ihm bekannten privaten Schlüssel wieder entschlüsselt werden.
 +
**Alternativ kann hier auch der Diffie-Hellman-Schlüsselaustausch verwendet werden
 +
***dann wird ein gemeinsames pre-master-secret zu generieren.
 +
***Wenn Diffie-Hellman-Geheimnisse von Server und Client während des Handshakes frisch und zufällig ausgehandelt
 +
***sind die Voraussetzungen für Perfect Forward Secrecy erfüllt.
 +
*Diese Phase schließt den Handshake ab.
 +
**Aus dem vorhandenen pre-master-secret kann das master secret abgeleitet werden
 +
**ein einmaligen Sitzungsschlüssel
 +
**Aus dem master secret werden wiederum Schlüssel abgeleitet
 +
**zum Ver- und Entschlüsseln der Daten sowie für die Integritätsprüfung verwendet werden.
 +
**Nachrichten, die die Kommunikationspartner sich nun gegenseitig zusenden sind verschlüsselt übertragen
  
−
=== TLS Handshake Protocol ===
+
= TLS Change Cipher Spec Protocol =
 +
*Das Change Cipher Spec Protocol besteht nur aus einer einzigen Nachricht.
 +
*Diese Nachricht ist ein Byte groß und besitzt den Inhalt 1.
 +
*Durch diese Nachricht teilt der Sender dem Empfänger mit, dass er in der aktiven Sitzung auf die im Handshake Protocol ausgehandelte Cipher Suite wechselt.
 +
*Protokoll wurde gewählt weil man expliziert keine Record Übertragung wollte.
  
−
[[Datei:SSL handshake with two way authentication with certificates.svg|mini|TLS-Handshake mit Zwei-Wege-Authentifizierung mittels Zertifikaten und RSA-Schlüsselaustausch]]
+
= TLS Alert Protocol =
−
 
+
*unterscheidet etwa zwei Dutzend verschiedene Mitteilungen.  
−
Das TLS Handshake Protocol baut auf dem TLS Record Protocol auf und erfüllt die folgenden Funktionen, noch bevor die ersten Bits des Anwendungsdatenstromes ausgetauscht wurden:
+
*Eine davon teilt das Ende der Sitzung mit (close_notify).  
−
* Aushandeln zu benutzender kryptografischer Algorithmen und Schlüssel. TLS unterstützt auch eine unverschlüsselte Übertragung.
+
*Andere beziehen sich zum Beispiel auf die Protokollsyntax oder die Gültigkeit der verwendeten Zertifikate.  
−
* Identifikation und Authentifizierung der Kommunikationspartner auf Basis [[Asymmetrisches Kryptosystem|asymmetrischer Verschlüsselungsverfahren]] und [[Public-Key-Infrastruktur|Public-Key-Kryptografie]]. Dieser Schritt ist optional eine Zwei-Wege-Authentifizierung (in diesem Fall wird manchmal von ''mutual TLS'' gesprochen), für gewöhnlich authentifiziert sich aber nur der [[Server]] gegenüber dem [[Client]].
+
*Es wird zwischen Warnungen und Fehlern unterschieden, wobei letztere die Verbindung sofort beenden.
−
 
 
−
Der Handshake selbst kann in vier ''Phasen'' unterteilt werden:
 
−
# Der Client schickt zum Server ein C''lientHello'', und der Server antwortet dem Client mit einem S''erverHello''. Die Parameter der Nachrichten sind:
 
−
#* die Version (die höchste vom Client unterstützte TLS-Protokoll-Version)
 
−
#* eine 32 Byte lange Zufallsinformation (4 Byte Timestamp + 28 Byte lange Zufallszahl), die später verwendet wird, um das ''pre-master-secret'' zu bilden (sie schützt damit vor [[Replay-Attacke]]n)
 
−
#* eine Session-ID
 
−
#* die zu verwendende [[Cipher Suite]] (Algorithmen für Schlüsselaustausch, Verschlüsselung und Authentifizierung)
 
−
#* Optional den gewünschten [[Fully Qualified Domain Name|FQDN]] für die Unterstützung von [[Server Name Indication]]
 
−
#* in der TLS 1.3 Version (mit [[Diffie-Hellman-Schlüsselaustausch]]) werden hier auch schon die Key-Shares übertragen, die den gemeinsamen Schlüssel definieren.
 
−
# Der Server identifiziert sich gegenüber dem Client. Hierzu wird per C''ertificate'' ein [[X.509]]v3-[[Digitales Zertifikat|Zertifikat]]  an den Client geschickt, gefolgt von einem ''CertificateVerify'' (in einigen TLS Versionen). Die C''ertificateVerify'' Nachricht enthält eine Unterschrift von zuvor ausgetauschten Nachrichten. Damit beweist der Server, dass er einen [[Asymmetrische Verschlüsselung|Secret-Key]] besitzt, der zu dem auf dem Server-Zertifikat enthaltenen [[Public-Key-Kryptografie|Public-Key]] passt. Der Client prüft das Zertifikat und die Unterschrift. Bei Misserfolg bricht der Client die Verbindung ab. Außerdem kann der Server optional per ''CertificateRequest'' ein Zertifikat zur Client-Authentifizierung anfordern. Diese Phase darf nur weggelassen werden, wenn eine anonyme Cipher Suite ohne Authentifizierung verwendet wird.
 
−
# Das zuvor erhaltene Server-Zertifikat enthält den [[Asymmetrisches Kryptosystem|öffentlichen Schlüssel]] des Servers. Wird eine [[Cipher Suite]] mit [[RSA-Kryptosystem|RSA]]-Schlüsselaustausch verwendet (siehe Abbildung), so wird das vom Client generierte ''pre-master-secret'' mit diesem öffentlichen Schlüssel verschlüsselt und kann vom Server mit dem nur ihm bekannten privaten Schlüssel wieder entschlüsselt werden. Alternativ kann hier auch der [[Diffie-Hellman-Schlüsselaustausch]] verwendet werden, um ein gemeinsames ''pre-master-secret'' zu generieren. Werden die Diffie-Hellman-Geheimnisse von Server und Client während des Handshakes frisch und zufällig ausgehandelt, sind die Voraussetzungen für [[Perfect Forward Secrecy]] erfüllt. Nach der Übertragung des ''pre-master-secrets''  identifiziert sich der Client mittels Zertifikat gegenüber dem Server, sofern dieser einen ''CertificateRequest'' geschickt hat. Dazu schickt der Client per ''Certificate'' das Client-Zertifikat, gefolgt von einem ''CertificateVerify.'' Die ''CertificateVerify'' Nachricht enthält eine Unterschrift aller zuvor ausgetauschten Nachrichten. Damit beweist der Client gegenüber dem Server, dass er einen Secret-Key besitzt, der zu dem auf dem Client-Zertifikat enthaltenen Public-Key passt. Ab hier ist dem Server also bekannt, mit wem er kommuniziert.
 
−
# Diese Phase schließt den Handshake ab. Aus dem vorhandenen ''pre-master-secret'' kann das ''master secret'' abgeleitet werden, das einen einmaligen [[Sitzungsschlüssel]] ({{enS|session key}}) darstellt. Aus dem ''master secret'' werden wiederum Schlüssel abgeleitet, die zum Ver- und Entschlüsseln der Daten sowie für die Integritätsprüfung verwendet werden. Die Nachrichten, die die Kommunikationspartner sich nun gegenseitig zusenden, werden nur noch verschlüsselt übertragen. Falls sich der Server nicht im Schritt 2 via ''CertificateVerify'' authentisiert hat, ist dem Client erst nach dem Erhalt der ersten verschlüsselten Nachricht bekannt, dass er mit dem rechtmäßigen Besitzer des Zertifikats kommuniziert.
 
−
 
 
−
=== TLS Change Cipher Spec Protocol ===
 
−
 
 
−
Das Change Cipher Spec Protocol besteht nur aus einer einzigen Nachricht. Diese Nachricht ist ein Byte groß und besitzt den Inhalt 1. Durch diese Nachricht teilt der Sender dem Empfänger mit, dass er in der aktiven Sitzung auf die im Handshake Protocol ausgehandelte [[Cipher Suite]] wechselt.
 
−
Ein wesentlicher Grund für die Definition eines eigenen Protokolls für diese Nachricht besteht darin, dass TLS-Implementierungen mehrere Nachrichten eines Protokolls in einem Record (also einer TLS-Dateneinheit) zusammenfassen können. Für die Nachricht „Change Cipher Spec“ ist das unerwünscht. Weil Records verschiedener Protokolle nicht zusammengefasst werden dürfen, ist das Problem durch Definition eines eigenen Protokolls gelöst.<ref>Joshua Davies: ''Implementing SSL / TLS Using Cryptography and PKI.'' John Wiley and Sons, Indianapolis 2011, S. 344.</ref>
 
−
 
 
−
=== TLS Alert Protocol ===
 
−
 
 
−
Das ''Alert Protocol'' unterscheidet etwa zwei Dutzend verschiedene Mitteilungen. Eine davon teilt das Ende der Sitzung mit (close_notify). Andere beziehen sich zum Beispiel auf die Protokollsyntax oder die Gültigkeit der verwendeten Zertifikate. Es wird zwischen Warnungen und Fehlern unterschieden, wobei letztere die Verbindung sofort beenden.
 
  
 
Der Aufbau einer Fehlermeldung lautet wie folgt: ''AlertLevel'' (1 Byte: ''Warning'' = 1, ''Fatal'' = 2) | ''AlertDescription'' (1 Byte: ''close_notify'' = 0, […], ''no_renegotiation'' = 100).
 
Der Aufbau einer Fehlermeldung lautet wie folgt: ''AlertLevel'' (1 Byte: ''Warning'' = 1, ''Fatal'' = 2) | ''AlertDescription'' (1 Byte: ''close_notify'' = 0, […], ''no_renegotiation'' = 100).
Zeile 133: Zeile 161:
 
|}
 
|}
  
−
=== TLS Application Data Protocol ===
+
= TLS Application Data Protocol =
−
 
+
*Die Anwendungsdaten werden über das Record Protocol
−
Die Anwendungsdaten werden über das Record Protocol transportiert, in Teile zerlegt, komprimiert und in Abhängigkeit vom aktuellen Zustand der Sitzung auch verschlüsselt. Inhaltlich werden sie von TLS nicht näher interpretiert.
+
*transportiert
 +
*in Teile zerlegt
 +
*komprimiert
 +
*in Abhängigkeit vom aktuellen Zustand der Sitzung auch verschlüsselt.
 +
*Inhaltlich werden sie von TLS nicht näher interpretiert.
  
 
=== Berechnung des Master Secrets ===
 
=== Berechnung des Master Secrets ===
 +
*TLS 1.2 mit Hilfe einer durch eine Cipher Suite spezifizierten Pseudozufallsfunktion das Master Secretberechnet.
 +
*In diese Berechnung fließen zusätzlich die Zufallszahlen der Phase 1 des Handshakes mit ein.
 +
*Die Verwendung beider Hash-Funktionen sollte sicherstellen, dass das ''Master Secret'' immer noch geschützt ist, falls eine der Funktionen als kompromittiert gilt.
 +
*In TLS 1.2 wird dieser Ansatz durch die flexible Austauschbarkeit der Funktion ersetzt.
  
−
Aus dem ''pre-master-secret'' wird in früheren Protokollversionen mit Hilfe der [[Hashfunktion]]en [[SHA-1]] und [[MD5]], in TLS 1.2 mit Hilfe einer durch eine ''Cipher Suite'' spezifizierten Pseudozufallsfunktion das ''Master Secret'' berechnet. In diese Berechnung fließen zusätzlich die Zufallszahlen der Phase 1 des Handshakes mit ein. Die Verwendung beider Hash-Funktionen sollte sicherstellen, dass das ''Master Secret'' immer noch geschützt ist, falls eine der Funktionen als kompromittiert gilt. In TLS 1.2 wird dieser Ansatz durch die flexible Austauschbarkeit der Funktion ersetzt.
+
=Quelle=
−
 
+
*https://de.wikipedia.org/wiki/Transport_Layer_Security
−
== Sicherheit ==
 
−
 
 
−
Auf SSL und TLS sind jeweils eine Reihe von Angriffen bekannt, die die Sicherheitsgarantien untergraben.<ref name="RFC7457" /> Die folgende Liste stellt einen Teil der bekannten Angriffe dar.
 
−
 
 
−
=== Padding-Oracle-Angriffe ===
 
−
 
 
−
Der Kryptologe [[Serge Vaudenay]] entdeckte 2002, dass ein [[Man-in-the-Middle-Angriff|Man-in-the-Middle-Angreifer]] aus dem [[Padding (Informatik)|Padding]] einer mit dem [[Cipher Block Chaining Mode]] (CBC) verschlüsselten Nachricht Informationen erhalten kann, die zur Entschlüsselung der Nachricht genutzt werden können. Durch gezielte Manipulation einer verschlüsselten Nachricht lernt der Angreifer, ob der Server ein gültiges Padding meldet und damit ein Teil des Klartexts richtig erraten wurde.<ref name="Vaudenay2002" />
 
−
 
 
−
Als Schutzmaßnahme sollte der Server ungültige Nachrichten verwerfen, ohne dabei zu offenbaren, ob das Padding oder die Nachrichtenauthentizität ungültig war. Allerdings kann ein Angreifer diese Information auch durch eine Analyse der Antwortzeiten herleiten (Timing-Angriff). Betroffen sind SSL, TLS bis Version 1.2 und DTLS, sofern eine [[Cipher Suite]] mit CBC verwendet wird. Cipher Suites mit [[Authenticated Encryption]] sind nicht betroffen.<ref name="AlFardan2013" />
 
−
 
 
−
Im Oktober 2014 demonstrierten Sicherheitsforscher den [[Poodle|POODLE-Angriff]] (''Padding Oracle On Downgraded Legacy Encryption''), mit dem ein Angreifer ein Versions-Downgrade einer TLS-Verbindung erzwingt, um einen Padding-Oracle-Angriff gegen SSL 3.0 durchzuführen. Zwecks Kompatibilität wurde SSL 3.0 trotz zu dem Zeitpunkt bekannter Sicherheitsschwächen noch von Webbrowsern und anderen Implementierungen unterstützt. Im Nachgang hat die [[Internet Engineering Task Force]] SSL 3.0 als überholt gekennzeichnet<ref name="RFC7568" /> und ein Verfahren zum Schutz vor Downgrade-Angriffen auf TLS spezifiziert.<ref name="RFC7507" />
 

Aktuelle Version vom 13. Juli 2021, 18:37 Uhr

Funktionsweise

  • Client baut eine Verbindung zum Server auf.
  • Server authentifiziert sich gegenüber dem Client mit einem Zertifikat
  • Client überprüft hierbei die Vertrauenswürdigkeit X.509-Zertifikats und ob der Servername mit dem Zertifikat übereinstimmt.
  • Optional kann sich der Client mit einem eigenen Zertifikat auch gegenüber dem Server authentifizieren.
  • Dann schickt entweder der Client dem Server eine mit dem öffentlichen Schlüssel des Servers verschlüsselte geheime Zufallszahl
  • Oder die beiden Parteien berechnen mit dem Diffie-Hellman-Schlüsselaustausch ein gemeinsames Geheimnis.
  • Aus dem Geheimnis wird dann ein kryptographischer Schlüssel abgeleitet.
  • Dieser Schlüssel wird in der Folge benutzt, um alle Nachrichten der Verbindung mit einem Symmetrisches Verschlüsselungsverfahren verschlüsseln
  • Schutz von Integrität und Authentizität durch einen Message Authentication Code gewährleistet.

TLS-Protokolle im Protokollstapel

  • Im OSI-Modell in Schicht 5 angeordnet.
  • Im TCP/IP-Modell ist TLS oberhalb der Transportschichtund unterhalb Anwendungsprotokollen angeordnet
  • Spezifikationen wird dies dann zum Beispiel als „HTTP over TLS“ bezeichnet. S
  • beide Protokolle zusammengefasst betrachtet werden, wird üblicherweise ein „S“ für Secure angehängt
  • TLS arbeitet transparent, so dass es leicht eingesetzt werden kann
  • Beispielsweise mit STUNNEL

Aufbau

Das TLS-Protokoll besteht aus zwei Schichten:

TLS Handshake Protocol TLS Change Cipher Spec. Protocol TLS Alert Protocol TLS Application Data Protocol
TLS Record Protocol

TLS Record Protocol

  • TLS Record Protocol ist die untere der beiden Schichten und dient zur Absicherung der Verbindung.
  • setzt direkt auf der Transportschicht auf und bietet zwei verschiedene Dienste
  • Diese können einzeln oder gemeinsam genutzt werden

Ende-zu-Ende-Verschlüsselung

  • mittels Symmetrisches Kryptosystem
  • verwendeteR Schlüssel wird dabei im Voraus über ein weiteres Protokoll (zum Beispiel das TLS Handshake Protocol) ausgehandelt
  • kann nur einmal für die jeweilige Verbindung verwendet werden.
  • Es wird symmetrische Verschlüsselung unterstützt (DES, 3DES und AES)

Sicherung der Integrität und Authentizität

  • durch einen Message Authentication Codein der Regel HMAC

Aufbau einer TLS-Record-Nachrich

  • 1 Byte: Change Cipher Spec = 20 Alert = 21, Handshake = 22, Application Data = 23
  • 1 Byte: Protokollversion Major
  • 1 Byte: Protokollversion Minor
  • 2 Byte: Länge

TLS Handshake Protocol

Tls-31.png

  • Baut auf dem TLS Record Protocol auf und erfüllt die folgenden Funktionen
  • Aushandeln zu benutzender kryptografischer Algorithmen und Schlüssel.
  • Identifikation und Authentifizierung der Kommunikationspartner
  • Basis sind Asymmetrischer Verschlüsselungsverfahren und Public-Key-Infrastruktur
  • Server authentifiziert sich gegenüber dem Client
  • Optional authentifiziert sich auch der Client gegenüber dem Server

Handshake selbst kann in vier Phasen unterteilt werden

  • Client schickt zum Server ein ClientHello, und der Server antwortet dem Client mit einem ServerHello. Die Parameter der Nachrichten sind:
    • die höchste vom Client unterstützte TLS-Protokoll-Version
    • eine 32 Byte lange Zufallsinformation wird später verwendet pre-master-secret, zum Schutz vor Replay-Attackenm zu bilden
    • eine Session-ID
    • die zu verwendende Cipher Suite (Algorithmen für Schlüsselaustausch, Verschlüsselung und Authentifizierung)
    • Optional den gewünschten FQDN für die Unterstützung von Server Name Indication
    • in der TLS 1.3 Version (mit Diffie-Hellman-Schlüsselaustausch) werden die Key-Shares übertragen, die den gemeinsamen Schlüssel definieren.
  • Der Server identifiziert sich gegenüber dem Client.
    • Hierzu wird per Certificate ein Zertifikat an den Client geschickt, gefolgt von einem CertificateVerify
    • CertificateVerify Nachricht enthält eine Unterschrift von zuvor ausgetauschten Nachrichten.
    • Server beweist, dass er einen Secret-Key besitzt, der zu dem auf dem Server-Zertifikat enthaltenen passt.
    • Client prüft das Zertifikat und die Unterschrift. Bei Misserfolg bricht der Client die Verbindung ab.
  • Das zuvor erhaltene Server-Zertifikat enthält den öffentlichen Schlüssel des Servers
    • Wird eine Cipher Suite mit RSA-Schlüsselaustausch verwendet
      • so wird das vom Client generierte pre-master-secret mit diesem öffentlichen Schlüssel verschlüsselt
        • und kann vom Server mit dem nur ihm bekannten privaten Schlüssel wieder entschlüsselt werden.
    • Alternativ kann hier auch der Diffie-Hellman-Schlüsselaustausch verwendet werden
      • dann wird ein gemeinsames pre-master-secret zu generieren.
      • Wenn Diffie-Hellman-Geheimnisse von Server und Client während des Handshakes frisch und zufällig ausgehandelt
      • sind die Voraussetzungen für Perfect Forward Secrecy erfüllt.
  • Diese Phase schließt den Handshake ab.
    • Aus dem vorhandenen pre-master-secret kann das master secret abgeleitet werden
    • ein einmaligen Sitzungsschlüssel
    • Aus dem master secret werden wiederum Schlüssel abgeleitet
    • zum Ver- und Entschlüsseln der Daten sowie für die Integritätsprüfung verwendet werden.
    • Nachrichten, die die Kommunikationspartner sich nun gegenseitig zusenden sind verschlüsselt übertragen

TLS Change Cipher Spec Protocol

  • Das Change Cipher Spec Protocol besteht nur aus einer einzigen Nachricht.
  • Diese Nachricht ist ein Byte groß und besitzt den Inhalt 1.
  • Durch diese Nachricht teilt der Sender dem Empfänger mit, dass er in der aktiven Sitzung auf die im Handshake Protocol ausgehandelte Cipher Suite wechselt.
  • Protokoll wurde gewählt weil man expliziert keine Record Übertragung wollte.

TLS Alert Protocol

  • unterscheidet etwa zwei Dutzend verschiedene Mitteilungen.
  • Eine davon teilt das Ende der Sitzung mit (close_notify).
  • Andere beziehen sich zum Beispiel auf die Protokollsyntax oder die Gültigkeit der verwendeten Zertifikate.
  • Es wird zwischen Warnungen und Fehlern unterschieden, wobei letztere die Verbindung sofort beenden.

Der Aufbau einer Fehlermeldung lautet wie folgt: AlertLevel (1 Byte: Warning = 1, Fatal = 2) | AlertDescription (1 Byte: close_notify = 0, […], no_renegotiation = 100).

In der Spezifikation von TLS werden die folgenden schweren Fehlertypen definiert:

unexpected_message Unpassende Nachricht wurde empfangen.
bad_record_mac Ein falscher MAC wurde empfangen.
decompression_failure Dekomprimierungsalgorithmus empfing unkorrekte Daten.
handshake_failure Absender konnte keine akzeptable Menge von Sicherheitsparametern bearbeiten.
illegal_parameter Ein Feld in der Handshake-Nachricht lag außerhalb des erlaubten Bereichs oder stand im Widerspruch mit anderen Feldern.

In der Spezifikation von TLS werden die folgenden Warnungen definiert:

close_notify Teilt Empfänger mit, dass Absender keine weiteren Nachrichten auf dieser Verbindung senden wird. Muss von jedem Partner einer Verbindung als letzte Nachricht gesendet werden.
no_certificate Kann als Antwort auf eine Zertifikatanforderung gesendet werden, falls passendes Zertifikat nicht verfügbar ist. (Wurde in TLS 1.0 entfernt<ref name="schwenk2010">Schwenk, Jörg (2010): Sicherheit und Kryptographie im Internet. Von sicherer E-Mail bis zu IP-Verschlüsselung, herausgegeben von Vieweg+Teubner Verlag / GWV Fachverlage GmbH, Wiesbaden. ISBN 978-3-8348-0814-1.</ref>)
bad_certificate Empfangenes Zertifikat war unvollständig oder falsch.
unsupported_certificate Der Typ des empfangenden Zertifikats wird nicht unterstützt.
certificate_revoked Zertifikat wurde vom Unterzeichner zurückgerufen.
certificate_expired Zertifikat ist abgelaufen.
certificate_unknown Andere, nicht genau spezifizierte Gründe sind beim Bearbeiten des Zertifikats aufgetreten, die dazu führen, dass das Zertifikat als ungültig gekennzeichnet wurde.

In der Spezifikation von TLS 1.0 wurden folgende Warnungen ergänzt:<ref name="schwenk2010" />

decryption_failed Entschlüsselung fehlgeschlagen.
record_overflow
unknown_ca Unbekannte oder nicht vertrauenswürdige CA.
access_denied Zugriff verweigert.
decode_error Decodierungsfehler.
decrypt_error Entschlüsselungsfehler.
export_restriction Exportbeschränkung.
protocol_version Veraltete Version von TLS/SSL.
insufficient_security Unzureichende Sicherheit.
internal_error Interner Fehler.
user_canceled Abbruch durch Benutzer.
no_renegotiation

TLS Application Data Protocol

  • Die Anwendungsdaten werden über das Record Protocol
  • transportiert
  • in Teile zerlegt
  • komprimiert
  • in Abhängigkeit vom aktuellen Zustand der Sitzung auch verschlüsselt.
  • Inhaltlich werden sie von TLS nicht näher interpretiert.

Berechnung des Master Secrets

  • TLS 1.2 mit Hilfe einer durch eine Cipher Suite spezifizierten Pseudozufallsfunktion das Master Secretberechnet.
  • In diese Berechnung fließen zusätzlich die Zufallszahlen der Phase 1 des Handshakes mit ein.
  • Die Verwendung beider Hash-Funktionen sollte sicherstellen, dass das Master Secret immer noch geschützt ist, falls eine der Funktionen als kompromittiert gilt.
  • In TLS 1.2 wird dieser Ansatz durch die flexible Austauschbarkeit der Funktion ersetzt.

Quelle

Abgerufen von „http://wiki.ixheim.de/index.php?title=TLS_Protokoll&oldid=25928“