Funktionsweise

---Cipher Suite Key Cipher Mac

Exchange

TLS_NULL_WITH_NULL_NULL NULL NULL NULL

TLS_RSA_WITH_RC4_128_MD5 RSA RC4_128 MD5

TLS_RSA_WITH_RC4_128_SHA RSA RC4_128 SHA

TLS_RSA_WITH_3DES_EDE_CBC_SHA RSA 3DES_EDE_CBC SHA TLS_RSA_WITH_AES_128_CBC_SHA RSA AES_128_CBC SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 DHE_RSA AES_128_CBC SHA256

---Das erste Beispiel nutzt keine Sicherheitsmechanismen: weder Client noch Server authentisie-ren sich, es wird weder eine symmetrische Chiffre noch ein MAC genutzt.

Beim zweiten Beispiel steht RSA f¨ur den Schl¨usselaustausch und die Instanzauthentifikation.

Der Schl¨usselaustausch geschieht wie folgt: Der Client w¨ahlt das PMS und verschl¨usselt dieses mit dem ¨offentlichen RSA Schl¨ussel des Servers. Anschließend wird dieser Chiffretext an den Server geschickt. Die Authentifikation des Servers geschieht implizit durch Nachweis der Kenntnis des PMS. Als symmetrische Chiffre wird die Stromchiffre RC4 mit einer Schl¨ussell¨ange 128 Bit verwendet, der MAC verwendet MD5 als Hashfunktion.

In der letzten CipherSuite dient das Diffie-Hellman-Verfahren zum Austausch des PMS. DHE steht dabei f¨ur Diffie-Hellman-Ephemeral: Client und Server nutzen jeweils einen einmaligen

¨offentlichen Diffie-Hellman-Schl¨ussel. Das RSA-Verfahren dient zur Instanzauthentifikation des Servers. Als symmetrische Chiffre wird AES mit einer Schl¨ussell¨ange 128 Bit im CBC-Modus verwendet, der MAC verwendet SHA256 als Hashfunktion. Diese Chiffre ist – eine hinreichende Schl¨ussell¨ange f¨ur RSA und das Diffie-Hellman-Verfahren vorausgesetzt – als sehr sicher einzu-stufen.

5.2.3 Funktionsweise

Dieser Abschnitt beschreibt die Funktionsweise von TLS im Detail. Dabei ist vor allem wichtig zu wissen, welche Aufgaben die einzelnen Protokolle des TLS-Protokollstacks ¨ubernehmen. Diese wurden bereits kurz in Abschnitt 5.2.1 erw¨ahnt. Zun¨achst aber sollen die in TLS verwendeten Schl¨ussel beschrieben werden.

Kryptographische Schl¨ussel, Pre-Master-Secret, Master-Secret In Abschnitt 5.2.2 wur-de bereits erl¨autert, dass TLS sechs symmetrische Schl¨ussel verwendet und diese dezentral be-rechnet. Client und Server tauschen nur das Pre-Master-Secret als geheime Information ¨uber das unsichere Internet aus.

Dient RSA zum Schl¨usselaustausch, so bestimmt der Client alleine das Pre-Master-Secret (PMS). Es ist in diesem Fall eine 48-Byte lange Datenstruktur: 46-Byte stammen von einer Zufalls-zahl, die verbleibenden zwei Byte sind die TLS-Versionsnummer. Der Client ¨ubermittelt das PMS

5Der RFC ist https://www.ietf.org/rfc/rfc5246.txt abrufbar. Ab Seite 82 ist eine Liste der in TLS1.2 standardisierten Cipher Suites.

an den Server, indem er es mit dem ¨offentlichen RSA Schl¨ussel des Servers verschl¨usselt. Daraufhin kann nur der Server daraus das PMS mit seinem zugeh¨origen privaten Schl¨ussel berechnen. Im Fall von Diffie-Hellman als Schl¨usselaustauschverfahren erzeugen beide Seiten zun¨achst ein einmaliges Diffie-Hellman-Schl¨usselpaar, aus dem nach dem klassischen Diffie-Hellman-Verfahren das PMS abgeleitet wird. Beide Seiten kennen also das PMS, obwohl dieses nie im Klartext ¨ubermittelt wurde.

Aus dem Pre-Master-Secret berechnen der Client und der Server dezentral mit Hilfe von Has-hfunktionen das 48-Byte lange Master-Secret (MS). Neben dem Pre-Master-Secret gehen noch Pseudozufallswerte von Client und Server sowie aktuelle Zeitstempel in das Master-Secret ein.

Aus dem MS berechnen beide Kommunikationspartner abschließend die sechs kryptographischen Schl¨ussel:

• Ein symmetrischer Schl¨ussel KC f¨ur die Verschl¨usselung der Daten, die der Client an den Server sendet. In der TLS-Notation wird dieser mitclient_write_keybezeichnet.

• Ein symmetrischer Schl¨usselK_Sf¨ur die Verschl¨usselung der Daten vom Server. TLS bezeich-net diesen Schl¨ussel alsserver_write_key.

• Ein symmetrischer MAC-Schl¨usselK_{M AC−C} zur Integrit¨atssicherung der TLS-Records, die der Client an den Server schickt. TLS nennt diesen Schl¨usselclient_write_MAC_key.

• Ein symmetrischer MAC-Schl¨ussel K_{M AC−S} zur Integrit¨atssicherung der Daten, die der Client vom Server empf¨angt. Die TLS-Notation bezeichnet diesen Schl¨ussel als server_write_MAC_key.

• Im Falle einer symmetrischen Blockchiffre existieren noch die beiden Initialisierungsvektoren client_write_IVsowieserver_write_IV.

Bitte erinnern Sie sich, dass aus Sicherheitsgr¨unden immer nur ein Schl¨ussel f¨ur eine Operation benutzt wird und niemals ein Schl¨ussel f¨ur mehrere Operationen, da ansonsten die Gefahr besteht, aus den verschl¨usselten Daten auf den geheimen, symmetrischen Schl¨ussel R¨uckschl¨usse zu ziehen.

TLS-Layer1 Auf TLS-Layer1 gibt es nur dasTLS Record Protocol. Eine ¨Ubersicht zu diesem Protokoll finden Sie in Abbildung 5.6. Zu den Aufgaben des Record Protocols geh¨ort zun¨achst die Fragmentierung der Daten des TLS-Layer2 in Fragmentem1,m2usw. Ein Fragment ist h¨ochstens 2¹⁴ Byte groß, also 16 KiB.

Jedes Fragment erh¨alt einen Header1, aus dem das Layer2-Protokoll sowie die Version hervorgehen. Dieses Fragment samt Header wird komprimiert, sofern das im TLS-Handshake festgelegt wurde. Oft wird keine Komprimierung eingesetzt. Das komprimierte Frag-ment erh¨alt einen neuen Header2 mit den gleichen Informationen wie Header1. Anschließend wird der MAC ¨uber Header2 und komprimiertes Fragment berechnet, danach wird das gesamte Frag-ment samt Header2 verschl¨usselt.

TLS-Layer2 Auf TLS-Layer2 sind vier Protokolle vorzufinden, die schon in Abschnitt 5.2.1 kurz erl¨autert wurden. In diesem Abschnitt werden nun weitere Details beschrieben, insbesondere zum TLS-Handshake.

Das TLS Application Data Protocol hat eine einfache Aufgabe, n¨amlich die Durchleitung der Daten zwischen Anwendungsschicht und TLS-Layer1. Das ist in Abbildung 5.5 durch die bei-den Pfeile dargestellt. Das Application Data Protocol stellt also die operative Schnittstelle zur Absicherung der Anwendungsschicht dar.

Die ¨ubrigen drei Protokolle auf TLS-Layer2 heißenTLS Handshaking Protokolle. Diese sind im Rahmen des TLS Handshakes relevant und sie haben keine Schnittstelle zur Anwendungsschicht.

Bitte beachten Sie, dass das TLS Handshake Protocol eines der drei TLS Handshaking Proto-kolle ist und dass Sie die beiden Begrifflichkeiten nicht verwechseln. Im Folgenden werden diese Protokolle kurz vorgestellt:

5.2. SSL/TLS 93

Abbildung 5.6: Das TLS Record Protocol

• TLS Handshake Protocol: Dieses Protokoll dient dem Verbindungsaufbau zwischen Cli-ent und Server. Im Rahmen des TLS Handshakes findet die AuthCli-entifikation des oder der Kommunikationspartner, das Aushandeln der zu verwendenden kryptographischen Verfahren und der Austausch ben¨otigter geheimer Informationen statt. Dabei sind f¨ur die Authenti-fikation drei M¨oglichkeiten vorhanden: keine Authentifikation, nur der Server authentisiert sich oder beide authentisieren sich. Eine vierte M¨oglichkeit, dass sich ein Client an einem nicht-authentisierten Server authentisiert, ist nicht zugelassen. Wenn der TLS Handshake ab-geschlossen ist, liegen die kryptographischen Verfahren fest und beide Seiten haben Zugriff auf alle sechs Sitzungsschl¨ussel.

• TLS Change Cipher Spec Protocol: Das Change Cipher Spec Protocol umfasst ledig-lich eine Nachricht bestehend aus dem Klartext-Byte 0x01. Sie wird im Rahmen des TLS Handshakes gesendet. Mit dieser Nachricht signalisiert der Sender, dass er f¨ur diefolgenden TLS-Records auf die gerade festgelegten Verfahren und Schl¨ussel umsteigt.

• TLS Alert Protocol: Mit diesem Protokoll werden TLS-spezifische Warnungen an den Kommunikationspartner ¨ubermittelt. Eine Alert-Nachricht besteht aus zwei Bytes. Mit dem ersten Byte wird die Schwere der Warnmeldung angezeigt. Wird ein fataler Zustand si-gnalisiert, f¨uhrt das zum sofortigen Abbruch der Verbindung. Ebenso werden keine neuen Verbindungen f¨ur diese Sitzung mehr er¨offnet. Das zweite Byte kodiert Hinweise zum Fehler, z.B. dass ein Zertifikat bereits abgelaufen oder zur¨uckgerufen ist.

TLS-Handshake Der Aufbau einer durch TLS gesicherten Verbindung wird auch als TLS-Handshake bezeichnet. Die wesentlichen Ziele des TLS Handshakes sind:

1. Festlegung der verwendeten kryptographischen Verfahren f¨ur die Absicherung der TLS-Records.

2. Festlegung der Komprimierung bzw. ob ¨uberhaupt komprimiert wird.

3. Festlegung, wer sich authentisiert sowie Durchf¨uhrung der Authentifikation durch den Kom-munikationspartner. In den meisten F¨allen authentisiert sich nur der Server mittels TLS, es

ist allerdings auch zugelassen, dass sich keiner oder beide Seiten authentisieren. Lediglich die Authentisierung eines Clients an einem nicht-authentifzierten Server ist verboten.

Denken Sie exemplarisch an einen TLS-Handshake, bei dem ein Nutzer mit seinem Browser auf einen TLS-gesicherten Webserver zugreifen will. Meist authentisiert sich nur der Server gegen¨uber dem Client mittels TLS, w¨ahrend der Nutzer Passwort-basiert authentifiziert wird.

Der gesamte TLS-Handshake wird in Abbildung 5.7 gezeigt. Im nachstehenden Abschnitt wer-den die einzelnen Schritte diskutiert.

Client Server

ClientHello --->

ServerHello Certificate*

ServerKeyExchange*

CertificateRequest*

<--- ServerHelloDone Certificate*

ClientKeyExchange CertificateVerify*

[ChangeCipherSpec]

Finished --->

[ChangeCipherSpec]

<--- Finished Application Data <---> Application Data

* Indicates optional or situation-dependent messages that are not always sent.

Note: To help avoid pipeline stalls, ChangeCipherSpec is an independent TLS protocol content type, and is not actually a TLS handshake message.

Abbildung 5.7: Der TLS-Handshake gem¨aß RFC 5246.

Zun¨achst signalisiert der Client dem Server, dass er mit ihm eine TLS-Sitzung aufbauen m¨ochte.

Dazu sendet der Client eineClientHello-Nachricht. Darin teilt der Client die von ihm unterst¨utzten CipherSuites mit. Außerdem werden zur Vermeidung von Replay-Angriffen eine ID sowie eine vom Client gew¨ahlte Zufallszahl RND1 an den Server gesendet.

Der Server antwortet mit einerServerHello-Nachricht. Darin teilt der Server die von ihm festge-legteCipherSuite f¨ur diese Sitzung mit. Außerdem wird die Client-ID sowie seine Zufallszahl RND2 zur¨uckgeschickt. Anzumerken ist, dass der Client lediglich eine Liste der von ihm unterst¨utzten Verfahren sendet und der Server ¨uber das Verfahren entscheidet.

Soll der Server authentifiziert werden, sendet dieser anschließend mit der Certificate -Nachricht die Zertifikatskette, die mit seinem eigenen Zertifikat beginnt. Durch Angabe geeig-neter CipherSuites zeigt der Client, dass sich der Server mittels TLS authentisieren soll (z.B.

TLS_DHE_RSA_WITH...). Soll der Server sich nicht authentisieren, unterbleibt die Certificate -Nachricht. Daher ist sie in Abbildung 5.7 als optional markiert. Des Weiteren wird vom Server je nach festgelegter CipherSuite eineServerKeyExchange-Nachricht gesendet, beispielsweise wenn Diffie-Hellman als Schl¨usselaustauschmethode verwendet wird. Im Fall einer CipherSuite der Form TLS_RSA_WITH... sendet der Server diese Nachricht nicht, da der Client das Pre-Master-Secret w¨ahlt und RSA-verschl¨usselt an den Server schickt (siehe Beispiel 23).

5.2. SSL/TLS 95 Optional verlangt der Server eine TLS-Client-Authentifikation: dazu sendet er eine Cerfica-teRequest-Nachricht. Zum Abschluss sendet der Server eine ServerHelloDone-Nachricht, um dem Client zu signalisieren, dass der Server auf die Client-seitigen Nachrichten wartet.

Sofern der Server eine TLS-Client-Authentisierung w¨unscht, sendet der Client mittels einer Certificate-Nachricht seine Zertifikatskette an den Server. Andernfalls entf¨allt diese Nachricht. In jedem Fall sendet der Client eine ClientKeyExchange-Nachricht. Im Fall von Diffie-Hellman als Schl¨usselaustauschverfahren sendet der Client seinen DH-Public-Key an den Server, im Fall von RSA w¨ahlt er das PMS, verschl¨usselt dieses mit dem ¨offentlichen RSA Schl¨ussel des Servers und sendet es als ClientKeyExchange-Nachricht. Im Falle einer TLS-Client-Authentisierung signiert der Client mit dem zu seinem Zertifikat geh¨orenden privaten Schl¨ussel alle bisherigen Handshake-Nachrichten. Er sendet diese Signatur alsCertificateVerify-Nachricht zum Server.

Der letzte Schritt des Clients beginnt mit derChangeCipherSpec-Nachricht, die angibt, dass der Client fortan seine gesendeten Nachrichten mit den ausgehandelten kryptographischen Verfahren und Schl¨usseln absichert. Direkt darauffolgend wird eineFinished-Nachricht gesendet, die einen Hashwert enth¨alt, der ¨uber alle empfangenen und gesendeten Nachrichten gebildet wird und mit den neuen Sicherheitseinstellungen abgesichert wird. Dadurch zeigt der Client, dass er das PMS kennt.

Der TLS-Handshake wird dadurch abgeschlossen, dass auch der Server den Umstieg der von ihm gesendeten TLS-Records auf die neuen Sicherheitseinstellungen mittels einer ChangeCipherSpec-Nachricht signalisiert. Danach weist der Server durch eine g¨ultig abgesicherte Finished-Nachricht nach, dass auch er das PMS kennt, weil er die daraus abgeleiteten Schl¨ussel nutzt. Ab diesen Zeitpunkt werden alle Informationen mit den neuen Sicherheitseinstellungen abgesichert: das TLS Application Data Protocol wird genutzt, um Daten zwischen TLS Layer1 und der Anwendungs-schicht auszutauschen.