Sie sind auf Seite 1von 13

SSL/TLS

HTL-Ottakring | NTSI | Franz Wilding, 2010


SSL/TLS

Inhaltsverzeichnis

Allgemeines 1
SSL - Secure Sockets Layer 1

SSL oder TLS? 1

Geschichte 2
Die Entstehung von SSL 2

Funktionsweise 3
Allgemein 3

Verbindungsaufbau (Handshake Protocol) 3

Datentransport - Record-Protocol 5

Konfiguration 6

Unterschied zwischen SSL und TLS 6

Praxis / Implementierung 7
HTTPS 7

Zertifizierung 8
Gültige Zertifikate 8

Installation 8

Überprüfung 8

Angriff 9
Brute Force 9

Man in the middle 9

Phishing 9

Quellen & Rechtliches 10

HTL-Ottakring | NTSI | Franz Wilding, 2010 i


SSL/TLS

Rechtliches 10

Quellen 10

HTL-Ottakring | NTSI | Franz Wilding, 2010 ii


SSL/TLS

Allgemeines

SSL - Secure Sockets Layer


SSL steht für Secure Sockets Layer und ist ein ein Protokoll-Paket dessen Aufgabe es ist auf einer ungesicherten Leitung
eine gesicherte Verbindung zustande zu bekommen. SSL liegt grundsätzlich auf der Darstellungsschicht (6) im OSI-Modell,
kann aber auch als eigene Schicht zwischen der Transport- und der Darstellungsschicht gesehen werde. In der Praxis wird
SSL häufig bei sicheren Web-Verbindungen wie Onlinebanking oder E-Commerce verwendet.

Die aktuelle Version ist 3.0 bzw. 3.1. SSL ist als RFC 2246 der IETF (Internet Engineering Task Force) standardisiert.

SSL oder TLS?


Als SSL standardisiert wurde, entwickelte sich auf Basis der SSL-Version 3.0 der neue Standard TLS (Transport Layer
Security) 1.0. Die Entwicklung von SSL hörte mit TLS 1.0 auf, da nun am TLS-Protokoll weitergearbeitet wurde. Zur Zeit ist
TLS in Version 1.2 (2008) im RFC 5246 standardisiert.

Da die Funktionsweisen von SSL 3 und TLS größtenteils identisch sind, wird im weiteren Verlauf dieses Dokumentes nur
noch SSL verwendet und beschrieben.

HTL-Ottakring | NTSI | Franz Wilding, 2010 1


SSL/TLS

Geschichte

Die Entstehung von SSL


Als Anfang der 90er-Jahre Websites immer mehr Bedeutung gewannen, und nicht mehr ausschließlich aus Textdokumenten
mit Hyperlinks bestanden, kamen Firmen bald auf die Idee ihren KundInnen viele Dienste auch über das Internet, auf ihrer
Website anzubieten. Dazu gehörten auch vertrauliche Dienste wie Banktransaktionen, oder das Zahlen per Kreditkarte. Das
Problem war nun, dass rein über das HTTP-Protokoll übertragene Passwörter oder Bankverbindungen relativ simpel
abgefangen werden konnten.

1995 brachte aus diesem Grund Netscape (der damals führende Browser-Anbieter) das Sicherheitspaket SSL, bestehend
aus einem Protokoll und dessen Software-Implementierung in ihrem Browser, heraus.

1999 reichte Netscape das SSL 3.0-Protokoll zur Standardisierung bei der IETF ein. Trotz wenig Änderungen, wurde ein
neues Protokoll auf SSL 3.0 aufgebaut: TLS 1.0 ist also quasi der neue Name für SSL 3.1.

Mittlerweile wurde TLS 2008 in der Version 1.2 von einer Großzahl an Firmen (Microsoft, Vodafone, IBM, Nokia, ...) und
Universitäten standardisiert.

HTL-Ottakring | NTSI | Franz Wilding, 2010 2


SSL/TLS

Funktionsweise

Allgemein
SSL kann als „sichere Basis“ beschrieben werden, auf die Anwendungsprotokolle wie HTTP aufbauen. Das Protokoll
kümmert sich um eine sichere Verbindung, die dann (von in der OSI-Schicht weiter oben liegenden Protokollen) genützt
werden kann.

Diese „sichere Verbindung“ bietet einerseits eine Verschlüsselung der Nachrichten zwischen Client und Server, andererseits
dient sie auch zur Authentizität. So kann z.B. verhindert werden, dass ein „Man-In-The-Middle“ seinen Server als
vermeintlich sichere Onlinebanking-Website ausgibt, und somit z.B. an sensible Bankdaten kommen kann.

SSL besteht aus 2 Teilprotokollen, die unterschiedliche Aufgaben für die Verbindung übernehmen:

• Das Handshake-Protokoll ist für den Verbindungsaufbau verantwortlich, und wird noch vor dem ersten
übertragenen Bit der Nutzlast abgearbeitet

• Das Record-Protokoll baut auf einer durch das Handshake-Protokoll aufgebauten Verbindung auf, und wird für die
sichere Datenübertragung verwendet

• Neben diesen zwei Teilprotokollen gibt es noch weitere Nachrichten (auch Protokolle genannt), die aber im
Handshake-Protokolle eine Rolle spielen, und daher nicht für sich selber erklärt werden müssen. Diese sind:

• Change Cipher Spec Protocol ist dafür zuständig, die Verbindung auf die im Handshake-Protokoll geeinigte
Verschlüsselung zu wechseln (Schritt 6 und 7 im nächsten Diagramm)

• Das Alert Protokoll ist eine Sammlung von vielen verschiedenen Nachrichten, die als Mitteilung (z.B.: für das
Beenden einer Verbindung) zwischen Sender und Empfänger dienen.

Verbindungsaufbau (Handshake Protocol)


Diagramm auf nächster Seite

Das Handshake-Protokoll kann in 7 Einzelschritte unterteilt werden, deren Aufgaben es ist, den Server zu identifizieren
und sich auf einen Schlüssel sowie gewisse Einstellungen zu einigen.

1. Alice, der Client fragt beim Server um eine SSL-Verbindung an. Dabei übergibt sie die SSL Versionen, die sie
unterstützt, bevorzugte Komprimierungs- und Chiffrier-Einstellungen sowie eine 32-Bit lange Einmalinformation EA.

2. Bob, der Server antwortet ihr mit der endgültigen SSL-Version, die er aus dem Spektrum der von Alice unterstützten
Versionsnummern wählt, sowie den Komprimierungs- und Kryptographischen Einstellungen. Dazu kommt seine
Einmalinformation: EB.

HTL-Ottakring | NTSI | Franz Wilding, 2010 3


SSL/TLS

3. Bob sendet seinen öffentlichen Schlüssel. Alice hat SSL implementiert, und daher auch eine Sammlung von bekannten
öffentlichen Schlüsseln (ca. 100) eingespeichert. Da aber viel mehr als 100 Server gerne SSL benützten möchten, und
Alice ihren Browser nicht alle 4 Sekunden updaten will, wenn ein neuer Server in die Liste der öffentlichen Schlüsseln
eingetragen werden soll, schickt Bob eine Zertifikatskette. Mit deren Hilfe kann Alice eine Verbindung zu einem der
100 öffentlichen Schlüsseln in ihrer Liste herstellen und Bob identifizieren.

HTL-Ottakring | NTSI | Franz Wilding, 2010 4


SSL/TLS

3.1. Optionale Nachrichten: Bob kann an dieser Stelle eine Nachricht an Alice schicken, um ihren öffentlichen
Schlüssel zu bekommen, falls sie einen besitzt. Gerade im Web-Bereich kann vom Client aber nicht erwartet
werden einen öffentlichen Schlüssel zu besitzen.

4. Nach dem der Server zufrieden ist (alle optionalen Anfragen beantwortet), sendet er eine „Server ist fertig“ Nachricht
an den Client.

5. Auf die „Server-Fertig“ Nachricht, antwortet Alice indem sie einen zufälligen Premaster-Schlüssel wählt und diesen mit
Bob‘s öffentlichem Schlüssel verschlüsselt retourniert. Dieser Schlüssel ist aber noch nicht der Sitzungs-Schlüssel für
die Übertragung der Daten.

6 + 7 Alice sowie Bob können jetzt mit Hilfe der Einmalinformationen EA und EB sowie dem Premaster-Schlüssel PS den
Sitzungsschlüssel berechnen. Das teilen sich Alice und Bob mit, indem sie sich gegenseitig eine Change Cipher Spec
Protocol-Nachricht schicken, um auf die neue Chiffre zu wechseln. Danach beenden sie mit einer letzten Nachricht das
Handshake-Protokoll.

Die Berechnung des Schlüssels hängt vom gewählten Algorithmus ab. Das wird im nächsten Kapitel genauer besprochen.
Wichtig ist noch anzumerken, dass für jede Verbindung das Handshake-Protokoll erneut durchlaufen werden muss.

Datentransport - Record-Protocol
Nach dem erfolgreichen Beenden des Handshake-Protokolls sind nun Server und Client in der Lage sich gegenseitig
Nutzdaten sicher zu schicken. Wenn sich der Client während des Verbindungsaufbaus nicht mittels öffentlichem Schlüssel
identifiziert hat, ist es oft üblich die eigene Identität via Username und Passwort zu bestätigen.

Die Nachrichten zwischen Client und Server werden für die Übertragung in 16KB große Blöcke zerlegt, komprimiert und
verschlüsselt:

Die Komprimierung erfolgt nach dem im Handshake ausgemachten Algorithmus, der MAC (Message Authentification Code)
ist ein simpler Hash-Code des Blockes. Verschlüsselt wird normalerweise mit einer XOR-Verknüpfung des Blockes und
einem Schlüsselstrom basierend auf dem Sitzungs-Schlüssel.

HTL-Ottakring | NTSI | Franz Wilding, 2010 5


SSL/TLS

Konfiguration

Wie im vorherigen Kapital angesprochen, kann der Client dem Server seine bevorzugten Einstellungen während des
Handshake-Protokolls mitteilen. SSL legt sich nicht auf ein bestimmtes Verfahren fest, sondern überlässt es dem Client und
dem Server sich auszumachen wie beide an den Schlüssel kommen wollen, und wie das Komprimieren funktionieren soll.

Aktuell wird meist TLS mit RSA oder AES und SHA-1 als sicherste Variante verwendet. Da durch diese Konfiguration eine
relativ lange Berechnungszeit entsteht, setzten gerade E-Commerce Websites, die ihre KundInnen nicht lange warten lassen
wollen, deshalb manchmal auf nicht so sichere Verschlüsselungs-Algorithmen, und gefährden damit sensible
KundInnendaten.

Unterschied zwischen SSL und TLS

SSL und TLS sind sich sehr ähnlich. Trotzdem gibt es kleine Unterschiede. Weshalb SSL und TLS auch nicht kompatibel
sind.

• Bei SSL wird der MAC nicht nach der Definition von HMAC erstellt. TLS verbesserte diesen Punkt, und erstellt jetzt
MACs immer nach der Definition von HMAC.

• Die Erstellung von Pseudozufallszahlen (EA und EB in der Grafik auf Seite 4) ist bei SSL dem Client und dem Server
überlassen. Um die Sicherheit zu verbessern, wird dies nun von TLS definiert.

• TLS erweitert das Alert-Protokoll um ein paar weitere Nachrichten.

HTL-Ottakring | NTSI | Franz Wilding, 2010 6


SSL/TLS

Praxis / Implementierung

HTTPS

Der Häufigste Einsatz von SSL ist wohl die


Implementierung im HTTP-Protokoll. Dieses wird
um SSL erweitert (HTTPS) um eine sichere
Online-Verbindung via Browser zu ermöglichen.

Der Aufbau über eine SSL-Verbindung geschieht


in den meisten Browsern nicht unbemerkt vom
User, dieser muss aber dazu nichts beitragen.
Der Browser handelt sich das mit dem Server
selbstständig aus.

Dabei zeigt der Browser einerseits an, dass sich der Server
authentifiziert hat, und wirklich der ist, für den er sich ausgibt.
Andererseits wird dem User auch die Sicherheit der
Verbindung angezeigt.

Sollte eine Website kein gültiges Zertifikat haben, warnt


der Browser den User vor dem Besuch der Website, dass
die Seite vielleicht nicht sicher ist. Wenn der User
trotzdem so eine Seite besucht, sollte er auf keinen Fall
sensible Bank- oder KundInnen-Daten an den Server
senden.

Neben HTTPS kann auch jedes andere Protokoll mit SSL


gesichert werden. POP3 und SMTP gehören wohl neben HTTP
zu den größten Einsatzbereichen von SSL.

HTL-Ottakring | NTSI | Franz Wilding, 2010 7


SSL/TLS

Zertifizierung

Es wurde bereits viel über Zertifikate und die „Echtheit“ von Servern geredet. In diesem Kapitel wollen wir uns anschauen,
wie ein Server ein SSL-Zertifikat bekommen kann, und was dieses ca. kostet.

Gültige Zertifikate
Als erstes gilt es ein gültiges Zertifikat zu erwerben, das die Echtheit des eigenen Public-Keys garantiert. Es gibt eine Reihe
von autorisierten Zertifikationsstellen, die auch gemeinsam mit Browser-EntwicklerInnen an der Verbesserung von SSL bzw.
TLS arbeiten. globalsign.wis.de bietet zum Beispiel verschiedene Varianten der Zertifizierung an:

• Domain Validated SSL ist das Standardzertifikat, bei dem der Domain-Name im Zertifikat enthalten ist. Der Sinn von
SSL war eigentlich, auch den/die EigentümerIn der Domain bei einer Registrierung zu überprüfen, und nicht nur zu
schauen, ob die Domain auch wirklich ihm/ihr gehört. Durch den gegenseitigen Preiskampf der einzelnen
Zertifizierungsstellen wird bei einer Domain Validation aus Sparmaßnahmen dies nicht mehr wirklich gemacht. Preis:
ca. 120€ / Jahr

• Ein bisschen weiter geht das Organisation SSL, das auch den Organisations bzw. Firmennamen in das Zertifikat
schreibt, und ein bisschen genauer den/die Domain-Eigentümerin überprüfen. Preis: ca. 200€ / Jahr

• Das Extended Validation SSL (EV) wurde von den Zertifizierungsstellen gemeinsam mit Browser-EntwicklerInnen
erstellt. Es soll ein neues High-Standard-SSL sein, bei dem die Zertifizierungsstellen bei einer Registrierung wirklich
genau die den/die Domain-EigentümerIn überprüfen sollen. Der Vorteil ist, dass der User die Url im Browser grün
hinterlegt sieht (siehe Bilder: Seite 7). User sollen dadurch mehr Vertrauen in SSL bekommen. Preis: ca. 680€

Installation
Das gekaufte Zertifikat wird nach erfolgreicher Überprüfung der eigenen Identität per Email zugesendet. Danach gilt es
dieses am Webserver zu installieren. Dabei muss ein neuer private Kay erstellt und mit dem Zertifikat gemeinsam in den
Webserver eingebunden werden. Die Installation hängt vom Betriebsystem des Webservers ab.

Überprüfung
Wenn ein Client jetzt das SSL-Zertifikat überprüft, kann er durch die X.509-Zertifikatskette, in die nun auch diese Domain
gehängt ist, ein Root-Zertifikate abbilden, das er mit einem seiner gespeichert Zertifikate vergleichen kann.

HTL-Ottakring | NTSI | Franz Wilding, 2010 8


SSL/TLS

Angriff

Brute Force
Die aktuellen Zertifikate funktionieren beinahe ausschließlich alle mit einer Schlüssellänge von 256Bit, was eine Brute Force
Attacke extrem rechenintensiv und kaum realistisch macht.

Man in the middle


Ein „man in the middle“ könnte, wenn er während der Handshake-Phase zwischen Client und Server sitzt einfach seinen
öffentlichen Schlüssel (anstelle des Schlüssels des Servers) an den Client schicken, um so alle Nachrichten (mit seinem
privaten Schlüssel) entschlüsseln zu können. Da aber der öffentliche Schlüssel zertifiziert wurde (vorheriges Kapitel) und
anzunehmen ist, dass Hacker kaum ein gültiges Zertifikat bekommen werden, merkt der Client einen „man in the middle“
sofort, und kann die Verbindung abbrechen.

Phishing
Phishing-Seiten sind nachgemachte Websiten, die darauf warten, dass sich User bei ihnen einloggen. Meistens kopieren sie
1:1 das Design der Originalseite, und können somit auf den ersten Blick nicht wirklich von ihren Originalen unterschieden
werden. Das Ziel von Phishing-Seiten ist es, vertrauliche Userdaten (wie z.b.: PayPal, Bankdaten, Kreditdaten. ...) zu
bekommen.

Durch den Preisdruck zwischen den Zertifizierungsstellen ist es dazu gekommen, dass auch Betreiber von Phishing-Seiten
an gültige SSL-Zertifikate gekommen sind. Durch das EV-SSL (vorheriges Kapitel) soll dieses Problem gelöst werden.
Anzumerken ist, dass die Sicherheit gegen Phishing-Seiten zu einem großen Teil von den Zertifizierungsstellen abhängt.

HTL-Ottakring | NTSI | Franz Wilding, 2010 9


SSL/TLS

Quellen & Rechtliches

Rechtliches
Alle Grafiken und Diagramme (mit Ausnahme von Bild 3 auf Seite 7) sind selber erstellt, und können unter der Creative
Commons - Lizenz weiterverwendet werden.

Quellen
• http://de.wikipedia.org/wiki/Transport_Layer_Security

• http://www.faqs.org/rfcs/rfc5246.html

• 4. Auflage von „Computernetzwerke“ (Andrew S. Tanenbaum)

• http://comodo.com

• http://www.repges.net/SSL/ssl.html

• https://globalsign.wis.de

• http://en.wikipedia.org/wiki/X.509

• https://online.bankaustria.at

• http://www.vibe.at/begriffe/ssl_def.html

HTL-Ottakring | NTSI | Franz Wilding, 2010 10