1) Vorausgesetzt wird:
- Eine bestehende Verbindung zwischen den Partnern A und B.
- Ein Schlüssel, der beiden Partnern vorliegt.
- Dieser Schlüssel ist nur A und B bekannt und wurde nicht ausgespäht.
Dann können beide Partner mit diesem Schlüssel Daten verschlüsseln und über die bestehende Verbindung übertragen.
Die entsprechenden Verfahren zur Verschlüsselung werden als „symmetrische Verschlüsselungsverfahren" bezeichnet.
Symmetrische Verschlüsselungsverfahren
Die symmetrische Verschlüsselung benutzt den gleichen Schlüssel zur Ver- und Entschlüsselung. Eine Verschlüsselung von großen Datenmengen ist daher in vertretbarer Zeit möglich. Offensichtliches Problem ist, dass beide Seiten den (geheimen) Schlüssel kennen müssen.
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.
2) Aufgrund der oben dargestellten Problematik muss der „symmetrische Schlüssel" vor der eigentlichen Verwendung gesichert (verschlüsselt) ausgetauscht werden.
Bei SSL wird dazu (vorübergehend) ein gesicherter (verschlüsselter) Kommunikationskanal für die Übertragung des symmetrischen Schlüssels generiert. Dazu werde asymmetrische Verschlüsselungsverfahren eingesetzt.
Asymmetrische Verschlüsselungsverfahren
Hinweis: Das dargestellte Verfahren ist nicht speziell nur auf den Verbindungsaufbau in SSL bezogen.
Bei der asymmetrischen Verschlüsselung werden unterschiedliche Schlüssel zum Ver- und Entschlüsseln benutzt .
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 Public 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.
<![endif]> In SSL werden nun beide Verfahren benutzt (sogenanntes hybrides Verfahren), die Idee ist dabei folgende: Mit Hilfe der asymmetrischen Verschlüsselung tauschen Client und Server einen Schlüssel aus. Dieser Schlüssel wird dann zur symmetrischen Verschlüsselung benutzt.
Beachte:
Die Punkte 1) und 2) zeigen, dass die mit SSL gewonnene Sicherheit sich „lediglich" auf die Problematik der evtl. abhörbaren/manipulierbaren Verbindung zwischen den Partnern bezieht (Kommunikationskanal).
3) Um ein überprüfbares Kriterium beim Empfänger zu haben, ob ein empfangenes Dokument tatsächlich von dem angegebenen Absender stammen und auch nicht während der Übertragung manipuliert wurde, kann ebenfalls unter Einsatz der asymmetrischen Verschlüsselung und einer sog. Hash-Funktion vom Absender eine „digitale Unterschrift" erzeugt werden.
Auch dieser Aspekt wird in SSL für die einzelnen Datenpakete genutzt (siehe Abschnitt „Secure Stocket Laxer Protocol"), kann aber auch zur Signierung von Mails verwendet werden, wenn man auf sonstige Verschlüsselung verzichtet.
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. 7 Die Erstellung einer digitalen Unterschrift
Abb. 8 Die Überprüfung einer digitalen Unterschrift
4) Bleibt als letztes die Frage zu klären, wie die Partner überprüfen können ob die öffentlichen Schlüssel der Gegenseite „echt" sind. Diese Überprüfung erfolgt mittels Zertifikaten, die von Zertifizierungsstellen ausgestellt werden.
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.
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)
Die folgende Abbildung soll dies verdeutlichen:
Der Text.txt stelle ein Mail dar.
A, B = Mailclient
S = Mailserver
Abbildung A
Auf dem Mailserver liegt der unverschlüsselte Mailtext vor, obwohl der Server „nur" eine Zwischenstation darstellt. Läuft die Verbindungen A/B über mehrere Server evtl. mit Abschnitten ohne SSL wird die Mail dort völlig ungeschützt übertragen.
Alternative ist/wäre eine doppelte Verschlüsselung:
Die Verschlüsselung im Kommunikationskanal erfolgt automatisch, die Verschlüsselung des Klartexts erfolgt durch den Sender (Anwender) mit dem Public-Key des Empfängers, die Entschlüsselung kann dann nur B mit seinem Private-Key vornehmen. D.h. für die Verschlüsselung des Klartexts „durch den Anwender" wird ein asymmetrische Verschlüsselungsverfahren verwendet.
Abbildung B
Auf keinem der zwischengeschalteten Server liegt die Mail im Klartext vor, obwohl der Abschnitt zwischen den Servern nicht SSL-geschützt ist. Trotzdem ist die Verschlüsselung in SSL nicht überflüssig, da die lokale Übermittlung des Anmeldepassworts z.B. beim Abholen der Mail durch B geschützt wird.
Des weiteren könnte auf dem nicht mit SSL geschützten Abschnitt zwischen den Servern theoretisch ein „Man in the middle" die verschlüsselte Mail abfangen und durch eine andere ersetzen.
Man erkennt in beiden Abbildungen die abschnittweise Wirkung von SSL.
Eine Certification Authority (CA) stellt ein Zertifikat für einen Server aus. Dieses Zertifikat beinhaltet die ID des Servers sowie seinen public key. Das Zertifikat wird mit dem private key der CA unterschrieben und ist damit fälschungssicher. Der Server bekommt einmalig von der CA dieses Zertifikat ausgestellt. Will sich ein Client nun von der Echtheit des Servers überzeugen, so schickt der Server sein Zertifikat an den Client. Dieser kann das Zertifikat mit dem public key der CA (dieser muss dem Client bekannt sein) überprüfen und kann nun sicher sein, dass der Server „echt“ ist (also, dass der public key tatsächlich dem gewünschten Server entspricht).
Ü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.
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 Handshake Protokoll
Zu beachten ist, dass dieses Protokoll abläuft, bevor die eigentlichen Anwendungsdaten übertragen werden.
Ein SSL Steuerprotokoll hat folgenden grundlegenden Aufgaben:
- Aushandeln des Verbindungsmodalitäten
Da SSL verschiedene Kompressions- und Verschlüsselungsverfahren unterstützt müssen diese zwischen Client und Server vor dem eigentlichen Datenaustausch vereinbart werden.
- Austausch von Zertifikaten
Um dem Client die Möglichkeit zu geben, die Echtheit (also Zuordnung Server ID zum public key) des Servers zu überprüfen, verschickt der Server sein Zertifikat. Diese Zertifikat bestätigt die Zuordnung des Servers zu seinem public key. Umgekehrt kann auch der Server die Zertifizierung des Client verlangen - dies verläuft völlig analog und wurde daher in die weitere Betrachtung nicht mit einbezogen.
- Schlüsselaustausch
Um für die spätere Datenübertragung aus Effizienzgründen ein symmetrisches Schlüsselverfahren benutzen zu können, muss ein Schlüsselaustausch zwischen Server und Client erfolgen. Dieser Austausch muss natürlich (asymmetrisch) verschlüsselt erfolgen.
- Überprüfung der Verbindung
Nach Aushandlung der Verbindungsmodalitäten wird überprüft, ob die Kommunikation zwischen Client und Server funktioniert und danach werden die eigentlichen Daten der Anwendung vom Record Layer übertragen.
Folgende Abbildung zeigt den Ablauf des Handshake Protokolls:
Der Client schickt ein CLIENT HELLO zum Server und bringt seinen Kommunikationswunsch zum Ausdruck. Der Server reagiert auf diese Anfrage mit einem SERVER HELLO. Dabei werden auch die Verbindungsmodalitäten ausgehandelt (Komprimierungs- und Verschlüsselungsverfahren). Der Server schickt ebenfalls sein Zertifikat (CERTIFICATE) und unter Umständen eine Zertifikatanforderung und signalisiert dann das Ende der Hallo-Phase.
Der Client überprüft das Zertifikat, generiert einen Schlüssel, verschlüsselt diesen mit dem public key des Servers und schickt den verschlüsselten Schlüssel als CLIENT KEY EXCHANGE. Danach schaltet der Client seinen Status um, signalisiert dies mit CNG CIPHER SPEC und verschickt eine - nun mit ausgehandelten Methoden verschlüsselte - Ende-Nachricht (FINISH). Der Server empfängt den Schlüssel schaltet seinen Status ebenfalls um, signalisiert dies und sendet ebenfalls eine Endenachricht.
Beide Seiten untersuchen die empfangene Endenachricht auf Korrektheit und danach kann die sichere Übertragung der Anwendungsdaten beginnen.
Nach vollständiger Übertragung wird die andere Seite mit CLOSE NOTIFY vom Schließen der Verbindung informiert und die Sitzung ist beendet.
Inhalt und Aufgaben der einzelnen Pakete werden nun genauer beschrieben.
Phase 1 - Verbindungsanfrage
Der Client eröffnet den Handshake
CLIENT HELLO
Dient dem Verbindungsaufbau und beinhaltet folgende Informationen
|
|
|
Möchte der Client eine in der Vergangenheit ausgehandelte Verbindung mit diesem Server wieder benutzen, dann wird die alte SitzungsID angegeben. Soll eine neue Verbindung eingerichtet werden, ist der Wert der SitzungsID Null. |
|
Diese Liste enthält in der präferierten Reihefolge die unterstützten Kompressions- und Verschlüsselungsmethoden des Client.
Dieses Paket wird unverschlüsselt gesendet.
Danach wartet der Client auf die Reaktion des Servers.
Phase 2 - Reaktion des Servers
Der Server empfängt das CLIENT HELLO. Falls der Client eine SitzungsID ungleich Null angegeben hatte, so überprüft der Server, ob er diese ID kennt und entscheidet, ob die Verbindung ohne neue Aushandlung wieder aufgenommen werden soll. Ist dies der Fall, so schickt er ein SERVER HELLO mit der gleichen SitzungsID zurück und das Handshake Protokoll ist beendet.
SERVER HELLO
Diese Paket dient zur Mitteilung der Verbindungsparameter:
- Protokollversion
Die niedrigere der unterstützen Protokollversionen von Client und Server wird ausgewählt.
- Verschlüsselungs- / Kompressionsmethoden
Je nach Unterstützung und Präferenz von Client und Server werden diese ausgewählt. (eine Kompressionsmethode, und je ein asymmetrisches, symmetrisches und ein Hashverfahren)
Auch dieses Datenpaket ist unverschlüsselt.
Des weiteren sendet der Server sein Zertifikat.
CERTIFICATE
Dieses Zertifikat ist unterschreiben durch eine Certification Authority und bestätigt die Echtheit des Servers (d.h. die Zuordnung des Servers zu seinem public key).
Wünscht der Server eine Zertifizierung des Client, so kann er ein Zertifikat anfordern:
CERTIFICATE REQUEST
Anforderung des Client Zertifikates, nicht verschlüsselt.
Zum Abschluss schickt der Server ein
SERVER HALLO DONE
Der Server wartet auf die Antwort des Client.
Phase 3 - Bestätigung des Client
Der Client empfängt SERVER HELLO und erkennt an der SitzungsID, ob eine alte Verbindung wieder aufgenommen wird, oder ob neu verhandelt werden muss. Falls eine alte Verbindung wieder aufgenommen wird, so ist der Handshake beendet.
Andernfalls wartet der Client auf das Zertifikat des Servers, überprüft es und kennt nun den public key des Servers. Der Client generiert einen Master Key (Hauptschlüssel) und verschlüsselt ihn mit dem public key des Servers und schickt ihn an den Server
CLIENT KEY EXCHANGE
Dient zur Übermittlung des Master Key und ist mit public key des Servers verschlüsselt.
Anschließend werden aus dem Master Key in Abhängigkeit der ausgewählten Verschlüsselungsverfahren neue Schlüssel erzeugt. Dazu werden für jedes Verschlüsselungsverfahren spezifische Algorithmen benutzt. Diese sind in der SSL Spezifikation enthalten.
Der Client kennt nun alle Verbindungsparameter zur sicheren Übertragung und ist bereit zum Verschlüsseln. Er signalisiert dies:
CHANGE CIPHER SPEC
Mitteilung, dass ab jetzt verschlüsselt gesendet wird. Die Meldung selber ist aber noch unverschlüsselt.
Danach schaltet er seinen Status um und schickt eine Ende Nachricht:
FINISH
Mitteilung über Ende des Handshake, verschlüsselt mir vereinbarten Methoden und Schlüsseln.
Der Client wartet auf die Ende Meldung des Servers.
Phase 4 - Handshake Abschluss
Der Server empfängt CLIENT KEY EXCHANGE und entschlüsselt das Paket mit seinem private key. Aus dem nun vorliegenden Master Key kann der Server analog zum Client die gleichen Schlüssel für die ausgewählten Verfahren generieren. Nun hat auch der Server alle Informationen, um seinen Status umzuschalten. Er sendet eine entsprechende Nachricht
CHANGE CIPHER SPEC
Mitteilung, dass ab jetzt verschlüsselt gesendet wird. Die Meldung selber ist aber noch unverschlüsselt.
und schaltet danach seinen Status um. Danach verschickt er eine verschlüsselte Ende Nachricht
FINISH
Mitteilung über Ende des Handshake, verschlüsselt mir vereinbarten Methoden und Schlüsseln.
Sowohl Client als auch Server warten auf das FINISH. Ist diese korrekt (d.h. richtig verschlüsselt) so kann die sichere Datenübertragung beginnen.
Datenaustausch
Der Datenaustausch erfolgt nun verschlüsselt mit den ausgehandelten Methoden.
Das SSL Record Protokoll
Das SSL Record Protokoll nimmt Datenblöcke beliebiger Größe entgegen, fragmentiert diese in Blöcke geeigneter Größe, wendet optional einen Komprimierungsalgorithmus an, führt weiteres 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.
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.
Abschließende Bemerkung zum SSL-Protokoll
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 ....
Verwendete Links:
www.tfh-berlin.de/~toby/vs/ssl
http://www.ssw.uni-linz.ac.at/Teaching/Lectures/Sem/2000