Transportsicherheit SSL TLS, HTTPS

Inhaltsverzeichnis

1 Einfuhrung

2 Authentisierungsmethoden im HTTP
2.1 Basic Authentication
2.2 Digest Access Authentication

3 SSL / TLS
3.1 Historie
3.2 TLS Protokollubersicht
3.3 Record Layer Protokoll
3.3.1 Ablauf einer Verschltisselung
3.3.2 Ein Record Layer Datenpacket (Record)
3.4 Handshake Protokoll
3.4.1 Uberblick: Ablauf eines Handshakes
3.4.2 HelloRequest
3.4.3 ClientHello
3.4.4 ServerHello
3.4.5 Certificate
3.4.6 CertificateRequest
3.4.7 ServerHelloDone
3.4.8 ClientKeyExchange
3.4.9 CertificateVerify
3.4.10 ChangeCipherSpec
3.4.11 Finished
3.4.12 Verkurzter Handshake
3.5 Change-Cipher-Spec Protokoll
3.6 Alert Protokoll
3.7 Angriffe auf SSL/TLS

4 Ausblick

Abbildungsverzeichnis

2.1 Aufforderung zur Authentisierung durch den Browser

2.2 Ablauf einer Basic-Authentisierung

2.3 Ablauf einer Digest Access Authentication

3.1 Die TLS-Protokolle im Schichtenzusammenhang

3.2 Der Record-Layer im TCP/IP-Stack

3.3 Ablauf einer Verschltisselung im Record Layer

3.4 Darstellung eines Records

3.5 Ablauf eines TLS-Handshakes

3.6 Ein Zertifikat im Browser

3.7 Berechnung des Master Secrets

3.8 Ablauf eines verkurzten Handshakes

3.9 Die ChangeCipherSpec Nachricht

3.10 Ethereal Protokollmitschnitt eines Handshakes

3.11 Die Alert-Protokoll Nachricht

3.12 Ethereal Alert Protokollmitschnitt

Abkiirzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einfuhrung

Im heutigen Zeitalter des Internets gehen taglich wichtige Informationen uber die elek- trischen Leitungen. Eine wichtige Informationsquelle von ca. 48 % der Frauen sowie ca. 63 % der Manner in Deutschland ist in der heutigen Zeit das World Wide Web (WWW) 1 in welchem hauptsachlich das Hypertext Transfer Protocoll (HTTP) eingesetzt wird. Um wichtige, vertrauenswurdige Informationen wie z.B. Bankuberweisungen oder Wa- reneinkaufe zu schutzen und deren Sicherheit zu gewahrleisten wurden einige Methoden entwickelt. Der am weitesten verbreitete Standard ist das SSL- bzw. TLS-Protokoll, welches in Kombination mit dem HTTP als HTTPS-Protokoll genutzt wird. Das ,,S“ hierbei steht fur ,,Secure“. Diese Arbeit stellt die Authentisierungsmethoden direkt im HTTP-Protokoll als Grundlage vor und geht dann tiefer in die TLS-Protokolle ein.

2 Authentisierungsmethoden im HTTP

In HTTP/1.17wurden zwei Authentisierungsmethoden aufgefuhrt. Zum ersten die Basic Authentication, die schon im HTTP/1.04aufgenommen wurde, und zum zweiten die Digest Access Authentication. Diese beiden Methoden werden in8spezifiziert und im folgenden naher betrachtet.

2.1 Basic Authentication

In HTTP/1.04wird als einzige Moglichkeit eine HTTP-Anfrage vor unautorisiertem Zugriff zu schutzen die Basic Authentication spezifiziert. Schon hier wird vor Sicher- heitsmangeln gewarnt, da der Benutzername sowie das Passwort im Klartext ubertragen werden. Es sollte nur genutzt werden, wenn man dem Netzbetreiber vertrauen kann und kein offenes Netzwerk genutzt wird.

Ablauf. Zu Beginn einer Authentisierung stellt der Client eine Anfrage an eine bestimm- te HTML-Seite. Diese Anfrage wird mit dem HTTP-Kommando ,,GET“ durchgefuhrt.

Der Client vermutet hier noch nicht, dass diese Seite zugriffsgeschutzt ist. Nach die- sem Aufruf priift der Server die Seite und stellt fest, dass eine Authentisierung notig ist. Er schickt eine Fehlermeldung mit dem Code 401 (Authorization Required) an den Client zuruck. Neben der Fehlermeldung befindet sich im Header des Server-Requests beispielsweise die Zeile:

WWW-Authenticate: Basic realm="Bitte Passwort fur Webanwendung XYZ eingeben!"

Dadurch teilt der Server dem Client mit, welche Art von Authentisierung gefordert ist. Durch den optionalen Parameter ,,realm“ sendet der Server dem Client zusatzlich eine explizite Meldung speziell fuar diese HTML-Seite. Die Interpretation dieser Meldung kann dann im Browser aahnlich wie in Abbildung 2.1 aussehen. Hier fragt der Browser sofort die benatigten Zugangsdaten ab.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1: Aufforderung zur Authentisierung durch den Browser

Nach der Eingabe eines Benutzernamens und des dazugehorigen Passworts codiert der Browser beide Werte durch eine Base64-Codierung11und schreibt sie in den Header der folgenden HTTP-Anfrage an den Server. Dabei sendet er genau wie bei der ers- ten Anfrage durch die ,,GET“-Methode die gewunschte HTML-Seite und zusatzlich die folgende Zeile:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Hier wird zuerst nochmals die Authentisierungsart sowie danach die Base64-Codierung des Usernamens und Passworts ubermittelt.

Base64 ist eine Codierung mit Prufsummenbildung, sodass eventuelle Ubertragungsfehler erkannt werden konnen. Eine Manipulation der Codierung ist jedoch jederzeit moglich, da der Algorithmus zur Erstellung veroffentlicht wurde und dadurch jeder Angreifer den Usernamen oder das Passwort andern und erneut eine giiltige Priifusumme errech- nen kann. Der Algorithmus zum dekodieren der Base64-Codierung ist ebenfalls bekannt, sodass ein Angreifer, der die Nachricht abfaongt jederzeit durch die Codierung den User- namen sowie das zugehorige Passwort leicht ermitteln kann.11

Nach dem Verifizieren der Zugangsdaten sendet der Server dann die gewunschte HTML- Seite zum Client. Bei jeder folgenden Anfrage des Clients sendet dieser immer Usernamen sowie Passwort im HTTP-Header mit, sodass dadurch die Chancen eines Angreifers die Benutzerdaten abzufangen erhoht werden. Einen beispielhafen Ablauf einer Basic Authentication beschreibt Abbildung 2.2.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2: Ablauf einer Basic-Authentisierung (entnommen aus13)

2.2 Digest Access Authentication

Die Digest Access Authentication wurde erst nach der Basic Authentication mit HTT­P/1.1 eingefuhrt und sollte die ,,offensichtlichsten Sicherheitsmangel beseitigen.“13Die Digest Access Authentication ist eine klassische Challenge-Response-Authentisierung. Der Ablauf der Digest Access Authentication beschreibt Abbildung 2.3.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.3: Ablauf einer Digest Access Authentication

Zu Beginn des Datenstroms steht - wie bei der Basic Authentication - die Client-Anfrage mit der ,,GET“-Methode sowie der gewunschten HTML-Seite. Nach der Anfrage sendet der Server - ahnlich wie bei der Basic Authentication - den Fehlercode 401 (Unauthori­zed). Danach folgen noch einige weitere Header-Attribute, die liber die Basic Authenti­cation hinausgehen:

Abbildung in dieser Leseprobe nicht enthalten

(Beispiel entnommen aus8)

In Zeile 2 wird nun ,,Digest“ anstatt ,,Basic“ als Authentisierungsart angegeben. Die Variable ,,realm“ soll dem Client anzeigen fur welche Seite er sich authentisieren soll. Die Werte ,,nonce“ sowie ,,opaque“ sind Zufallswerte in base64- oder Hexadezimal- Codierung. Der ,,nonce“ Wert soll bei jeder Fehlercode 401 Ruckgabe des Servers er- neuert und jeweils vom Client bei dessen Response identisch zuruckgegeben werden. ,,opaque“ stellt den ,, Challenge “-Wert des Challenge-and-Response Protokolls dar. Er wird vom Server generiert und bei jeder Ubertragung sowohl vom Client als auch vom Server bei Anfragen auf den gleichen Authentisierungs-Raum ubermittelt. Nach der Ant- wort des Servers muss sich nun der Client authentisieren und die Response an den Server schicken:

Abbildung in dieser Leseprobe nicht enthalten

Die Response enthalt zusatzlich den Benutzernamen, die gewunschte HTML-Seite mit Pfad sowie den ,,response“-Wert, welcher implizit das Passwort zum angegebenen User beinhaltet. Der ,, response “-Wert wird wie folgt berechnet:

Abbildung in dieser Leseprobe nicht enthalten

Nach dem ubersenden an den Server ,,hashed“ dieser sein schon zuvor ,,gehashten“ Be­nutzernamen mit Passwort und ,,realm“-Wert aus der Passwortdatei mit dem ,,nonce“- Wert sowie der gewuanschten Seite und vergleicht diesen Wert mit dem response“-Wert des Clients. Bei Gleichheit erhalt der Client die gewunschte HTML-Seite zugesendet.

Bei der Digest Access Authentication ist es einem Angreifer nicht moaglich das Pass- wort durch Abhaoren der Leitung zu ermitteln, da dieses als Hashwert uabermittelt wird. Eine Hashfunktion (hier: MD5) ist eine Einwegfunktion. Daher kann durch die Einwegei- genschaft dieser Funktion praktisch kein x aus einem gegebenen Hashwert y berechnet werden, sodass gilt:

Abbildung in dieser Leseprobe nicht enthalten

Nach erfolgreicher Authentifizierung werden die Nutzdaten (z.B. eine HTML-Seite) im Klartext ubermittelt, sodass ein Angreifer diese Daten mithoren und aufzeichnen kann. Somit ist zwar das Passwort weiterhin geheim, die danach ubertragenen Daten jedoch nicht.

Diese Authentisierung ist aufgrund der immer noch grofien Sicherheitsmangel nicht sehr verbreitet, da fur nicht sicherheitskritische Anwendungen die Basic Authentication und fur sicherheitskritische Anwendungen eine Verschlusselung des kompletten HTTP- Datenverkehrs z.B. mit SSL/TLS oder VPN genutzt wird.

3 SSL / TLS

Da es durch das HTTP-Protkoll alleine keine MOglichkeit gibt, die tibertragenen Da- ten vollstandig zu verschltisseln, benotigt man einen anderen Ansatz zur Absicherung der Daten. Ein aktueller Ansatz ist SSL, eine Sicherungsschicht zwischen einem Anwen- dungsprotokoll z.B. HTTP sowie dem Transportprotokoll TCP. Durch diese zusatzliche Schicht und dem einfachen Aufbau ist SSL flexibel genug, um den Anforderungen der raschen Weiterentwicklungen gerecht zu werden. SSL/TLS ist aktuell der gangigste Si- cherheitsstandard im E-Commerce und wird bei der Ubertragung personlicher Daten im Internet, erst recht bei Kreditkartennummern, vom Kunden erwartet. SSL/TLS ist vor- wiegend bei HTTP vertreten, weitere bekannte Anwendungen sind z.B. POP3, SMTP, NNTP, IMAP, IRC, FTP aber auch VPN.

3.1 Historie

Im Jahr 1993 wurde der erste populare Webbrowser Mosaic vom National Center for Su­percomputing Applications (NSCA) entwickelt und veroffentlicht. Netscape Communica­tions begann daraufhin mit der Entwicklung ihres eigenen Webbrowsers und machte sich dabei auch Gedanken um die Web-Sicherheit. Als erstes Resultat daraus veroffentlichte Netscape im Jahr 1994 SSL 1.0. Ende 1995 wurde der erste Netscape Browser ,,Netscape Navigator“ schon mit SSL 2.0 veroffentlicht.14

SSL 2.0 hatte allerdings aufgrund des damals noch neuen Web-Sicherheitsaspektes noch einige Sicherheitsschwaochen. Die bekannteste wurde allerdings nur in der Referenzim- plementierung von Netscape gefunden, in der der Zufallszahlengenerator eine Schwdche hatte.

Des Weiteren war SSL 2.0 gegen ,,man-in-the-middle“ Attacken anfollig, sodass der An- greifer eine 40-Bit-Verschlusselung erzwingen konnte. Die USA erliefi Exportvorschriften, sodass Verschluosselungsschluossel nur maximal 40-Bit haben durften. Dadurch wurden die Schluossel zur Berechnung des MAC unsicher, da 40 Bit in heutiger Zeit durch einfaches ausprobieren zu knacken ist.13

Diese Sicherheitsmdngel wurden in der Version 3.0 behoben. Weiterhin wurden einige Funktionen aufgrund der Erfahrungen mit SSL 2.0 hinzugefugt. Bei SSL 2.0 war es nicht moglich den Verschlusselungsalgorithmus sowie den Schlussel wahrend der Verbindung zu wechseln. Bei SSL 3.0 kann nun durch einen erneuten ,,Handshake“ eine neue Ver- einbarung zwischen Client und Server getroffen werden. Aufierdem ist es seit SSL 3.0 nun erlaubt, mehrere Zertifikate im Handshake zu ubertragen und dadurch komplexere Public-Key-Infrastrukturen (PKI) zu ermoglichen.

Weitere Schlusselaustauschalgorithmen wie z.B. (Diffie-Hellman) wurden erganzt, um Alternativen zu dem patentierten RSA-Algorithmus zu geben.

Sobald die Daten durch SSL verschlusselt wurden, ist eine Komprimierung dieser Daten nicht mehr effektiv. Um die vorhandene Bandbreite besser zu nutzen ist es deshalb notig, eine Komprimierung vorher durchzufuhren. Dadurch wurde es in SSL 3.0 moglich, einen Kompressions-Algorithmus auszuhandeln. Fur SSL 3.0 gab es jedoch noch keine definierten Kompressionsalgorithmen. Ein Algorithmus wurde erst spater flir TLS 1.0 in9explizit definiert, wird aber aufgrund des hohen serverseitigen Performancebedarfs wenig genutzt.

In der Praxis wird allerdings oft die Kompression schon im HTTP-Protokoll durch- geftihrt, also vor der Ubergabe der Daten an den Record Layer. Ab SSL 3.0 konnen weiterhin mehrere Nachrichten (z.B. mehrere Handshake-Nachrichten (vgl. 3.4)) in einen SSL-Record verpackt werden.

SSL 2.0 wird in den aktuellen Browsern (z.B. Firefox 1.5) noch unterstutzt, sollte jedoch aufgrund der bekannten Sicherheitsmangeln deaktiviert werden.13

1995 wurde dann SSL 3.0 auf Basis von SSL 2.0 sowie Microsofts Private Communication Technology (PCT) veroffentlicht. Die Ubergabe der Weiterentwicklung von Netscape an die Internet Engineering Task Force (IETF), welche schon die Standards fur TCP und IP entwickelte, geschah 1996. Die erste Version der Weiterentwicklung von SSL veroffentlichte die IETF mit TLS 1.0 im Jahr 1999.

Die Unterschiede zwischen SSL 3.0 und TLS 1.0 sind nicht sehr grofi, sodass TLS 1.0 auch als SSL 3.1 bezeichnet wird. Ein weiterer Grund fur diese Versionierung ist die eventuell aufkommende Verwirrung, wenn im Versionsfeld des SSL-Records plotzlich mit 1.0 eine niedrigere Version stehen wuorde.

TLS ist serverseitig sowie in jedem aktuellen Browser goangiger Standard und wird bei SSL/TLS abgesicherten Verbindungen aktuell auch meist im Handshake ausgehandelt. Da die Bezeichnung SSL noch bekannter ist, wird oft TLS gemeint, wenn von SSL gesprochen wird.

Im Rahmen einiger Open-Source-Projekte gibt es Implementierungen wie beispielsweise OpenSSL¹oder GnuTLS².

3.2 TLS Protokollubersicht

TLS besteht aus insgesamt 4 Protokollen:

- Handshake Protokoll
- Change-Cipher-Spec Protokoll
- Alert Protokoll
- Record Layer Protokoll

Abbildung 3.1 zeigt die Protokolle im Zusammenhang mit dem Schichtenmodell. In den folgenden Kapiteln werden die einzelnen Protokolle von TLS 1.0 naher beschrieben und mit Beispielen erganzt. Sobald Unterschiede zum SSL 3.0 Standard auftreten, werden diese erlautert.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.1: Die TLS-Protokolle im Schichtenzusammenhang (entnommen aus13)

3.3 Record Layer Protokoll

Der Record Layer ist fur die endgultige Verschlusselung der Pakete zustandig. Er ist eine eigene Schicht im Schichtenmodell und zwischen dem Anwendungsprotokoll (z.B. HTTP) sowie dem Transportprotokoll TCP eingeschoben (Abbildung 3.2).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.2: Der Record-Layer im TCP/IP-Protokollstack (entnommen aus13)

3.3.1 Ablauf einer Verschlusselung

Der Ablauf einer Verschlusselung auf dem Record Layer wird in Abbildung 3.3 darge- stellt. Die HTTP-Anfragen und Antworten werden in Datenpakete gleicher Grofie (je- doch maximal 214 Bytes) zerlegt. Diese Datenpakete werden ,,Records“ genannt. Nach

[...]

¹http://www.openssl.org/

²http://www.gnu.org/software/gnutls/