Vertraulichkeit und Integrität. Kommunikationssicherheit durch Secure Sockets Layer (SSL) und Transport Layer Security (TSL)

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

1 Einleitung

2 Hypertext Transfer Protocol
2.1 Authentifizeirungsmethoden in HTTP
2.1.1 HTTP Basic Authentication
2.1.2 HTTP Digest Access Authentication

3 Secure Sockets Layer und Transport Layer Security
3.1 Hypertext Transfer Protocol Secure
3.1.1 Secure HTTP
3.2 Weitere Protokolle über SSL
3.3 SSL Implementierungen
3.4 SSL Protokoll Struktur
3.5 SSL Handshake
3.5.1 Handshake Messages
3.5.2 Session Resumption
3.5.3 Client Authentication
3.6 SSL Record Protocol

4 SSL/TLS Sicherheitsmechanismen
4.1 Schlüsselaustausch und Digitale Signatur
4.2 Key Derivation Function
4.3 Verschlüsselung
4.4 Hashfunktion
4.5 Authentifizierung

5 Angriffe auf SSL/TLS
5.1 Million Message Attack
5.2 Key-Exchange-Algorithm-Rollback
5.3 Timing Attacken

6 Fazit

Literaturverzeichnis

Abbildungsverzeichnis

Bild 1: HTTP im TCP/IP-Protokollstapel

Bild 2: SSL im TCP/IP-Protokollstapel

Bild 3: Übersicht des SSL Handshake

Bild 4: Sequenz von Handshake Messages

Bild 5: SSL Datenfragmentierung und Verschlüsselung

Bild 6: Schlüsselerzeugung

Tabellenverzeichnis

Tabelle 1: Portnummervereinbarung für Protokolle über TLS/SSL

Tabelle 2: SSL Protokollstruktur

Tabelle 3: Auswahl möglicher Cipher Suites

1 Einleitung

Kommunikationssicherheit hat als primäre Ziele: Vertraulichkeit und Integrität von Daten zu gewährleisten sowie die Authentifikation des Kommunikationspartners. Vertraulichkeit zu gewährleisten heißt übertragene Daten geheim zu halten. Integrität zu sichern bedeutet, dass man den Eingriff einer dritten Partei in die Kommunikation nachweisen kann. Die Authentifizierung des Kommunikationspartners erlaubt es, dass man sich sicher sein kann seine Daten an den „Richtigen“ zu übertragen.

Der Datentransport über Computernetze im Besonderen über das Internet muss als unsicher betrachtet werden. Vor einem möglichen Zugriff eines Angreifers auf das Netzwerk ist man kaum geschützt.

Die vorliegende Arbeit beschreibt zunächst kurz das Hypertext Transfer Protokoll als „das“ Protokoll des Internets, um Daten bzw. Informationen zu transportieren und die in ihm implementierte Möglichkeit der Nutzerauthentifizierung. Um eine umfassende Transportsicherheit der zu übertragenden Daten zu erreichen, müssen kryptographische Mechanismen zum Einsatz kommen. Die Arbeit stellt hier das Konzept der Secure Sockets Layer und Transport Layer Security vor, die eine Verschlüsselung der Daten auf der Transportebene bereitstellen.

2 Hypertext Transfer Protocol

Das Hypertext Transfer Protocol (HTTP) ist ein zustandsloses Datenaustausch- Protokoll zur Übertragung von Daten. Es ist eines der Protokolle, die der TCP/IP- Protokollstapel bereitstellt. Zugeordnet ist es dabei der Anwendungsschicht, wie in Bild 1 dargestellt.

Bild 1: HTTP im TCP/IP-Protokollstapel (WIKIPEDIA 2005a)

Abbildung in dieser Leseprobe nicht enthalten

Primär wird es im Rahmen des World Wide Web zur Übertragung von Webseiten verwendet. Durch Erweiterung seiner Anfragemethoden, Headerinformationen und Fehlercodes ist es allerdings nicht auf Hypertext beschränkt, sondern wird zum Austausch beliebiger Daten verwendet.

Das Protokoll wurde 1989 von Tim Berners-Lee am CERN zusammen mit dem URL und HTML erfunden.

HTTP ist ein Kommunikationsschema, um Webseiten (oder Bilder oder prinzipiell jede andere beliebige Datei) von einem entfernten Computer auf den eigenen zu übertragen. Zusätzliche Informationen wie Angaben über den Browser, gewünschte Sprache etc. können über einen Header in jeder HTTP Kommunikation übertragen werden.

Bei HTTP 1.0 wird vor jeder Anfrage eine neue TCP Verbindung aufgebaut und nach Übertragung der Antwort wieder geschlossen. Enthält eine HTML-Datei Verweise auf zehn Bilder, so werden insgesamt elf TCP Verbindungen benötigt, um die Seite auf einem grafikfähigen Browser aufzubauen. In der Version 1.1 von HTTP können mehrere Anfragen pro TCP Verbindung gemacht werden. Für die HTML-Datei mit zehn Bildern wird so nur eine TCP Verbindung benötigt.

Informationen aus früheren Anforderungen gehen verloren (zustandsloses Protokoll). Über Cookies in den Headerinformationen können aber Anwendungen realisiert werden, die Status- bzw. Sitzungseigenschaften erfordern (Benutzereinträge, Warenkörbe) (WIKIPEDIA 2005a).

Als einen Aspekt der Kommunikationssicherheit ist eine Benutzerauthentifizierung via HTTP möglich und soll im Nachfolgenden dargestellt werden.

2.1 Authentifizierungsmethoden in HTTP

Um bestimmte Bereiche oder Dateien eines öffentlichen Web-Servers nur einem eingeschränkten Nutzerkreis zur Verfügung zu stellen, bedient man sich z.B. der Nutzerauthentifizierung mit Hilfe von Nutzerkennung mit zugehörigem Passwort. Für die Authentifizierung mittels HTTP werden zwei Verfahren unterschieden: HTTP Authentication Basic und Digest Access Authentication.

2.1.1 HTTP Basic Authentication

Ein Zugriff auf ein durch Basic Authentication geschütztes Dokument läuft in folgenden Schritten ab:

Client:

Stellt HTTP Anfrage bzgl. des gewünschten Dokuments an den Server. Zu diesem Zeitpunkt ist dem Client nicht bekannt, dass es sich um ein geschütztes Dokument handelt.

Server:

Antwort Statuscode 401: “Unauthorized to access the document” und übermittelt dem Client im HTTP Header “WWW-Authenticate: Basic realm=’secure pages’”

Client:

Anhand des Statuscode und der WWW-Authenticate-Information erkennt der Client, dass es sich um Basic Authentication handelt und fordert über ein Dialogfenster die Benutzerkennung und das Passwort an. In einer neuen HTTP Anfrage übermittelt der Client mit der Anfrage einen Authorization String, der Benutzerkennung und Passwort des Users enthält.

Server:

Bei erfolgreicher Überprüfung der Client Daten wird das angeforderte Dokument an den Client übermittelt. Andernfalls wiederholt sich die Rückgabe des Statuscode 401 und der Authentifizierungsaufforderung.

Sowohl die Kombination von Benutzerkennung und Passwort als auch das eigentliche Dokument werden Base64 codiert übermittelt, wobei es sich nicht um eine kryptographische Codierung handelt, sondern um eine allgemein bekannte Transformation des Klartextes zur besseren Übermittlung. Sicherheitsanforderungen genügt diese Codierung nicht. Ein Angreifer kann durch einfaches Abhören der Leitung (Sniffer-Attacke) neben dem geschützten Dokument auch an die Authentifizierungsdaten des Nutzers gelangen (PIETSCH 2002).

Um die unverschlüsselte Übertragung der Authentifizierungsdaten zu unterbinden, kann man sich der HTTP Digest Authentication bedienen.

2.1.2 HTTP Digest Access Authentication

Der Ablauf zur Anforderung eines Dokumentes ist hier sehr ähnlich aufgebaut:

Client:

Stellt HTTP Anfrage bzgl. des gewünschten Dokuments an den Server. Zu diesem Zeitpunkt ist nicht bekannt, dass es sich um ein geschütztes Dokument handelt. Server:

Antwortet mit Statuscode 401: „Unauthorized to access the document“ und übermittelt dem Client im HTTP Header mit dem WWW-Authenticate die Information, dass es sich um Digest Access Authentication (DAA) handelt. Außerdem wird eine zufällige Integerzahl übermittelt, der so genannte Nonce-Wert.

Client:

Auf gleiche Art und Weise wie bei Basic Authentication erkennt der Client, dass es sich um ein DAA geschütztes Dokument handelt. Nach Abfrage der Benutzerkennung und des Passworts werden diese Daten zusammen mit dem Nonce-Wert aus der Server Antwort unter Verwendung der MD5 Hashfunktion auf einen 128-Bit Wert abgebildet. In einer neuen HTTP Anfrage übermittelt der Client mit der Anfrage zusammen den berechneten Wert.

Server:

Bei erfolgreicher Überprüfung der Client Daten wird das angeforderte Dokument an den Client übermittelt. Andernfalls wiederholt sich die Rückgabe des Statuscode 401 und der Authentifizierungsaufforderung.

Im Gegensatz zur Basic Authentication werden User-ID und Passwort nicht im Klartext, sondern als Hashwert der MD5 Funktion übertragen. Der Nonce-Wert dient dazu, die Übermittlung der Benutzerdaten für diese Anfrage zu kennzeichnen. Damit genügt ein Abhören des 128-Bit-Wertes nicht. Übermittelt ein Angreifer zu einem späteren Zeitpunkt den abgefangenen Hashwert an den Server, so kann dieser aufgrund des falschen Nonce-Wertes erkennen, dass es sich nicht um den User handelt, der zuvor das Dokument angefordert hat.

Mit diesem Verfahren wird die Nutzerkennung verschlüsselt, die Übertragung des eigentlichen Dokumentes erfolgt im Klartext. Es ist ebenfalls nicht für die Übertragung sensibler Daten geeignet. Dazu kommt, dass übermittelte Dokumente u.U. im Cache des Browsers oder eines Proxy Servers für einen gewissen Zeitraum verbleiben und an diesen Stellen von unbefugten Personen eingesehen werden können (PIETSCH 2002).

Die Verfahren der Authentifizierung, die über HTTP zur Verfühgung gestellt werden, stellen keine Transportsicherung der zu übertragenden Daten dar. Sie sind für Anwendungen, die eine Vertraulichkeit, Integrität und Verbindlichkeit der Daten in offenen Netzwerken bedingen (z.B. eCommerce), ungeeignet. Für solche Anwendungen müssen Verfahren angewandt werden, die die Transportsicherheit von Daten mit Hilfe von Verschlüsselungsverfahren herstellen. Nachfolgend soll das 1994 von der Firma Netscape veröffentlichte Secure Sockets Layer (SSL) Protokoll als Sicherungsprotokoll für die Transportschicht und der daraus entwickelte Standard, Transport Layer Security (TLS), vorgestellt werden.

3 Secure Sockets Layer und Transport Layer Security

Das SSL Protokoll liegt seit 1995 als Version SSL 3.0 vor. Im Januar 1999 wurde SSL von der Internet Engineering Task Force (IETF) als Standard festgelegt. Dieser neue Standard wird als Transport Layer Security (TLS) bezeichnet und ist mit geringen Änderungen behaftet. TLS 1.0 meldet sich im Header als Version SSL 3.1.

Das SSL Protokoll stellt einen sicheren Kanal zwischen zwei Rechnern, zwei kommunizierenden Programmen, bereit. SSL verfügt über Mechanismen die übertragenen Daten zu schützen und den Rechner mit dem man kommuniziert zu identifizieren. Der sichere Kanal ist transparent, d.h., dass Daten unverändert den Kanal passieren. Daten werden zwar zwischen Client und Server verschlüsselt, stimmen aber an Senke und Quelle exakt überein. Diese Transparenz erlaubt es nahezu jedem Protokoll das mit dem Transportation Control Protocol (TCP) arbeitet auch mit SSL benutzt werden kann, wobei nur minimale Modifikationen nötig sind.

Eine SSL Verbindung soll sich wie eine sichere TCP Verbindung verhalten, entsprechend einer TCP Sockets Verbindung. Um dem Rechnung zu tragen und die Programmierung zu erleichtern, ähnelt die API (application programming interface) der meisten SSL Implementierungen stark den üblichen Sockets APIs, wie z.B. der Berkley Sockets API (RESCORLA 2001).

Die Implementierung von SSL innerhalb der Client- oder Serverprogramme stellt der Anwendungsschicht spezielle Funktionen für die Eröffnung und Nutzung einer Transportverbindung zur Verfügung. Anstelle der normalen Socket Funktionen rufen Client und Server die durch die SSL API bereitgestellten, sehr ähnlichen Funktionen auf. Daten werden zunächst nicht direkt dem Betriebssystem zur Übertragung übergeben, sondern stehen zunächst SSL zur Bearbeitung zur Verfügung. SSL schützt übertragenen Daten der Seite des Senders mittels kryptographischer Verfahren und übergibt die geschützten Daten an die Transportschicht. Auf Seiten des Empfängers werden die gekapselten Daten von der Transportschicht an die lokale SSL-Schicht übergeben und von dort an die Anwendungsschicht weitergereicht (FUHRBERG 1998).

SSL ist im TCP/IP Protokoll Stapel direkt unter der Anwendungsebene und über TCP anzusiedeln, wie in Bild 2 dargestellt.

Bild 2: SSL im TCP/IP-Protokollstapel (WIKIPEDIA 2005b)

Abbildung in dieser Leseprobe nicht enthalten

Die Hauptanwendung für SSL liegt im Schutz von HTTP basierenden Internetdatenverkehr. Der Vorgang läuft folgendermaßen ab: In HTTP wird eine TCP Verbindung aufgebaut und der Client sendet eine Anfrage. Der Server antwortet mit einem Dokument. Wird SSL verwendet, baut der Client eine TCP Verbindung auf und darüber eine SSL Verbindung, dann wird dieselbe HTTP Anfrage über die SSL Verbindung gesendet. Der Server antwortet über den SSL Kanal in ähnlicher Weise. Da ein normaler Webserver mit dem SSL Handshake nichts anfangen kann, wird der Client über den Uniform Resource Locator (URL) informiert, ob eine SSL Verbindung zum Server überhaupt möglich ist. Anstelle von http beginnt die URL eines Servers, der SSL unterstützt, mit https. Das Benutzen von HTTP über SSL wird als HTTPS bezeichnet.

3.1 Hypertext Transfer Protocol Secure

HTTPS steht für Hypertext Transfer Protocol Secure und ist ein Netzwerkprotokoll, das eine gesicherte HTTP Verbindung zwischen Rechnern ermöglicht.

Hierbei werden die Daten über SSL/TLS verschlüsselt, damit sie abhörsicher sind. HTTPS Verbindungen laufen über TCP. Der Standardport für HTTPS Verbindungen ist 443 (WIKIPEDIA 2005c).

[...]