Secure
Socket Layer
SSL
eine Seminararbeit von
Lehner Thomas
Ziel diese Dokumentes ist es, dem Leser einen
allgemeinen Einblick in die Funktionsweise des von Netscape entwickelten
SSL-Protokolls zu verschaffen.
Im ersten Teil werden vorerst allgemeine Sicherheitsüberlegungen
zu ungesicherten Übertragungsstrecken durcheführt. Aus diesen Überlegungen folgt
schließlich das Modell jener Umgebung, in der SSL eingesezt wird.
Bevor das SSL-Protokoll genauer untersucht wird,
werden im Mittelteil einige der wichtigsten kryptographieschen Methoden
vorgestellt.
Motivation zur Verwendung von sicheren
Übertragungsprotokollen
Immer mehr und
mehr Personen haben Heute Zugang zum Internet. Gerade das World Wide Web bietet
vielen, die nicht den täglichen Umgang mit Computern und moderner
Informationstechnologie gewohnt sind, eine interessante Möglichkeit, sich so
manche wichtigen oder weniger wichtigen Information zu besorgen. Einfach
gestaltete, graphische Webseiten sollen dem Benutzer das intuitive Navigieren
ermöglichen.
Gerade
kommerzielle Unternehmen, die sich auf die Produktion von Waren spezialisiert
haben, die nicht die typische Massenware darstellt, machen sich die Weiten des
Internet zu Nutzen, um möglichst viele Kunden mit ihren Artikeln zu erreichen.
Aber auch immer mehr konventionelle Produkte werden von den verschiedensten
Herstellern angeboten. Und es werden täglich mehr.
Möchte man nun
als Kunde dieses Angebot nützen, so benötigt man oft nur eine Kreditkarte, um
mit ihrer Nummer das verlanget Entgelt zu entrichten. Nun muss nur noch ein
kurzes Formular ausgefüllt werden, in dem unter anderem die Adresse angegeben
wird, an die die Ware zugestellt werden soll. Nichts einfacheres als das!
Doch was wäre
wenn? Wenn der bestellte und bezahlte Artikel nicht ankommt, weil das
Unternehmen, dessen Webseite man besuchte, in Wirklichkeit gar nicht existiert.
Wenn auf dem Kontoauszug bemerkt wird, dass mehr als erwartet mit der
Kreditkarte bezahlt wurde, weil die über das Internet übertragene
Kreditkartennummer von einem Mithörer abgefangen wurde und er diese illegaler
weise für seine eigenen Einkäufe verwendete. Oder wenn ein Mithörer beim
übertragenen Formular seine eigene Adresse eintrug und nun ihm statt mir die
bezahlte Ware zugestellt wird. In den meisten Fällen: Pech gehabt! Denn dieser
Mithörer lässt sich im nachhinein oft nicht mehr ermitteln. Auch sind die
rechtlichen Rahmenbedingungen im internationalen Netz der Netze noch lange
nicht eindeutig festgelegt.
Prinzipielle
gilt, dass es in der Verantwortung jedes Einzelnen liegt, sich zu entscheiden,
welche Unternehmen vertrauenswürdig sind und welche sensiblen Daten man
auszutauschen bereit ist.
Eine Methode, die
hier Abhilfe schaffen soll, ist SSL. Mit dieser Verbindungsart soll erstens der
Anbieter der Internetseite eindeutig identifiziert werden und überdies wird
eine gesicherte, verschlüsselte Übertragung der Daten gewährleistet.
Wie SSL
funktioniert, welche Probleme gelöst werden müssen und welche weiteren Informationsquellen zur Beantwortung von
Detailfragen existieren soll im weitern Verlauf diese Dokumentes gezeigt
werden.
Der Leser möge
sich selbst eine Meinung bilden, ob und vor allem unter welchen Randbedingungen
er SSL sein Vertrauen schenken möchte.
Das eigentliche Problem
Man stelle sich
zwei Kommunikationspartner vor. Der Einfachheit halber nennen wir sie A und B.
Diese kennen einander nicht. Daher besitzen sie kein gemeinsames Wissen von dem
sie annehmen können, dass kein anderer dieses Wissen mit ihnen teilt.
A und B selbst sitzen in einer geschützten Umgebung. Alles, was sie sozusagen innerhalb ihrer eigenen vier Wände treiben, bleibt für Außenstehende unsichtbar. Leider ist jedoch der Kommunikationskanal, der von A nach B führt, öffentlich und kann von jeder man abgehört werden. A und B müssen daher mit einem C rechnen, das von Anfang an ihre Gespräche belauscht. Und nicht nur das, C hat auch die Möglichkeit beliebig Nachrichten aus diesem Nachrichtenkanal herauszunehmen und diese verändert an den Bestimmungsort weiter zu senden, ohne dass der Empfänger dies bemerkt.
Abb. 1
"The man in the middle"
Dieses C wir oft
"The man in the middle" genannt. Wenn dieser von der Möglichkeit
gebrauch macht Nachrichten zu verändern, so spricht man von aktiven sonst von
passiven Angriffen.
A und B stehen nun vor der Aufgabe sich auf eine Sprache zu einigen, die C nicht versteht. Dies ist in der im Abb. 1 dargestellten Situation unmöglich. Denn wenn C ein aktiver Angreifer ist, stehen für A und B keine Möglichkeiten zur Verfügung folgendes Problem zu lösen:
Abb. 2
"Ein aktiver Man in the middle Angriff"
Hier gibt sich
von Anfang an C aus der Sicht von A als B aus und aus der Sicht von B scheint
es so, als wäre C A. Wann immer A eine Nachricht an B schickt, nimmt C diese
entgegen und leitet diese an B weiter. Liefert B schließlich die Antwort, nimmt
C diese zur Kenntnis und stellt sie A zu. Wenn A eine verschlüsselte Verbindung
mit B aufbaut, so tut A dies in Wirklichkeit mit C. Dieses richtet als Folge
eine sichere Verbindung mit B ein, so als würde dies der Wunsch von A sein.
Selbst wenn A nun eine verschlüsselte Nachricht an B schickt, kann C diese
entschlüsseln, diese zur einsehen und anschließend wieder für B verschlüsseln
usw.
Dieses Problem
wäre gelöst, wenn zum Beispiel B einen Ausweis besitzt, mit dem es sich
gegenüber A eindeutig ausweisen könnte. Dieser Ausweis muss natürlich so
gestaltet sein, dass sich kein anderer als B selbst mit diesem Ausweis
ausweisen kann. Zumindest muss es später für A eine Möglichkeit geben,
festzustellen, ob der Ausweis direkt von B stammt oder ob sich ein C
fälschlicherweise als B ausgibt.
Theoretisch zeigt
sich, dass C jeden Ausweis fälschen kann! Dies kann jedoch C so stark erschwert
werden, das die Kosten die C aufwenden müsste, um diesen Ausweis zu fälschen
höher sind als der Gewinn, den C durch Abhören der Nachrichten zwischen A und B
erreichen könnte.
Nun ist noch die
Frage zu klären, wer den Ausweis für B ausstellt. B darf sich diesen Ausweis
nicht selbst ausstellen können, denn sonst könnte sich auch C einen Ausweis
anfertigen, in dem sich C unter dem "Namen" von B ausweist.
Wie Abb. 3 zeigt, wird neben A und B noch eine dritte vertrauenswürdige Person D benötigt:
Abb. 3: Die Rolle der Authentifizierungsstelle
Hier muss sich A
einmalig davon überzeugen, dass alle Ausweise die von D ausgestellt werden
korrekt sind. Wie A dieses Vertrauen in D erreicht, wird später erläutert.
Bevor die
Authentifizierungsstelle einen Ausweis ausstellt, muss der Antragsteller seine
Identität eindeutig nachweisen. Dies muss oder soll nicht auf elektronischem
Wege geschehen. Idealerweise muss sich B physisch an den Aufenthaltsort von D
begeben und dort seinen Ausweis beantragen.
Die im Abb. 3
dargestellte Situation zeigt die Rahmenbedingungen, in der SSL nun eine sichere
Verbindung zwischen A und B gewährleisten kann.
Einige wichtige Methoden
Bevor nun SSL im
Detail beschrieben wird, sollen noch einige allgemeine Methoden vorgestellt
werden, die auf dem Gebiet der Kryptographie zum Einsatz kommen und von SSL
verwendet werden.
Verschlüsselungsverfahren allgemein
In diversen
Spionagethrillern kommt des öfteren folgende Situation vor. Böse Hacker
versuchen sich Zugang zu einem Unternehmen zu verschaffen, dass
kryptographiesche Software herstellt. Diese Hacker wollen dadurch in Erfahrung
bringen, wie eine solche Software funktioniert, um mit einem Schlag alle
verschlüsselten Nachrichten, die mit dieser Software erstellt wurden, entschlüsseln
zu können.
In der
Vergangenheit mag es zwar Verschlüsselungsverfahren gegeben haben deren
Sicherheit auf der Geheimhaltung der Verschlüsselungsmethode selbst beruhte,
doch werden derartige Systeme heute nicht mehr verwendet. Somit kann es zu der
oben geschilderten Situation nicht mehr kommen.
Moderne
Verschlüsselungsmethoden sind allgemein bekannt. Ihre Sicherheit beruht auf der
Geheimhaltung von sogenannten Schlüsseln die sich jeder Anwender selbst
erzeugen kann. Diese Schlüssel bestehen aus einer bestimmten Anzahl von
Datenwörtern. Eine Nachricht die mit einem Schlüssel verschlüsselt wurde kann
nur mit dem entsprechenden Gegenschlüssel wieder entschlüsselt werden. Die
allgemeine Kenntnis darüber, wie die Verschlüsselungsmethode funktioniert, erhöht
in weiterer Folge sogar die Sicherheit! Denn um so bekannter eine solche
Methode ist, desto mehr Angriffe muss diese standhalten, um weiter hin als
sicher gelten zu können und um so wahrscheinlicher wird es daher, dass die
verwendete Methode tatsächlich sicher ist.
Die Sicherheit
von modernen Verschlüsselungsverfahren beruht also darauf, dass die Schlüssel,
die zur Entschlüsselung von Nachrichten benötigt werden, nur sehr schwer oder
praktisch gar nicht gefunden werden können.
Symmetrische Verschlüsselungsverfahren
Im weiteren
unterscheidet man die auf Schlüssel beruhenden kryptographieschen Verfahren in
Methoden mit symmetrischen und mit asymmetrischen Schlüsseln.
Symmetrische
Verschlüsselungsverfahren verwenden zur Verschlüsselung und zur Entschlüsselung
den selben Schlüssel. Idealerweise kann sogar der selbe Algorithmus verwendet
werden.
Abb. 4:
Symmetrische Verschlüsselung
Die symmetrischen
Verschlüsselungsmethoden bieten den Vorteil, dass die Verschlüsselung und die
Entschlüsselung relativ schnell durchgeführt werden kann. Daher wird versucht
den Großteil der zu übertragenden Datenmengen mit symmetrischen Verfahren zu
verschlüsseln. Ein Nachteil den diese Methoden besitzen ist das Problem des
Schlüsselaustausches.
Erzeugt A zum
Beispiel den Schlüssel, so muss dieser natürlich B mitgeteilt werden. Dieser
Austausch sollte verschlüsselt erfolgen! Doch mit welchem Schlüssel? Die Lösung
dieses Problems erfolgt unter anderem durch die Verwendung von asymmetrischen
Verschlüsselungsverfahren.
Der
Vollständigkeit halber seien hier drei der auch in SSL verwendeten Verfahren
erwähnt: Triple DES, DES
und RC4.
Asymmetrische Verschlüsselungsverfahren
Bei den
asymmetrischen Verschlüsselungsmethoden verwenden der Sender und der Empfänger
unterschiedliche Schlüssel zur Ver- bzw. zur Entschlüsselung. Bei diesen
Schlüsseln handelt es sich um sogenannte Schlüsselpaare, welche immer aus einem
privatem Schlüssel, den nur der Sender kennt, und einem öffentlichen Schlüssel,
der allgemein zugänglich ist, bestehen. Eine Nachricht, die mit dem privaten
Schlüssel verschlüsselt worden ist, kann nur mit dem öffentlichen Schlüssel
entschlüsselt werden. Umgekehrt, kann eine mit dem öffentlichen Schlüssel
verschlüsselte Nachricht nur mit dem dazugehörigen privaten Schlüssel auch
wieder entschlüsselt werden.
Abb. 5
Verschlüsselung mit privatem Schlüssel
In dieser
Situation kann sich B sicher sein, dass jede Nachricht, die sich mit dem
öffentlichen Schlüssel von A entschlüsseln lässt, auch tatsächlich von A
verschlüsselt wurde, da nur A den nötigen privaten Schlüssel kennt.
Abb. 6
Verschlüsselung mit öffentlichem Schlüssel
In diesem Fall
kann sich B wiederum sicher sein, dass die Nachricht die mit dem öffentlichen
Schlüssel von A verschlüsselt wurde, auch nur von A entschlüsselt werden kann.
Auf diesen beiden
Assoziationen, die B beim Empfangen bzw. beim Senden von verschlüsselten
Nachrichten an A annehmen darf, beruhen wie wir sehen werden viele weitere
Methoden, die auch von SSL genützt werden.
Das bekannteste
asymmetrische Verschlüsselungsverfahren ist sicherlich RSA. Diese Methode nützt die Tatsache, dass es
sehr schwierig ist große Zahlen in ihre Primfaktoren zu zerlegen. So besteht
bei diesem Verfahren der öffentliche Schlüssel im wesentlichen aus dem Produkt
zweier großer Primzahlen. Um nun vom Puplic Key auf den Private Key schließen
zu können, müsste eine solche Zerlegung gefunden werden. Und dies ist eben sehr
aufwendig, da alle heute bekannten Methoden zur Faktorisierung einer Zahl in
Abhängigkeit von der Größe dieser Zahl exponentielle Zeit benötigen.
(Bemerkung: Früher glaubte man, dass das Faktorisieren von Polynomen ebenfalls
exponentielle Zeitkomplexität besitzt. Heute kennt man jedoch Algorithmen, die
dieses Problem in polynomialer Zeit lösen. Dementsprechend gelten
Verschlüsselungsmethoden, deren Sicherheit auf der Schwierigkeit der
Faktorisierung von Polynomen beruht, heute nicht mehr als zuverlässig.)
Der Nachteil von
asymmetrischen Verschlüsselungsmethoden besteht im hohen Rechenaufwand beim
Ver- und Entschlüsseln. Deshalb wird RSA in SSL nur zu Beginn zum
Verbindungsaufbau und zur Vereinbarung des symmetrischen Schlüssels verwendet.
Der Vorteil liegt
in der einfachen Methode des Schlüsselaustausches. Da den öffentlichen
Schlüssel jeder kennen darf, kann dieser dem Kommunikationspartner einfach
zugesandt werden. Nun bleibt nur noch
die Frage zu klären, wie B überprüfen kann, ob der ihm zugesandte öffentliche
Schüssel auch wirklich der öffentliche Schlüssel von A ist. Diese Überprüfung
erfolgt mittels Zertifikaten, die jenen Ausweisen entsprechen, die in der
Einführung erwähnt wurden.
Digitale Unterschriften
Ein wichtiges
Verfahren das auf Public-Key-Methoden aufbaut und das im weiteren verwendet
wird ist das Konzept der digitalen Unterschrift.
Anhand einer
solchen digitalen Unterschrift kann der Empfänger eines Datenpaketes
feststellen, ob dieses tatsächlich von der unterschreibenden Person stammt, und
ob dieses Packet verändert wurde.
Wie wird nun eine
solche Unterschrift erstellt? Als erstes wird eine sogenannte Hash-Funktion
benötigt. Diese nimmt als Eingabe ein beliebig großes Datenpaket und liefert
als Ausgabe einen Wert fixer Größe. Dieser Wert wird als Hash-Wert bezeichnet.
Er soll zwei Eigenschaften erfüllen. Zum ersten sollen ähnliche Dokumente
unterschiedlichste Hash-Werte zur Folge haben und zum zweiten soll anhand des
Hash-Wertes nicht auf den Inhalt des Dokuments geschlossen werden können.
Eine sehr
einfache jedoch hier unbrauchbare Hash-Funktion wäre zum Beispiel eine
Prüfsumme. Unbrauchbar deshalb, da Dokumente, die sich nur durch Umstellung von
Zeichen unterscheiden, gleiche Hash-Werte liefern würden. So könnte man in
einer Rechnung in der die Zahl 1900 vorkommt diese einfach durch 9100 ersetzen
und würde dennoch den gleichen Hash-Wert erhalten.
Die zweite
Bedingung an die Hash-Funktion ist
leicht erfüllbar, da durch die Abbildung eines Dokumentes auf
typischerweise nur wenige Bytes die Eindeutigkeit verloren geht.
Nach der
Erstellung des Hash-Wertes wird nun dieser mit dem privaten Schlüssel des
Unterschreibenden verschlüsselt. Das Ergebnis ist die digitale
Unterschrift.
Der Empfänger des
Dokumentes entschlüsselt die Unterschrift mit dem öffentlichen Schlüssel und
überprüft, ob der Hash-Wert, den er selbst erstellt, mit dem entschlüsselten
Wert übereinstimmt. Ist dies der Fall, so kann er sich wie verlangt sicher
sein, dass die Unterschrift nur von der Person erstellt wurde, die den zum
verwendeten öffentlichen Schlüssel passenden privaten Schlüssel besitzt, da nur
diese Person die Unterschrift korrekt verschlüsseln konnte und dass die
Nachricht nicht verändert wurde, da sonst der berechnete Hash-Wert vom
erhaltenen Wert abweichen würde. In Abb.
7 und Abb. 8 sind die einzelnen Schritte entsprechend dargestellt.
Abb. 8 Die
Überprüfung einer digitalen Unterschrift
Zertifikate
Wie bereits
mehrmals erwähnt sind Zertifikate so etwas ähnliches wie Ausweise. Die
wesentlichen Inhalte eines solchen Zertifikates sind der Name der Stelle, deren
Authentizität durch diesen Ausweis bestätigt wird, deren Public-Key, der Name
der ausstellenden Zertifizierungsstelle und deren digitale Unterschrift über
das Zertifikat.
Die wichtigste
und eigentlich einzige Aufgabe die ein Zertifikat erledigt, ist die eindeutige
Zuordnung eines Public-Key's zu einer bestimmten Institution. Dass diese
Zuordnung korrekt ist und dass die Institution, die den passenden privaten
Schlüssel besitzt, tatsächlich existiert, dafür verbürgt sich die ausstellende
Zertifizierungsstelle. Diese fügt dem ausgestellten Zertifikat seine digitale
Unterschrift hinzu, wodurch es für Dritte ohne die Kenntnis des privaten
Schlüssels der Zertifizierungsstelle unmöglich wird, das Zertifikat zu
verändern. Der Aufbau von Zertifikaten ist standardisiert. Hierzu finden
interessierte Leser genaue Angaben im RFC2459
mit dem Titel "Internet X.509 Public Key Infrastructure, Certificate and CRL Profile".
Der schematische Aufbau eines Zertifikates kann auch aus Abb. 9 abgelesen werden.
Abb. 9 Wesentliche Inhalte eines X.509 Zertifikates
Nun stellt sich
eine Weiter Frage. Wieso soll eigentlich derjenige der ein Zertifikat
überprüft, ausgerechnet der Zertifizierungsstelle trauen, die das Zertifikat
ausgestellt hat? Diese Frage soll im nächsten Teil beantwortet werden.
Zertifizierungsstellenhierarchie
Jeder der ein Zertifikat benötigt kann dieses
bei einer geeigneten Zertifizierungsstelle beantragen. Zu diesem Zweck muss
sich der Antragstelle bei der Zertifizierungsstelle auf konventionelle Art und
Weise ausweisen. Dies erfolgt zum Beispiel mit einem Lichtbilderausweis und
erfordert daher die körperliche Anwesenheit des Antragstellers am Ort der
Zertifizierungsstelle. Um den Aufwand für den Antragsteller möglichst gering zuhalten,
ist somit eine große Anzahl von Zertifizierungsstellen erwünscht, damit die
Anreisewege zu diesen möglichst kurz gehalten.
Andererseits muss
aber nun jemand, der ein Zertifikat überprüfen möchte, alle diese
Zertifizierungsstellen kennen und er muss ihnen vor allem vertrauen können. Um
zu verhindern, dass der Einzelne die Übersicht über die verschiedenen
Zertifizierungsstellen verliert und dass somit keiner zweifelhaften Stelle
vertraut wird, wurde eine Zertifizierungsstellenhierarchie eingeführt.
Abb. 10 Zertifizierungshierarchie (CA ... Certificate Authority)
Um im
dargestellten Beispiel das Zertifikat von A zu überprüfgen besorgt man sich
zuerst das Zertifikat jener Stelle, die dieses ausstellte. Hier ist dies das
Zertifikat der "Engineering CA". In diesem befindet sich der
öffentliche Schlüssel dieser Authentifizierungsstelle mit dem die digitale
Unterschrift des Zertifikates von A überprüft werden kann. Ist dies erfolgreich,
so kann der Überprüfende dem Zertifikat von A vertrauen, wenn er dem Zertifikat
von der Zertifizierungsstelle "Engineering CA" vertrauen kann, usw.
Diese
Zertifizierungskette handelt man sich Schritt für Schritt nach oben, bis eine
CA gefunden wird der man vertraut. Spätestens der so genanten Root CA, die sich
ihr Zertifikat selbst ausstellte, muss der Überprüfende vertrauen ansonsten
kann die Korrektheit des Zertifikates von A nicht nachgewiesen werden.
Üblicherweise ist
der Überprüfende eine Software, die diesen Überprüfungsprozess automatisch
durchführt. So wird zum Beispiel beim bekannten Internetbrowser Netscape eine
Liste von vertrauenswürdigen Root CA's fix in die ausführbare Programmdatei
eingebaut. Letzten Endes vertraut der Benützer also in diesem Fall auf den
Browserhersteller Netscape, der bestimmt welche Root CA's vertrauenswürdig
sind.
Nach dem nun
einige der wichtigsten Verfahren und Methoden die im SSL- Protokoll zum Einsatz
kommen zumindest Prinzipiell erklärt wurden, wird nun im weiteren das Secure
Socket Layer Protokoll selbst vorgestellt.
Das Secure Socket Layer Protokoll
Das Secure Socket
Layer Protokoll stammt ursprünglich von Netscape. Seit November 1996 liegt es
als Version 3.0 in Form des Internet-Draft302 vor. Die Verallgemeinerung von SSL ist
das Transport Layer Security(TLS) Protokoll, das als RFC2246 veröffentlicht wurde.
Die weiteren
Erlauterungen stützen sich auf die Informationen des Internet-Draft zu SSL 3.0.
Es wurde versucht jeweils an die passenden Abschnitte dieses Draft's zu
verweisen.
Das SSL Protokoll
soll eine eindeutige Authentifizierung der Kommunikationspartner ermöglichen
und schließlich eine verschlüsselte, sichere Verbindung aufbauen. Um SSL
universell anwendbar zu machen, wurde es direkt über dem TCP/IP Protokoll
angesiedelt.
Abb. 11 Die
Ansiedelung des SSL-Protokolls über TCP/IP
Wie aus Abb. 11
ersichtlich wird das SSL Protokoll selbst ebenfalls wieder in zwei
Teilprotokolle eingeteilt. Dem SSL-Handshake Protokoll, das nur während des
Verbindungsauf- und abbaus aktive ist, und in das SSL Record Protokoll das
unter anderem schließlich die Verschlüsselung und Entschlüsselung der
übertragenen Daten durchführt. In Richtung der Anwendungsschicht präsentiert
sich SSL nach dem Verbindungsaufbau wie TCP/IP. Somit können verschiedenste
Applikationsprotokolle wie zum Beispiel HTTP direkt auf SSL aufsetzen ohne das
diese angepasst werden müssen.
Das SSL Record Protokoll
Das SSL-Record Prodokoll nimmt Datenblöcke beliebiger Größe entgegen, fragmentiert diese in Blöcke geeigneter Größe, wendet optional einen Komprimierungsalgorithmus an, führt weiters den vereinbarten Verschlüsselungsalgorithmus aus, signiert das erhaltene Datenpaket mit dem Message Authentication Code (MAC) und gibt die Daten schließlich an denn darunter liegenden TCP/IP Layer weiter. Beim Empfänger werden die einzelnen Tätigkeiten entsprechend in umgekehrter Reihenfolge ausgeführt.
Abb. 12
Aktionen des SSL-Recordprotokolls beim Sender
Den genauen
Aufbau der erzeugten Datenstrukturen SSLPlaintext, SSLCompressed
und SSLCiphertext kann der
Protokollspezifikation entnommen werden.
Welche
Komprimierungs- und Verschlüsselungsfunktionen zur Anwendung kommen, wird
während des SSL-Handshakes vereinbart. Zu Beginn der Sitzung erfolgt keine
Komprimierung und auch keine Verschlüsselung.
In die Berechnung
des MAC fließt ein Hash-Wert ein, der abhängig ist von:
- den zu übertragenden Daten
- einer Packetsequenznummer
- einem für jede Sitzung eindeutigen
Wert
Dadurch wird es
dem Empfänger eines SSL-Record-Paketes möglich zu überprüfen, ob dieses während
der Übertragung verändert wurde, ob dieses Paket zu einem früheren Zeitpunkt
während der aktuellen Sitzung bereits einmal empfangen wurde und ob das Paket
auch tatsächlich zu der aktuellen Verbindung gehört. Letzteres soll verhindern,
dass ein Angreifer Datenpakete aus einer früheren Verbindung in eine spätere
Sitzung einfließen lässt, um somit die Kommunikation gezielt seinen Absichten
entsprechend zu beeinflussen.
Die exakte Berechnung des MAC kann
selbstverständlich wieder aus der SSL-Spezifikation entnommen werden.
Zusammengefasst
kann schließlich bemerkt werden, dass wenn das SSL-Record-Protokoll einmal im
verschlüsselten Modus betrieben wird, es einem Angreifer ohne die Kenntnis der
Schlüssel unmöglich ist folgende Dinge zu tun:
- Datenpakete einsehen
- Nachrichten verändern
- Pakete aus dem Nachrichtenkanal
entfernen
- alte Nachrichten wieder in die
Kommunikation einfließen lassen
Der erste Punkt
wird durch die Verschlüsselung erreicht, die weitern durch die Verwendung des
MAC (digitale Unterschrift + Sequenznummer + Teil des Sitzungsgeheimnisses).
Diesem sicheren
Kommunikationsmodus von SSL geht ein erfolgreicher SSL-Handshake voraus, in dem
unter anderem die gemeinsamen Schlüssel erzeugt werden.
Der SSL-Handshake
Die vom
SSL-Handshake Protokoll verfolgten Ziele:
·
das Einigen
auf gemeinsame Verschlüsselungs- und Komprimiermethoden
·
das Erzeugen
eines gemeinsamen Geheimnisses aus dem schließlich alle benötigten Schlüssel
abgeleitet werden können
Gleich zu Beginn
soll hier in Abb. 13 der prinzipielle Ablauf eines SSL-Handshakes dargestellt
werden.
Abb. 13 Der SSL-Handshake
Wie aus Abb. 13
ersichtlich sind manche Nachrichten optional. Welche dieser Nachrichten tatsächlich
benötigt werden entscheidet zum Teil der Client, zum Teil der Server, in dem
sie bekannt geben welche Art von Verbindung sie wünschen.
1. Verbindungsart: Server und Client ohne
Authentifizierung
Bei dieser
Verbindungsart verlangt weder der Server noch der Client eine Authentifizierung
seines Kommunikationspartners durch ein Zertifikat.
Abb. 14 Die
benötigten Nachrichten für die Verbindungsart 1
Die erste Nachricht, die der Client dem Server schickt, ist die so genante ClientHello- Nachricht.
Abb. 15 Der wesentliche Inhalt einer ClientHello
Nachricht
Im Gegenzug Antwortet der Server mit einem ServerHello:
Abb 16.
wesentlicher Inhalt des ServerHello
In diesen ersten
beiden Nachrichten erzeugen der Client und Server gemeinsam Zufallsdaten. Diese
Zufallsdaten fließen in weiterer Folge in die Erzeugung des gemeinsamen
Geheimnisses, dem so genanten Master Secret, mit ein.
Hier soll darauf
hingewiesen werden, dass die Erzeugung der Zufallsdaten gemeinsam geschieht!
Erzeugt ein Client korrekte Zufallsdaten, so kann er sich, auch wenn der Server
in Wirklichkeit ein Angreifer ist, der zum Beispiel versucht eine alte Sitzung
zu wiederholen , sicher sein, dass die Zufallsdaten insgesamt zufällig sind, da
sein Beitrag zufällig ist. Das selbe gilt natürlich auch für einen Server, der
es mit einem angreifenden Client zu tun hat.
Mit der
ClientHello Nachricht teilt der Client dem Server weiter mit, welche
Verschlüsselungs- und Komprimiermethoden er unterstütz. Der Server wählt nun
den stärksten Verschlüsselungsalgorithmus, den beide beherrschen, und eine ihm
geeignet erscheinende Komprimiermethode aus. Diese Wahl wird dem Client mit der
ServerHello Nachricht mitgeteilt. Welche Algorithmen
zur Verschlüsselung und zur Komprimierung im Detail bis zur Version 3.0 von
SSL zur Verfügung stehen, kann wiederum aus der Protokollspezifikation
entnommen werden. Im wesentlichen handelt es sich bei den verwendeten
Verschlüsselungsalgorithmen um symmetrische Verschlüsselungsverfahren mit
Schlüsselbreiten zwischen 40 bis 168 Bit.
Im Falle der Nicht-Authentifizierung
des Servers sendet dieser nun eine ServerKeyExchange-Nachricht
an den Client.
In dieser Nachricht gibt der Server einen von drei möglichen Key-Exchangealgorithmen (Diffie-Hellman, RSA, FORTEZZA) an, nach dem der weiter Schlüsselaustausch durchgeführt werden soll.
Eine Unterscheidung in diese drei Algorithmen ist für die weiteren Erklärungen nicht nötig, da sie hier alle zum selben Ergebnis führen. Deshalb soll nun für die weiteren Überlegungen die Wahl der bekannte Public-Key Methode RSA angenommen werden.
In diesem Fall enthält die ServerKeyExchange-Nachricht vereinfacht dargestellt lediglich den Public-Key des Servers. Würde sich der Server an dieser Stelle mit einem Zertifikat ausweisen, so würde die ServerKeyExchange-Nachricht ganz entfallen, da dann der Client den Public-Key aus dem Zertifikat ablesen könnte.
Abb. 17 Vereinfachte ServerKeyExchange-Nachricht für
RSA-KeyExchange
Nun folgt die ServerHelloDone-Nachricht, die dazu
dient dem Client mit zuteilen, dass der Server auf seine Antwort wartet. Diese
Nachricht enthält keine weiteren Informationen.
In Abhängigkeit
des in der ServerKeyExchange Nachricht angegebenen Key-Exchange-Algorithmuses
muss der Client nun eine passende ClientKeyExchange-Nachricht
an den Server zurück senden.
Unter der oben
angenommenen RSA-KeyExchange-Methode
enthält diese Client Antwort nun das mit dem Public-Key verschlüsselte
Premaster Secret welches vom Client durch die Wahl von 48 zufälligen Bytes
erzeugt wird.
Nach dem der
Server diese Nachricht erhalten hat, besitzen nun beide dieses Premaster
Secret. Aus diesem und aus weiteren Daten erzeugen sie nun unabhängig von
einander das Master Secret nach folgender Formel:
master_secret = MD5(pre_master_secret + SHA('A' + pre_master_secret + ClientHello.random + ServerHello.random)) + MD5(pre_master_secret + SHA('BB' + pre_master_secret + ClientHello.random + ServerHello.random)) + MD5(pre_master_secret + SHA('CCC' + pre_master_secret + ClientHello.random + ServerHello.random));
Hier sind MD5 und SHA allgemein bekannte Hash-Funktionen und
ClientHello.random und ServerHello.random die Zufallsdaten die ganz zu Beginn
der Sitzung durch die Hello-Nachrichten ausgetauscht wurden.
Im nächsten
Schritt leiten der Client und der Server die für die vereinbarte
Verschlüsselungsmethode nötigen Schlüssel aus dem Master Secret ab. Beide
wechseln nun mit diesen Schlüsseln in den gewählten Verschlüsselungsmodus. In
diesem senden sie sich nun jeweils eine verschlüsselte Finished-Nachricht zu.
Abb. 18 Der Inhalt einer Finished-Nachricht
Geling es den
beiden die jeweils erhaltenen Finished-Nachrichten zu entschlüsseln und den
somit erhaltenen Hash-Wert erfolgreich zu verifizieren, dann können sie
annehmen, dass:
- beide das identische Master Secret
abgeleitetet haben
- beide während des Handshakes die
gleichen Nachrichten gesendet bzw. empfangen haben
Der erste Punkt
wird alleine schon dadurch sichergestellt, dass beide offensichtlich ihre
gegenseitig zugesandten Nachrichten entschlüsseln konnten. Dies ist jedoch nur
dann möglich, wenn beide die selben Schlüssel aus eben dem selben Master Secret
abgeleitet haben.
Hiermit ist der
Verbindungsaufbau beendet und es kann begonnen werden, Applikationsdaten aus zu
tauscht.
Achtung: Die
beiderseits anonyme Verbindung ist nicht sicher gegenüber aktive "man in
the middle" Angriffe (Siehe Abb. 2). Diese Verbindungsart soll daher
vermieden werde.
2. Verbindungsart: Server authentifiziert, Client
anonym
Der wesentliche
Unterschied zur vorhergehenden Verbindungsart ist, dass der Server seinen
öffentlichen Schlüssel nicht durch eine ServerKeyExchange-Nachricht dem Client
mitteilt, sondern seinen Schlüssel durch die Übermittlung seines Zertifikates
dem Client zukommen lässt. Geling es nun dem Client das Zertifikat als gültig
zu verifizieren, so kann sich dieser sicher sein, dass nach einem erfolgreichen
Verbindungsaufbau eine SSL-Verbindung zu genau jenem Server zustande gekommen
ist, dessen Zertifikat empfangen wurde.
Die in SSL verwendeten Zertifikate entsprechen dem X.509 Format.
Abb. 19 Der SSL-Handshake für
Serverauthentifizierung
Jene Nachrichten,
die auch schon bei der Verbindungsart 1 vorkamen müssen hier nicht mehr erklärt
werden. Der Aufbau und die Bedeutungen haben sich nicht verändert.
Abb. 20 ServerCertificate-Nachricht
Die ServerCertificate-Nachricht
beinhaltet nicht nur, wie man vielleicht vermuten würde, das Zertifikat des
Servers, sonder auch alle Zertifikate der Zertifizierungsstellen bis hinauf zur
Root Authority unter der das Serverzertifikat ausgestellt wurde. Somit ist es
dem Client möglich zu überprüfen, ob die Zertifizierungskette eine gültige ist
und ob der Root Authority vertraut werden kann. Ist beides der Fall, wurde das
Serverzertifikat erfolgreich verifiziert.
Nun kann der
Client natürlich noch nicht davon ausgehen, dass ihm dieses Zertifikat auch
tatsächlich vom Server zugesandt wurde. Im nächsten Schritt würde jedoch ein
falscher Server entlarvt! Denn nur der zum zugestellten Zertifikat passende
Server wird in der Lage sein, das mit dem Public-Key verschlüsselte Premaster
Secret aus der nun folgenden ClientKeyExchange-Nachricht
richtig zu entschlüsseln.
Da jetzt ein
"man in the middle" keine Chance mehr hat sich in Richtung des
Clients als falscher Server zu präsentieren, sind mit der Einführung der
Serverauthentifizierung aktive Angriffe unmöglich geworden.
3. Verbindungsart: Server authentifiziert, Client
authentifiziert
Zusätzlich zur
Verbindungsart 2 kann der Server mit der CertificateRequest-Nachricht
auch ein Zertifikat vom Client
beantragen. Dieser stellt dem Server dies mit der ClientCertificate-Nachricht zu und
beweist mit der weiteren Nachricht CertificateVerify, dass er auch tatsächlich
jener ist, dessen Namen im Zertifikat aufscheint.
Abb. 21 Der SSL-Handshake für Authentifizierung von
Client und Server
Der Aufbau der 3
zusätzlichen Nachrichten ist aus Abb. 22 bis 24 ersichtlich.
Abb. 22
CertificateRequest-Nachricht
Abb. 23
ClientCertificate-Nachricht
Abb. 24 CertificateVerify-Nachricht
Falls der Client
kein Zertifikat besitzt, dass unter einer Root CA ausgestellt wurde, welche in
der vom Server bekannt gegebenen Liste auftaucht, wird der Verbindungsaufbau
abgebrochen.
Besitzt der
Client hingegen ein Zertifikat, das vom Server akzeptiert wird, so schickt der
Client dem Server mit der ClientCertificate-Nachricht sämtliche Zertifikate der
Authentifizierungskette, die nötig sind, um das Clientzertifikat überprüfen zu
können.
Damit der Server
weiters überprüfen kann, ob derjenige, der sich mit dem Clientzertifikat
ausweist, auch tatsächlich der Client ist, muss der Client seine Identität
beweisen. Dies geschieht mit der CertificateVerify-Nachricht. Denn kann nun der
Server die digitale Unterschrift mit dem öffentlichen Schlüssel des
Clientzertifikates verifizieren, so kann diese Nachricht nur vom zum Zertifikat
passenden Client stammen.
Womit der Server
die Identität des Clients eindeutig feststellte.
Bemerkung: Da die Unterschrift, die in der
CertificateVerify-Nachricht aufscheint, über Daten erfolgt, die
Sitzungsabhängig sind, kann ein falscher Client nicht versuchen eine einmal von
einem Client ausgestellte CertificateVerify-Nachricht zu missbrauchen, um sich
mit dieser und dem zugehörigen Clientzertifikat falsch auszuweisen.
Beispiel:
Wir betrachten
drei Personen: Martin, Thomas und Roland.
Martin möchte
eine Verbindung mit Thomas aufbauen. Thomas verlangt während dieses
Verbindungsaufbaues, dass sich Martin authentifizieren muss. Martin tut dies
mit seinem Zertifikat und der zugehörigen CertificateVerify-Nachricht. Der
Verbindungsaufbau war erfolgreich, die beiden unterhalten sich und beenden
schließlich die Sitzung. Nun kennt aber Thomas das Zertifikat von Martin und er
besitzt eine zu diesem Zertifikat passende CertificateVerify-Nachricht. Jetzt
kann er versuchen mit Roland eine Verbindung aufzubauen. Roland verlangt von
Thomas eine Authentifizierung. Thomas möchte sich nun als Martin ausgeben und
schickt Roland das Zertifikat von Martin. Roland möchte nun feststellen, ob
derjenige der ihm Martin's Zertifikat zuschickte auch wirklich Martin ist und
erwartet eine CertificateVerify-Nachricht, um dies überprüfen zu können. Nun
kann zwar Thomas die CertificateVerify-Nachricht, mit der zuvor Martin seine Identität nachwies, an Roland
schicken, doch passt diese CertificateVerify-Nachricht jetzt nicht mehr zur
neuen Sitzung, da die neue Sitzung ein anderes Master Secret besitzt und Roland
die Unterschrift in der CertificateVerify-Nachricht nicht verifizieren
kann..... der Schwindel ist aufgeflogen.
Nach einem
erfolgreicher Handshake der Verbindungsart 3 können sich schließlich die beiden
Kommunikationspartner der Identität ihres Gegenübers sicher sein und mit dem
verschlüsselten Datenaustausch beginnen.
Abschließende Bemerkung zum SSL-Protokoll
Auf den ersten
Blick scheinen viele Details des SSL-Protokolls unmotiviert oder ohne Funktion
zu sein. Die Wirkung vieler dieser kleinen Details und somit auch der Grund
dafür, dass diese in das SSL-Protokoll aufgenommen wurden, werden erst klar,
wenn man versucht Sicherheitslücken zu finden. Hier sei vor allem auf den Anhang
F "Security Analysis"
der SSL Spezifikation verwiesen, wo einige Methoden und Verfahren motiviert
werden.
Bei sämtlichen
Sicherheitsüberlegungen ist immer zu bedenken, dass ein System genau so sicher
wie die unsicherste Stelle des Systems ist. So ist SSL unter den im Abb. 3
dargestellten Randbedingungen ein absolut sicheres System. Dies setzt natürlich
eine fehlerfreie Implementierung der SSL-Spezifikation voraus. Ein weiterer
heikler Punkt sind die Zertifikate. So kann nur eine einzige fälschlicherweise
als vertrauenswürdig eingeschätzte Authentifizierungsstelle fatale Folgen
haben.
Die
Randbedingungen des SSL-Protokolles setzen voraus, dass sich die beiden
Kommunikationspartner in geschützten Umgebungen aufhalten. Dies bedeuten zum
Beispiel, dass ein Angreifer keinen Zugang zu den erzeugten Master Secret hat
usw.
Der Autor diese
Dokumentes ist der Meinung, dass Angriffe auf das SSL-Protokoll selbst
wahrscheinlich unmöglich sind. Doch solange Angriffe auf die Systeme möglich
sind, auf denen die Server- bzw. die Clientenapplikationen laufen, solange wird
auch SSL nicht wirklich 100% sicher sein.
Abschließend noch
ein Beispiel das zum Nachdenken anregen soll...
Bsp. Idee
eines möglichen Angriffes:
Bei diversen
Internet-Browsern soll es angeblich möglich sein, fremden Code zur Ausführung
zu bringen. Angenommen dieser Code würde in der Browsersoftware eingetragene
Root CA's so verändern, dass in Zukunft auch Zertifikaten vertraut wird, die
man sich selbst anfertigt ....
Referenzen:
Hier einige Links
zum Thema SSL beginnent mit den Links von Netscape, dem Erfinder...
Internetdraft
(Spezifikation SSL 3.0)
Hompage des "Open SSL" Projektes
Ausarbeitungen und
Links zum Thema "Security and Encryption" (sehr gut!)
Verschlusssache Sicherheit im
World Wide Web
www.ietf.org (weitere RFC von Methoden die in SSL
eingesetzt werden)