TLS Aufbau und Funktion

Aufbau und Funktionsweise von TLS
Andreas Eisele, Karsten Stepanek
June 19, 2016
Hochschule Aalen
Fach: Seminar
Projektbetreuer: Prof. Dr.Werthebach
1
Contents
1 Vorwort
3
2 Was ist TLS
2.1 DTLS die Variante für UDP . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Abgrenzung von TLSv1 und SSLv3 . . . . . . . . . . . . . . . . . . . . . . .
4
5
5
3 Geschichte
6
4 Aufbau von TLS
4.1 Chipher-Suites . . . . . . .
4.1.1 Beispiel Chiper-Suite
4.2 Record Protokoll . . . . . .
4.3 Application Data Protokoll .
4.4 Alert Protokoll . . . . . . .
4.5 Handshake Protokoll . . . .
4.6 Change CipherSpec . . . . .
.
.
.
.
.
.
.
7
7
8
9
10
10
10
10
5 Protokoll Aufbau in Wireshark
5.1 Client Hello . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Server Hello . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
11
13
6 Trust Center und Zertifikate
6.1 Trust Center (CA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 Zertifikate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
14
14
7 Funktionsweise
7.1 Voraussetzung für TLS-Verbindung mittels Zertifikate und Public-Key
fahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2 Beginn eines Verbindungsaufbaus (mit TLS-Handshake-Verfahren) . . .
7.3 Eigentliche Übertragung, . . . . . . . . . . . . . . . . . . . . . . . . .
7.4 Wiederaufnahme einer TLS-Verbindung . . . . . . . . . . . . . . . . . .
7.5 Open Source Implementierungen von TLS (OpenSSL und GnuTLS . .
7.6 Anwendungsfälle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.6.1 HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.6.2 SMTPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.6.3 IMAPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.6.4 POP3S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Ver. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
15
15
16
17
17
17
17
17
18
18
8 Schwachstellen
8.1 DHE EXPORT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2 Heartbleed-Exploit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
19
19
9 Zusammenfassung und Fazit
20
10 Ausblick
20
1
11 Anhang
21
Quellverzeichnis
21
Abbildungsverzeichnis
23
Abkürzungsverzeichnis
23
2
1
Vorwort
Diese Arbeit stellt das TLS (Transport Layer Security) oder auch die verbreitetere Bezeichnung SSL (Secure Socket Layer) Protokoll vor.
Basierend auf der Transport-Schicht und deren Protokolle wie TCP und UDP, sichert TLS
diese Dienste.
Der Schwerpunkt der Ausarbeitungen bezieht sich vor allem auf den Aufbau sowie dem
generellen Ablauf dieses Protokolls. Anschaulich wird anhand von Abbildungen und Diagrammen vermittelt, wo im Osi-Schichtenmodell der Einsatz erfolgt und welche zusätzlichen
Bedingungen für den Dienst von TLS vorausgesetzt sind.
Um visuell ein besseres Verständnis für eben diesen Ablauf einer gesicherten Verbindung
darzustellen, bedienen sich die Autoren an mehreren Stellen dem Netzwerkanalyse-Programm
Wireshark.
Kapitel 2 bildet die erste Festlegung was TLS überhaupt ist und aus welchen ProtokollBausteinen es besteht, zudem stellt es eine Abgrenzung zu der letzten Version von SSL und
der nunmehr verwendeten Bezeichnung TLS her.
Kapitel 3 gibt die Entstehungsgeschichte wieder anhand der zeitlichen Etappen der Entwicklung.
Kapitel 4 veranschaulicht den Aufbau und stellt die unterschiedlichen Komponenten und
deren Funktionen dar. Insbesondere beleuchtet dieser Abschnitt bereits die eingesetzten
kryptografischen Algorithmen und deren Einsatz.
Kapitel 5 zeigt die Abbildungen eines Wireshark Sniffs der die Nachrichten ”hello Client”
& ”hello Server” darstellt und ermöglicht so einen detaillierten Einblick des Inhalts dieser
Nachrichten.
Kapitel 6 beschäftigt sich mit elektronischen Zertifikaten, die einen wichtigen Anteil an
dem Konzept von TLS besitzen.
Kapitel 7 ist ein sehr umfangreiches Kapitel, dass aufbauend auf den Vorangegangen den
Ablauf einer TLS-Verbindung beschreibt. Zudem wird dort Bezug auf die verfügbaren
Implementierungs-Kit‘s des TLS genommen und stellt die Umsetzungen von TLS in den
Anwendungsprotokollen dar.
Kapitel 8 nimmt Bezug auf die Schwachstellen vergangener SSL & TLS Versionen und
verdeutlicht damit die Notwendigkeit einer ständigen Aktualisierung bzw. Anpassung an
aktuelle Gefahrenquellen für diesen bedeutenden Dienst.
Das Ziel dieser Arbeit besteht darin dem Leser die grundlegende Funktionalität des TLS
Protokolls zu vermitteln und das nötige Wissen über Aufbau und Einsatzgebiete näher zu
bringen. So kann die nötige Basis für tiefgreifendere Forschungen des TLS Protokolls entstehen.
3
2
Was ist TLS
Transport Layer Security (TLS) ist ein sogenanntes hybrides Verschlüsselungs-Verfahren, das
oberhalb der Transportschicht im Open Systems Interconnection Model (OSI-Schichtenmodell)
angesiedelt ist. Es entstand aus dem unsicheren Secure Socket Layer (SSL)v3 (Secure
Socket Layer) Protokoll, das von der Firma Netscape entworfen wurde. Im Jahr 1995 war
das primäre Ziel von SSL das Hypertext Transfer Protocol (HTTP) Protokoll abzusichern.
Dadurch entstand der Name Secure-Hypertext Transport Protokoll (S-HTTP)
Allerdings wird der Begriff SSL auch für TLS verwendet, was für Laien oftmals verwirrend
sein kann. Festzuhalten ist, dass SSL Version 3.0 nicht mehr als sicher eingestuft wird aufgrund verschiedener Sicherheitsmängel. Als aktuell sichere Versionen sind die in den Request
for Comments (RFC)‘s beschriebenen Versionen TLS ab Version 1.2. [Sch05, Seite 276-278]
Figure 1: OSI TLS [Abb]
TLS wurde entworfen um eine Ende zu Ende-Verschlüsselung zwischen zwei Verbindungspartnern herzustellen. Wobei es in der Regel so ist, dass ein Client eine Verbindung zu einem
Server aufbaut. Die während dem Verbindungsaufbau auf einer asymmetrischen Verschlüsselung
basiert und später in ein symmetrisches Verfahren wechselt. TLS setzt auf der Transportschicht an und sichert die nicht verschlüsselten Transportprotokolle Transmission Control Protocol (TCP) und User Datagram Protocol (UDP). Eine weitere Variante ist IPsec
die ebenfalls verwendet wird, durch die aufwändigere Implementierung ist diese Methode
jedoch nicht so verbreitet.
Um von einer sicheren Verbindungsart zu sprechen werden die drei folgenden Aspekte als
die Eckpunkte verstanden um dies zu erreichen:
• Authentifizierung des Kommunikationspartners
• Authenzität (auch Integrität) vor Täuschung und Fälschung
• Vertraulichkeit der Daten
4
2.1
DTLS die Variante für UDP
Während TLS das TCP Protokoll unterstützt und damit zuverlässige sowie verbindungsorientierte Kommunikationen sichert, blieb lange eine adäquate Alternative für UDP nicht
verfügbar.
Mit der festen Standardisierung 2006 ist dann Datagram Transport Layer Security (DTLS)
als sichere Methode für UDP Verbindungen verfügbar. Damit sind zum Beispiel VoIP
Verbindungen verschlüsselt. Aufgrund des geringeren Einsatzgebietes und da der Aufbau
und Ablauf zu TLS fast identisch ist, wird in dieser Arbeit nicht näher auf DTLS eingegangen. [ER12]
2.2
Abgrenzung von TLSv1 und SSLv3
In diesem Unterkapitel werden die zwei Verschlüsselungsverfahren TLS und SSL von einander abgegrenzt.
Die Grundstruktur der Protokolle(z.B. Handshake Protokol) die auf das Recordprotokoll
aufsetzten sind die gleichen geblieben.
Für das Verständis wird hier kurz die MAC und HMAC erläutert. Die MAC wird Anahnd der
kompremierten Nachricht erzeugt und anschließend an das TLS-Segment angehängt. Es dient der Datenintegrität des Packets. Bei SSL wird dies durch ein doppel Hash-Algorithmus(MD5
oder SHA1) anhand des Mastersecret, Sequenznummer der Nachricht und den Anwendungsdaten erzeugt. In dem TLS Protokoll ist es jetzt möglich ein beliebigen Hash-Algorithmus
zu verwenden. Dies wird als HMAC bezeichnet.
Die Alertmeldungen wurden größten Teil von SSL übernommen, bis auf die no certificat
Meldungen. Weiterhin wurden bei TLS einige Meldungen ergänzt. Aufgrund das die symmetrischen Verfahren SKIPJACK und KEA (BlockChiphre-Verfahren) nicht mehr unterstütz
wurden, gibt es keine gesonderten Zertifikatstypen in TLSv1 mehr.
Weiterhin wurde die finished-Nachricht so erweitert das der geheime Schlüssel anzeigt ob die
Nachricht von dem CLient oder Server kommt. Zum Schluss wurde durch das vergrößern
der TLS-Variablen das Padding(aufblähen von Nachrichten durch pseudo Werte) verbessert,
dient der Verwirrung von Angreifern, da nicht alle Daten relevant sind.
TLS wurde so weiter entwickelt, das es abwarts kompatibel zu SSL ist. TLS wurde so weiter
entwickelt, das es abwärts kompatibel zu SSL ist. [SEM], [REP]
5
3
Geschichte
Seit Anfang der Neunziger Jahre des vergangenen Jahrhunderts verzeichnete das Internet
einen rasanten Nutzer-Anstieg. Aufgrund der Verbreitung von Personal Computern und
damit auch dem Zugang zum World Wide Web vernetzten sich vor allem immer mehr Privatpersonen und damit wuchs auch der kommmerzielle Einsatz des Internets.
Die Möglichkeiten des Internets angefangen von der Informationsbeschaffung, E-Mail Verkehr
oder einkaufen in Online-Shop‘s und natürlich Online-Banking verlangten nach einer sicheren
Möglichkeit der Kommunikation im Web. Da das Internet bis dato überwiegend von Forschungsorganisationen wie Universitäten oder Regierungsstellen genutzt wurde, boten die wichtigsten Protokolle in der Web-Kommunikation TCP und IP noch keine Mechanismen für einen
sicheren Datenaustausch.
1994 entwickelte die Firma Netscape Communications das Protokoll SSL (Secure Socket
Layer) Version 1. für ihren Browser ”Netscape Navigator” das jedoch kaum verbreitet wurde.
Kurz darauf entstand bereits die zweite Version. Netscape ging es vor allem um die Sicherung
des HTTP-Protocols um Transaktionen wie Online-Banking und Online-Shopping sicher zu
machen. Da es sich bei SSL um eine alleinige Entwicklung der Firma Netscape handelte
blieben kryptografische Analysen unabhängiger Experten aus.
So wurden bald darauf erhebliche Schwächen in der Version 2 entdeckt. Fast zeitgleich stellte
Microsoft eine eigene Variante des SSL Vers. 2, das PCT-Protokoll für den Ende 1995 herausgebrachten Internet Explorer. Durch das PCT-Protokoll war es möglich in einer Client
Serververbindung die Daten zu authentifizieren, jedoch noch nicht zu verschlüsseln. Auch
Netscape veröffentlichte 1995 die dritte Version des SSL-Protokolls, welches grundlegend
überarbeitet wurde und nicht nur die Schwachstellen der Version 2 behoben hatte sondern
auch um Funktionen des PCT‘s ergänzt wurde.
Um letzlich einen herstellerunabhängigen Standard herzustellen, setzte sich eine Arbeitsgruppe Internet Engeneering Task Force (IETF) zusammen und stellte 1999 die erste Version des TLS (Transport Layer Security) Protokolls vor. Es unterscheidet sich kaum von
SSL Version 3 was mit dazu beiträgt, dass nach wie vor beide Bezeichnungen SSL und TLS
noch verwendet werden.
Das Protokoll ist in ständiger Entwicklung und Anpassung an technische Neuerungen, die
aktuelle Version 1.2 des TLS (Stand 2015) wird zum Beispiel vom BSI als gesetzliche Mindestvorschrift in der Bundesverwaltung festgelegt.
[Zah06], [Sch05], [KOM]
6
4
Aufbau von TLS
Das TLS ist eng mit dem TCP Protokoll verzahnt. Da es genau oberhalb der Transportschicht im OSI-Schichtenmodell angesiedelt ist. Dadurch nutzt das TLS die Eigenschaften der zuverlässigen Kommunikation von TCP. Das Transport Control Protokoll ist
für die zuverlässige und fehlerfreie Datenübertragung verantwortlich.
Der Aufbau sieht wie folgt aus:
Figure 2: TLS-Schichtenmodel [SEM]
In den kommenden Unterkapiteln wird das Abbild näher erläutert.
4.1
Chipher-Suites
Unter dieser Suite findet man mehrere Konstellationen zwischen Authentizität- und Verschlüsselungverfahren. Die stärkste Suite orientiert sich an der jeweils schwächsten Methode
in seiner Chipher-Suite.
Bei dem Verbindungsaufbau schlägt der Client dem Server mehrere Chipher-Suites vor, aus
denen wiederum der Server eine auswählt, die anschließend im Record Protokoll eingetragen
wird.
Der Bezeichner einer Chiphre-Suite ist wie folgt aufgebaut:
TLS Schlüsselaustauschverfahren WITH VERFAHRENzurDATENSICHERUNG
Das WITH dient lediglich zur Trennung. Nachfolgend werden zwei Cipher-Suite aus TLS
1.0 näher betrachtet.
Eine weitere heute gängigere Suite ist die ”TLS ECDHE RSA WITH AES 128 GCM SHA256”.
Das elliptic curve diffie-hellman (ECDHE) ist eine Erweiterung von Diffie-Hellman (DHE)
die durch eine mathematische Ellipse-Curve erweitert wurde.
Im Gegensatz zu SSL Ver.3.0 wurden die Verschlüsselungsverfahren verstärkt. Statt Triple
Data Encryption Standard (3DES) wird Advanced Encryption Standard (AES) 128Bit verwendet und statt SHA-1 wird SHA256Bit genutzt. Da die heutigen Endgeräte deutlich
leistungsstärker, sind ist es möglich auch rechenintensivere Verfahren anzuwenden ohne das
dies einen merklichen Performanceunterschied macht. [Sch05, Seite 278 ff]
7
• TLS RSA WITH 3DES EDE CBC SHA
Bei dieser Chipher-Suites wird das Rivest, Shamir und Adleman (RSA) ProtokoTherell
verwendet um die Kommunikationsteilnehmer zu authentifizieren, das geschieht parallel zum Schlüsselaustausch. Gleichzeitig dient das Protokoll auch der Verschlüsselung
des von Client erzeugten Schlüsselmaterials.
Die darauf folgende Datenübertragung wird mittels 3DES im EDE-CBC-Modus verschlüsselt. Das SHA-1 Hash-Verfahren sorgt für die Gewährleistung der Datenintegrität.
• TLS DHE RSA WITH 3DES EDE CBC SHA
Das ist ein weiteres Verfahren das den vorherigen sehr ähnlich ist. Der Unterschied
hierbei ist das das Schlüsselmaterial mittels des Diffie-Hellman Verfahren statt findet.
Die Vorgaben einer Primzahl und einem Generator gehen vom Server aus. Darauf
folgend werden die DH-Werte mit der RSA-Singatur authentifiziert. Der weitere Ablauf
ist dann der gleiche wie im vorherigen Beispiel.
4.1.1
Beispiel Chiper-Suite
Der detaillierter Einblick in die Chipher-Suite. Wenn man die Suite TLS ECDH RSA WITH AES 128
mit CBC SHA256 betrachtet ist der zweite Wert ”ECDH” das Verfahren zum Schlüsselaustausch. Darauf folgt die Zertifikatart ”RSA” und die Verschlüsselung mit dem Betriebsmodi
”AES 128”. Das ist eine 128 Bit AES-Verschlüsselung mit dem Betriebsmodi Cipher Block
Chaining (CBC) Mode. Zusätzlich verwendetes Hashverfahren ist ”SHA256”.
AES handelt es sich um ein symmetrisches Verschlüsselungsverfahren welches Blockweise verschlüsselt. Zurzeit sind keine effektiven Angriffe bekannt d.h. dass dieses Verfahren
also als sicher gilt und wird zum Beispiel in der Absicherung von W-Lan Netzen verwendet
unter WPA2. Es gib drei verschiedene Bit Längen, allerdings werden in TLS nur 128Bit und
256Bit eingesetzt.
RSA ist ein Kryptosystem von Rivest, Shamir und Adelman welches eine asymmetrisches
Verschlüsselungsverfahren darstellt und meist in Verbindung mit Zertifikatssystemen zum
Einsatz kommt. Es wird empfohlen bei langen Laufzeiten eine Schlüssellänge von 15360Bit
zu verwenden.
ECDH wird benötigt um einen geheimen Schlüssel zu erzeugen bei dem kein sicherer
Kanal zur Verfügung steht. Dabei nehmen die Verbindungspartner einen öffentlichen und
einen geheimen Parameter. Diese werden ausgetauscht und der Gegenüber kann mit seinem
geheimen Schlüssel die Nachricht vom Sender entschlüsseln. Das EC steht hier für das eine
Elliptic Curve Cryptography verwendet wird.
8
CBC ist das Verfahren für die Block Erzeugung und im Anschluss mit dem AES erstellten Schlüssel XOR Verknüpft.
Es wird zuerst mit ECDH ein Schlüssel generiert. Im Anschluss sendet der Server das
RSA Zertifikat, je nach Einstellung kann der Server auch ein Zertifikat vom Client verlangen.
Diese werden von dem jeweiligen Partner überprüft der das Zertifikat bekommen hat und
anschließen wird dann auf die symmetrische Verschlüsselung gewechselt (AES128).
4.2
Record Protokoll
Das Record Protokoll stellt die Schnittstelle zwischen TCP und dem TLS-Protokoll (Socket)
dar.
Wie in der 2.Figur weiter oben dargestellt, erkennt man das alle Daten von den darüber
liegenden Protokollen in das Record Protokoll einfließen.
Die Mechanismen Komprimierung, Authentifizierung und Verschlüsselung erfolgen erst nach
einem erfolgreichen Schlüsselaustausch.
Zu Beginn werden die Anwendungsdaten segmentiert und anschließend komprimiert. Daraus
wird dann eine Checksumme erstellt und angehängt. Zum Schluss wird dann das ganze
Segment verschlüsselt. Die Vorgaben für den ganzen Ablauf kommen durch die Chiper-Suite
zustande. Diese enthält die Datenstrucktur wie auch die Algorithmen, die für den Ablauf
relevant sind. [Sch05, Seite 286 ff]
Figure 3: TLS Record Layer [Sch05]
9
4.3
Application Data Protokoll
Die Daten von der darüberliegenden Schicht (z.B. HTTP) werden eins zu eins übernommen
und vom Record Protocol fragmentiert, komprimiert und anschließend verschlüsselt.
4.4
Alert Protokoll
Das Alert Protokoll ist für die Warn- und Fehlermeldungen zuständig. Durch die entsprechenden Meldungen können dem Kommunikationspartner die Informationen übergeben werden.
Je nach Fehler kann das sogar bis zum Verbindungsabbau führen, wenn die Sicherheit der
Verbindung gefährdet ist. Wie bereits erwähnt ist der Alert auf den Wert 0 gesetzt, wird
die Alert Message ”close notify” übertragen, so bedeutet das. Das der Empfänger bestätigt
keine Nachrichten mehr unter dieser Verbindung zu senden.
4.5
Handshake Protokoll
Das Handshake-Protokoll dient zum aushandeln der Sicherheitsparameter zwischen Client
und Server beim Verbindungsaufbau. Dabei kommt ein 4-way Handshake mit den folgenden
Nachrichten zustande.
1. Client Hello
2. Server Hello (Server Key Exchange, Certificate, Certificate Request) Server Hello Done
3. Client Key Exchange, Finished (Certificate, Certifcate Verify) —Change Chipher Spec
4. Finished — Change Chipher Spec
Die Nachrichten die in Klammer stehen sind optional und können an die ersten Nachricht
in der Zeile mit hinzugefügt werden. Bei den Hello Nachrichten geht es darum den Algorithmus(Chipher Suite) auzuhandeln und die Zufallszahl auszutauschen. Die Key Exchange
Nachrichten enhält Premaster-Secret welches später sich zu einen Master-Secret ableitet.
Durch die Finished-Nachrichten laden beide Endsysteme ”Change Chipher Spec” und sind
ab den punkt verschlüsselt. [HAN]
Der detalierte Ablauf wird im späteren Kapitel näher erklärt.
4.6
Change CipherSpec
Bei Change CipherSpec handelt sich um eine 1x Byte große Nachricht in der bestätigt wird,
das ab sofort die ausgehandelte CipherSuite angewendet wird. Da bei einer Nachricht von
gleichem Typ das Paket zusammengefasst werden kann, wird das Change Chipher Spec als
seperates Protokoll verwendet. [SEM]
10
5
Protokoll Aufbau in Wireshark
Um den Aufbau anschaulicher und Praxis näher zu gestallten, wird an dieser Stelle mittels
Wireshark, zwei TLS Pakete eingebunden und näher beschrieben. Diese Pakete sind die Ersten die bei einer Kommunikation mittels TLS von Server wie auch Client gesendet werden.
Dabei präsentiert der Client was für Mittel ihm zur Verfügung stehen und teilt dieses dem
Server mit.
Näheres zur Verbidungsaufbau finden Sie in den kommenden Kapiteln.
5.1
Client Hello
In der folgenden Figur zeigen wir wie das TLS Protokoll anhand einer Wireshark-Aufzeichnung
aufgebaut ist.
Die erste Nachricht kommt vom Client und heißt ”Client Hello”. Der Hex-Code 0x0300 ist
die SSLv3 also die letzte SSL Versionsnummer. Danach kam die Version TLSv1.0(0x0301)
bei der, der Hex-Code von SSL fortläuft.
Figure 4: Client Hello
11
Das ist die erste TLS Message die vom Client gesendet wird. In der Aufzählung wird das
Protokoll näher erläutert:
• Version: Hier gibt der Client die Version an, mit der er kommunizieren kann.
• Session ID: Ist die gewünschte Session ID, die bei der ersten Nachricht leer ist.
• Chipher Suites: In diesen Abschnitt teilt der Client dem Server mit, welche CipherSuite er verwenden kann.
• Compression Method: Kann zu Beginn leer sein. Normalerweise stehen hier die
Informationen über die Komprimierungs-Methoden die der Client verwenden kann.
12
5.2
Server Hello
Die Antwort auf die erste Nachricht vom Client ist dann das ”Server Hello”. Hier werden
dann die Verfahren vom Server aus festgelegt.
Figure 5: Server Hello
• Protocol Version: Auswahl der Version (in der Regel die höchste die der Client
unterstützt.
• Session ID: Wenn der Client bereits eine Session ID mit schickt, schaut der Server
ob er diese ID in seinem Cache findet. Wenn das zutrifft wird die gleiche Session ID
wieder zurück geschickt. Ist dies nicht der Fall dann wird die Session beendet.
• Chipher Suite: Der Server wählt sich eine Chiper Suite vom Client aus.
• Compression Method: Wählt ein Kompremierungsverfahren aus.
• Certificate Request: Der Server sendet eine Liste von allen Zertifikaten die ihm zur
Verfügung stehen.
13
6
6.1
Trust Center und Zertifikate
Trust Center (CA)
Bei einem Trust Center oder Certification Authority handelt es sich um eine Zertifizierungsstelle,
welche digitale Zertifikate ausstellt, verwaltet und sperrt.
Darüber hinaus signiert die Stelle öffentliche Schlüssel und veröffentlicht diese.
Anbieter von Inhalten via Webservern können sich so im Internet mit einer unabhängiger
Stelle gegenüber Anfragen identifizieren. Mit dem digitalen Zertifikat werden die Echtheit
des öffentlichen Schlüssels und die digitale Signatur zertifiziert. Die Bundesnetzagentur oder
der Deutsche Forschungsnetz Verein (DFN) sind nur zwei von sehr vielen solcher Zertifizierungsstelle. [CA], [SSLb]
6.2
Zertifikate
Ein digitales Zertifikat soll Authentizität und Integrität in Verbindungen (Client und Server)
gewährleisten. Die sehr weit verbreiteten X.509 Zertifikate werden in Zusammenhang mit
dem Public-Key Verfahren eingesetzt. Von einem CA zertifiziert kann so ein Zertifikat für
die TLS - Verbindung genutzt werden. In der Abbildung a) ist der Aufbau eines solchen Zertifikats dargestellt. In Abbildung b) ist der Ausschnitt eines in Google Chrome hinterlegten
Zertifikats zu sehen, der HS-AAlen. [SSLb], [ZER]
(a) X.509
(b) HSAAlenZertifikat
Figure 6: Zertifikate [SSLb]
14
7
Funktionsweise
7.1
Voraussetzung für TLS-Verbindung mittels Zertifikate und
Public-Key Verfahren
Um eine sichere Übertragung im Internet zu gewährleisten sind Vertraulichkeit, Integrität
(nicht Veränderbarkeit), Verbindlichkeit und Authentizität (sichere Absender-Identifikation)
erforderlich. Das SSL bzw. TLS-Protokoll erreicht dies durch zwei Verschlüsselungsverfahren.
• Das asymmetrische Public-Key-Verfahren wird während des Handshake angewandt
und verwendet unter anderem RSA zur Verschlüsselung und Authentifizierung.
• Nach dessen erfolgreichem Abschluss wird auf eine symmetrische AES (128 Bit, DES,
Triple-DES-Verschlüsselung gesetzt, welche den Session key erzeugt.
Diese Methodik nutzt dafür elektronische Zertifikate die von einem bereits erwähnten
Trust Center oder auch Certification Authority (CA) ausgestellt werden. Dadurch wird die
Identität eines Endpunktes also Computer oder Person verifiziert. Ein Trust Center stellt
somit einen öffentlichen und privaten Schlüssel sowie das Zertifikat bereit. Diese Zertifikate
sind oft schon als Rootzertifikate in den Browsern hinterlegt, abhängig von dem Browser
sind dies dann mehr oder weniger. Eine entsprechende Meldung wird angezeigt, sollte ein
Zertifikat fehlen. Die Server wiederum erhalten ihr Zertifikat und einen entsprechenden
öffentlichen Schlüssel auf Anfrage an ein CA. Um nun das Serverzertifikat zu sichern, unterschreibt das CA mit seinem privaten Schlüssel das Zertifikat des Servers.
[SSLa], [SSLb], [Sch05, Seite 284]
7.2
Beginn eines Verbindungsaufbaus (mit TLS-Handshake-Verfahren)
Für den dann beginnenden Verbindungsaufbau sendet der Client eine ”Hello Client” Nachricht
an den Server und handelt die Kommunikationsbedingungen aus.
Diese Vorgang wird als Handshake-Verfahren bezeichnet und wird über das TLS-HandshakeProtokoll abgewickelt. Zu den ausgehandelten Bedingungen in dieser ersten Phase zählen die
Festlegung der jeweils unterstützten Cipher Suites (Verweis auf Tripel: Verschlüsselungsalgorithmus, Schlüsselaustausch, Message Authentication Mode)und die zu verwendende Version
(TLS 1.0, TLS 1.1 ...)zudem werden 32 Bytes bestehend aus 4 Bytes timestamp + 28 Bytes
große zufällige Daten von Client und Server ausgetauscht(clientHello.random) um in einem
späteren Schritt daraus den Master-key zu generieren.
In der nun folgenden zweiten Phase sendet der Server wiederum ein ”Server Hello” und sein
Serverzertifikat and den Client. Dieses von dem Server versendete Zertifikat, wurde von
einem Trust Center durch dessen private key signiert und kann dann mit dem public key
des Client geprüft werden. Der public key des im Browser des Client hinterlegten Zertifikats
wurde wiederum von einem Trust Center zur Verfügung gestellt. Durch diesen Abgleich
kann der Client sicher sein, dass es sich um den richtigen Server handelt. Zusätzlich kann
der Server auch vom Client ein Zertifikat zur Gegenauthentifizierung anfordern.
Durch die dritte Phase des Handshake sendet der Client dem Server einen 48 Bytes großen
Pre-Master-key zu und leitet ein sogenanntes Challenge-Response-Verfahren ein. Dieses
15
Pre-Master-Secret wurde zuvor mit dem public-key des vom Server übermittelten Zertifikats
verschlüsselt, die Authentifizierung erfolgt dann nur, wenn der Server auch im Besitz des
dazu passenden private key ist.
Die vierte und letzte Handshake Phase kann nun durch die korrekte Entschlüsselung des
Pre-Master-Secrets berechnet werden.
Die Berechnung beinhaltet die je 32 Byte Zufallsdaten von Client und Server aus der ersten
Phase. Zuletzt wird an den Client und daraufhin an den Server eine verschlüsselte Client bzw.
ServerFinished Meldung übertragen, welche die Werte der Hashfunktionen MD5 und SHA-1
aus den bisherigen ausgetauschten Handshake-Nachrichten enthält. Nun können Beide die
Nachrichten je für sich entschlüsseln. Wenn sichergestellt wurde, das die Identitäten richtig
sind, kann die eigentliche Datenübermittlung beginnen.
[Zah06, Seite 314 ff], [Sch05, Seite 276 ff]
7.3
Eigentliche Übertragung,
Der Client erstellt nun einen Session key der mit dem public key des Servers verschlüsselt
wird, dieser Session key wird dann an den Server versandt. Mit dem private key des Servers
kann dieser nun den symmetrisch chiffrierten Session key entschlüsseln. Durch diesen Vorgang besitzen Client und Server nun gemeinsam den Session key und sind in der Lage symmetrisch verschlüsselt zu kommunizieren.
Auf diese Weise können beide Parteien nun ihre Nachrichten jeweils mit dem Session key
verschlüsseln oder entschlüsseln und sicher ihre Daten übertragen.
Der Vorteil einer symmetrischen Verschlüsselung während des Datenaustausches ist das sehr
schnelle ver- und entschlüsseln des Session key im Vergleich zu den weit aufwendigeren asymmetrischen Methoden.
[SSLb], [Zah06, Seite 316]
Figure 7: SessionKey
16
7.4
Wiederaufnahme einer TLS-Verbindung
TLS erlaubt ein Wiederaufnehmen einer Verbindung um den enormen Rechenaufwand bei
der Zertifikatsüberprüfung und der Berechnung des Schlüsselmaterials einzusparen. Dies
muss vom Server angeboten werden.
Durch die Verwendung des bereits bestehenden Master-Secrets, kann dieser mit der jeweils
neuen Zufallszahl kombiniert werden. In der Server-Hallo Nachricht ist eine Sitzungs-ID
(session-ID siehe Seite 13) vermerkt, die es dem Client ermöglicht später bei Wiederverwendung dieser Sitzungs-ID auf die gleiche Verbindung aufzubauen und das ohne ein erneutes
ausführen der aufwendigen asymmetrischen Operationen. In diesem Fall wird direkt neues
Schlüsselmaterial erzeugt. [Sch05, Seite 285]
7.5
Open Source Implementierungen von TLS (OpenSSL und GnuTLS
• OpenSSL ist ein Open-Source toolkit das Programmbibliotheken wie die crypto-Bibliothek
für das Nutzen des TLS Protokolls in der Entwicklung von Netzwerkanwendungen zur
Verfügung stellt.
• GnuTLS unterscheidet sich kaum von der Funktionalität zu OpenSSL. Im Gegensatz zu
OpenSSL ist GnuTLS GPL (General Public License) lizensiert und kann damit in GPLlizensierte Software eingebunden werden. Zusätzlich zu den verfügbaren Funktionen
unterstützt GnuTLS z.B auch OpenPGP-Schlüssel.
[Zah06, Seite 323] [GNU]
7.6
Anwendungsfälle
An folgenden Beispielen werden Umsetzungen von SSL/TLS dargestellt. Die Endung S steht
hier jeweils für Secure.
7.6.1
HTTPS
Eine der ersten Lösungen für das SSL-Protokoll ist die Anwendung auf Webservern und
Webbrowsern um vor allem sensible Onlinebanking-Verbindungen zu sichern. Diese Webserver verlangen zwingend eine SSL/ TLS - Verbindung. Der https - Service wird generell
auf Port: 443 bereitgestellt.
7.6.2
SMTPS
Das Simple Mail Transfer Protocol (SMTP) was einen Teil des Mailverkehrs im Internet
regelt vor allem die Zugangskontrolle des Server-Dienstes. Standardmäßig lauscht der Server
hier auf Port 25.
17
7.6.3
IMAPS
Das Internet Message Access Protocol (IMAP) stellt ein Netzwerkdateisystem für e-mails
bereit. SSL/ TLS wird auf Port 993 als IMAPS genutzt.
7.6.4
POP3S
Das Post Office Protocol (POP3) regelt das ”abholen” von e-mails auf einem E-mail-Server.
Auf Port 110 wird dieser Dienst ausgeführt.
18
8
8.1
Schwachstellen
DHE EXPORT
Mitte des Jahres 2015 wurde eine Schwachstelle des TLS (Version 1.1) Verfahrens beim
Diffie-Hellman-Schlüsselaustausch entdeckt. Dies betrifft alle Betriebssysteme die TLS mit
”DHE EXPORT” Verschlüsselungsverfahren in Verwendung haben.
Die Voraussetzungen für den Angriff ist der Zugang zum lokalen Netzwerk. Dabei handelt
es sich hierbei um einen Man-in-the-middle Attacke, die Remote auf dem TLS-Handshake
stattfindet. Die Schwachstelle ist ein Entwurfsfehler bei der Implementierung von diesem
Verfahren.
Ein Angreifer kann dadurch die Kommunikation abhören und die ausgetauschten Passwörter
abfangen, sowie die Daten manipulieren. Dazu braucht der Angreifer lediglich den Rückfall
auf eine unsichere Schlüssellänge zu veranlassen.
Allerdings ist der Angriff sehr aufwendig, sodass dieser nicht geeignet ist für flächendeckende
Angriffe. Weiterhin kommt dem Angreifer zu Hilfe das in sehr vielen DHE (Diffie-Hellman)
Implementierungen die gleichen Primzahlen zum Einsatz kommen. Was ihm ermöglicht die
Schlüssel vorab zu berechnen und damit viel Zeit spart.
Die Lösung ist den Servern die Verwendung von ”DHE Export”-Verschlüsselungsverfahren
zu deaktivieren und dafür ECDHE (Elliptic-Curve Diffie-Hellman) zu verwenden. [UNI]
8.2
Heartbleed-Exploit
Ein trivialer Fehler mit großen Folgen. Der so genannte Heartbleed-Exploit unter TLS
basiert darauf, dass einer der Kommunikationspartner Server oder Client in regelmäßigen
Abständen ein Paket mit beliebigen Daten sendet, sodass die Verbindung am Leben erhalten
wird.
Bei OpenSSL war es jedoch so das die Länge des Payloads nicht überprüft wurde d.h. das,
das Datenpaket beliebig groß wird. Die Pakete werden einfach entgegen genommen ohne das
eine Überprüfung statt findet. Wenn der Client eine falsche Größe des Paketes angibt kann
dieser dadurch die Daten von dem Server einfach auslesen.
Ablauf des Angriffs:
Der Client behauptet im Heartbleed-Paket welches zum Server geschickt wird das sein Paket
16KByte groß sei, allerdings ist es in echt nur 1 KByte groß. Der Server überprüft die
Nachricht nicht weiter und füllt das Datenpaket mit seinen Daten auf, sodass es 16KByte
groß ist. Darauf gefolgt sendet dieser die Nachricht wieder zurück zum Client. Wenn es
schlecht läuft stehen Benutzernamen oder auch Passwörter in den vom Server zugesandten
Daten.
Allerdings funktioniert die Attacke nur lediglich unter TLS 1.0, die nicht mehr ganz aktuell
ist. [HBA]
19
9
Zusammenfassung und Fazit
In der Ausarbeitung wurde verdeutlicht, das die Umsetzung des Konzeptes des TLS eine der
wichtigsten Sicherungs-Mechanismen für den Datenverkehr im Internet ist.
Es wurde dargelegt wo der Einsatz des Protokolls erfolgt und wie Inhalt und Ablauf des Dienstes umgesetzt werden. Mit der Vertiefung der Punkte wie zum Beispiel der Aufbau einer
Verbindung und der darin stattfindenden Prozesse können Rückschlüsse auf die Kernpunkte
der Sicherheit genommen werden, welche bei TLS eingesetzt werden.
Weiterhin wurden Themen wie elektronische Zertifikate, Verschlüsselungsverfahren und Protokolle der Anwendungs- und Transportschicht erläutert im Kontext der Verzahnung mit
TLS. Abschließend wurde im Kapitel Schwachstellen auch die Wichtigkeit der ständigen
Neubeurteilung der Implementierung dargestellt um den Dienst auch zukünftig sicher einsetzten zu können.
Damit ist mit dieser Arbeit ein fundierter Einblick in Aufbau, Ablauf und Bedeutung des
TLS Protokolls gegeben.
Vertiefungen in Themen wie zum Beispiel Verschlüsselung oder explizite Fehler des Protokolls
bei bestimmten Angriffsmethoden konnten aufgrund des Rahmens nicht näher behandelt
werden.
10
Ausblick
Da TLS und IPsec heutzutage noch am weitesten verbreitet sind wird hier noch ein kurzer
Überblick darüber gegeben.
Aufgrund das TLS auf der Anwendungsschicht arbeitet hat es den großen Vorteil das es quasi
Betriebssystem unabhängig ist. In Gegensatz zu IPsec, das eine Änderung des Betriebssystem benötigt da es auf der Vermittlungsschicht aufsetzt. Beim Schlüsselaustausch ist TLS
zudem komfortabler da in der Lösung alles integriert ist, in konträr zu IPsec welches hierzu
zusätzliche Software benötigt.
Die Einsatz Varianten sind bei beiden Protokollen Netz-zu-Netz-Sicherung wie auch Endezu-Ende-Sicherung verwendbar, allerdings ist bei TLS meist die zweite Variante gängig da
Netz-zu-Netz den Zusatz Software benötigt. Da es in Kombination zu Konflikten kommen
kann wurde das DTLS entwickelt um unabhängig von TCP die TLS Verschlüsselung anbieten zu können. Der unterschiedliche Einsatz in verschiedenen Schichten wird auch bewusst,
wenn man die Firewall regeln modifizieren muss damit IPsec funktionieren soll. Daher ist
das TLS wesentlich komfortabler und schneller einzurichten. Allerdings bietet es schlechtere
Methoden zur Fehlererkennung im Vergleich zu Ipsec.
Woraufhin wir zu dem Entschluss kommen das Dauerhaft VPN Verbindungen besser mit
IPsec realisiert werden. Die Zugänge von Außerhalb z.B. von einer Geschäftsreise können
mittels TLS dafür aber besser umgesetzt werden, aufgrund der Unabhängigkeit des Betriebssystems.
Das TLS Protokoll ist nach wie vor eine gute Lösung für das sichern von Client - Server Verbindungen. Durch ständige Aktualisierungen des Protokolls welche durch neue RFC ()
Einträge verfolgbar sind, kann es auch zukünftig sicher eingesetzt werden.
20
11
Anhang
Quellverzeichnis
[Abb]
OSI
TLS.
Quelle:http://orm-chimera-prod.s3.amazonaws.com/
1230000000545/images/hpbn_0401.png, . – Accessed: 2016-06-07
[AuI]
exChiperSuite.
http://www.rn.inf.tu-dresden.de/hara/arbeiten/
BA_2014_Thiem_-_Auswahl_und_Implementierung_geeigneter_
kryptographischer_Verfahren_fuer_die_verschluesselte_und_signierte_
Proxy-Kommunikation.pdf, . – Accessed: 2016-05-13
[CA]
CA Zertifizierungsstelle.
http://www.itwissen.info/definition/lexikon/
Zertifizierungsstelle-CA-certification-authority.html, . –
Accessed:
2016-05-23
[ER12] E. Rescorla, N. M.: DTLS. https://tools.ietf.org/html/rfc6347, 2012. –
Accessed: 2016-04-28
[GNU] GnuTLS. https://de.wikipedia.org/wiki/GnuTLS, . – Accessed: 2016-05-16
[HAN] TLS Protocol. http://einstein.informatik.uni-oldenburg.de/rechnernetze/
handshake.htm, . – Accessed: 2016-06-07
[HBA] Heartbleed.
http://www.heise.de/security/artikel/
So-funktioniert-der-Heartbleed-Exploit-2168010.html, . –
Accessed:
2016-05-13
[Jr06]
Jr, Nobody: My Article. 2006
[KOM] tls-transport-layer-security.
http://www.elektronik-kompendium.de/news/
tls-transport-layer-security/, . – Accessed: 2016-04-013
[REP]
TLS 1.0 vs SSL 3.0. http://www.repges.net/SSL/UNTERS_1/unters_1.HTM, . –
Accessed: 2016-06-07
[Sch05] Schöller, Roland Bless Stefan Mink Erik-Oliver Blaß Michael Conrad HansJoachim Hof Kendy KutznerM̃.: Sichere Netzwerkkommunikation. Springer-Verlag
Berlin Heidelberg, 2005. – ISBN 3540218459
[SEM] TLS
SSL
Seminar
Arbeit.
http://docplayer.org/
2903915-Seminararbeit-zu-ssl-tls.html, . – Accessed: 2016-06-07
[SSLa] Secure Socket Layer.
http://www.elektronik-kompendium.de/sites/net/
0902281.htm, . – Accessed: 2016-05-13
[SSLb] SSLTelematik-Institut.
%http://www.telematik-institut.org/ti-trust_
center/SSL-visualisierung.html, . – Accessed: 2016-06-01
[UNI]
Export Attack.
https://cert.uni-stuttgart.de/ticker/article.php?mid=
1732, . – Accessed: 2016-06-07
21
[Win]
MS Windows NT Kernel Description.
http://web.archive.org/web/
20080207010024/http://www.808multimedia.com/winnt/kernel.htm,
.
–
Accessed: 2010-09-30
[Zah06] Zahn, Markus: Unix-Netzwerkprogrammierung. Springer-Verlag Berlin Heidelberg,
2006. – ISBN 3540002995
[ZER]
CertificateAuthority.
http://winfwiki.wi-fom.de/index.php/
Implementierung_von_Open-Source_VPN-Systemen_am_Beispiel_von_OpenVPN,
. – Accessed: 20160427
22
Abbildungsverzeichnis
1
2
3
4
5
6
7
OSI TLS [Abb] . . . . . . .
TLS-Schichtenmodel [SEM]
TLS Record Layer [Sch05] .
Client Hello . . . . . . . . .
Server Hello . . . . . . . . .
Zertifikate [SSLb] . . . . . .
SessionKey . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Abkürzungsverzeichnis
3DES
Triple Data Encryption Standard
AES
Advanced Encryption Standard
CBC
Cipher Block Chaining
DHE
DTLS
Diffie-Hellman
Datagram Transport Layer Security
ECDHE
elliptic curve diffie-hellman
HTTP
Hypertext Transfer Protocol
IETF
Internet Engeneering Task Force
OSI-Schichtenmodell
Open Systems Interconnection Model
RFC
RSA
Request for Comments
Rivest, Shamir und Adleman
S-HTTP
SSL
Secure-Hypertext Transport Protokoll
Secure Socket Layer
TCP
TLS
Transmission Control Protocol
Transport Layer Security
UDP
User Datagram Protocol
23
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
7
9
11
13
14
16