2.2.2 Technologien zur sicheren Datenübertragung
Bei einer Datenerhebung über das Medium Internet ist es wichtig, dass die eingegebenen Daten korrekt übermittelt werden. Zusätzlich muss sichergestellt werden, dass die Daten durch Hacker nicht ausspioniert bzw. manipuliert werden können.
Der Begriff des Hackers kann positiv oder negativ dargestellt werden. Bei der positiven Betrachtung bedeutet der Begriff, dass ein Hacker eine Person mit tiefen Fachkenntnissen ist, die Sicherheitslücken aufzeigt und zu beseitigen versucht oder sie den zuständigen Personen mitteilt, damit sie geschlossen werden können. Oftmals wird der Begriff in negativer Weise verwendet und meint damit eine Person, die unbefugt Sicherheitsbarrieren umgeht und die Sicherheitslücken ausnutzt (vgl. [Wiki09h1]). Diese negative Definition soll verwendet werden.
Damit eine Datenmanipulation erschwert bzw. verhindert wird, gibt es verschiedene Verfahren zur Authentifizierung und sicheren Datenübertragung mittels Webbrowser. Drei solcher Methoden sollen in den nächsten Abschnitten erläutert werden. Dabei handelt es sich um folgende Methoden: Basic Authentication/Digest Access Authentication (Kap. 2.2.2.1), Secure Hypertext Transfer Protocol (Kap. 2.2.2.2) und Secure Socket Layer (Kap. 2.2.2.3).
2.2.2.1 Basic Authentication/Digest Access Authentication
Die Basic Authentication ist ein standardisiertes Verfahren, mit dem sich ein Nutzer mittels Webbrowser bei einem Server als Benutzer authentifizieren kann. Dieses Verfahren ist - wie es der Name "Basic" ausdrückt - in jedem gängigen Browser implementiert. Es schützt Dokumente oder Verzeichnisse vor unerlaubtem Zugriff. Jedoch garantiert es nur die Authentifizierung, d. h. kryptografische Verschlüsselung der Dateien wird bei diesem Verfahren nicht unterstützt (vgl. [Zahn98]).
Die Authentifizierung durchläuft folgende Schritte (vgl. [Wiki09h2]):
- Der Webserver fordert eine Authentifizierung für die geschützte Datei an.
- Daraufhin sucht der Browser nach Benutzername und Passwort für diese Datei. Findet er keine Informationen, so wird der Benutzer gefragt.
- Anschließend sendet der Browser die Daten mit dem Authorization-Header an den Server.
- Wenn die Authentifizierung erfolgreich war, wird die Datei an den Benutzer gesendet. Ist das nicht der Fall, so wird der Vorgang abgebrochen.
Bei der Digest Access Authentication verläuft die Authentifizierung ähnlich der Basic Authentication. Der Unterschied zwischen den beiden Verfahren ist, dass beim Basic Authentication das Passwort und der Benutzername im Klartext über das Web transportiert werden, was beim Digest Access Authentication nicht der Fall ist.
Bei dieser Methode sendet der Server neben der Forderung einer Authentifizierung (Punkt 1) noch eine zufällig erzeugte Zeichenfolge an den Benutzer. Der Browser berechnet dann den Hashcode , d. h. eine Kombination aus Benutzername, Passwort, erhaltener Zeichenfolge, http-Methode und angeforderter URL (Uniform Resource Locator) welche dann mit dem Benutzernamen an den Server gesendet wird (Punkt 3). Der Server berechnet anschließend eine Prüfsumme und entscheidet, ob die Authentifizierung erfolgreich ist oder nicht (Punkt 4). Wichtig ist hierbei zu bedenken, dass die restliche Datenübertragung nicht weiter gesichert ist (vgl. [Wiki09h2]). Dies wird erst mittels S-HTTP möglich, welches im folgenden Kapitel erläutert wird.
2.2.2.2 Secure Hypertext Transfer Protocol (S-HTTP)
S-HTTP (Secure HTTP) ist eine Erweiterung des Protokolls HTTP (Hypertext Transfer Protocol), welches für die sichere Übertragung von Daten in einem Netzwerk genutzt wird. Der Name lässt darauf schließen, dass dieses Protokoll durch das https in der Adressleiste angezeigt wird, dies ist allerdings nicht der Fall. Das S-HTTP baut auf drei Arten von Sicherheit auf: Unterschrift , Authentifizierung und Verschlüsselung, welche sich alle auf den Benutzer beziehen. Es "kapselt gewöhnliche HTTP-Nachrichten" [Zahn98]. Die in der Nachricht enthaltenen Nutzdaten werden wie folgt verschlüsselt:
- Chiffriert
- Signiert
- Chiffriert und signiert
[Zahn98]
Der Unterschied zwischen signieren und chiffrieren, d. h. verschlüsseln, ist folgender: Signierte Nachrichten bieten dem Empfänger die Möglichkeit, die Identität des Absenders zu überprüfen und davon auszugehen, dass die Datei während der Übertragung nicht manipuliert wurde. Hierbei muss nur der Sender die Nachricht signieren. Verschlüsselte Nachrichten sind sicherer als nur signierte. Diese arbeiten mit Zertifikaten des Senders und Empfängers einer Nachricht, d. h. nur wenn der Sender den öffentlichen Schlüssel des Empfängers besitzt, kann eine Nachricht chiffriert werden (vgl. [Apple09]).
Das bedeutet, dass das S-HTTP eine Reihe von Verfahren "für das Handshake , für Chiffrierung , digitale Unterschrift und mehr" [Zahn98] unterstützt, sodass sich Dokumente vertraulich austauschen und leicht signieren lassen (vgl. [Zahn98]).
Dieses Verfahren definiert einen sicheren Datenaustausch zwischen Webserver und Webbrowser, indem es die Nutzdaten kapselt. Der Header ist bei diesem Verfahren nicht verschlüsselt. Daher ist es ratsam, das SSL zu verwenden, was eine komplett sichere Verbindung aufbaut (vgl. [Wiki09s1]). Das SSL-Verfahren wird im folgenden Kapitel erläutert.
2.2.2.3 Secure Socket Layer (SSL)/Transport Layer Security (TLS)
In der Literatur findet man oft die Bezeichnung SSL (Secure Socket Layer), welches das Vorgängermodell des TLS (Transport Layer Security) ist (vgl. [Wiki09t1]). Auf Grund des häufigen Vorkommens von SSL in der Literatur wird in dieser Ausarbeitung das Verfahren auch weiterhin unter dem Begriff SSL geführt.
Das SSL ist ein hybrides Verschlüsselungsprotokoll, das zur sicheren Datenübertragung im Internet genutzt wird (vgl. [Wiki09t1]). Es liegt funktional zwischen dem Aufgabenbereich von TCP/IP und den Anwendungen. Jedoch wird es weder von den Transportprotokollen noch von den Applikationen bemerkt, da es transparent arbeitet, d. h. es müssen keine zusätzlichen Änderungen getätigt werden, damit SSL genutzt werden kann. Während einer sicheren Verbindung kommunizieren die Rechner ausschließlich über den Mechanismus, der von SSL bereitgestellt wird. Soll keine sichere Verbindung hergestellt werden, schaltet sich das SSL-Protokoll selbstständig aus.
Das SSL-Protokoll wird gestartet, indem das bekannte http (in der Adressleiste des Webbrowsers) um ein "s" erweitert wird, d. h. https. Folgende Schritte werden dann von dem Browser und Server abgearbeitet (vgl. [Rojahn07]):
- Der Browser fordert vom angesprochenen Server ein Zertifikat und seinen öffentlichen Schlüssel an.
- An den Browser wird der Schlüssel mit einer Prüfsumme und einer ID zurückgeliefert.
- Der Browser prüft anhand der übermittelten Daten, ob er wirklich mit dem Server verbunden ist, der in der URL angegeben ist. Ob das der Fall ist, wird auf unterschiedliche Weise dargestellt (siehe "Empfehlungen für die IT" im Kapitel 4.2).
- Beide Rechner verständigen sich auf einen symmetrischen Schlüssel, der Session Key genannt wird. Da die Absprache in asymmetrischer Verschlüsselung vollzogen wird, ist die Sicherheit gegeben.
- Vom Browser werden vor dem Datenaustausch Testnachrichten versendet, die nur der Server beantworten kann, wenn es wirklich der Server ist, der er zu sein vorgibt.
Nachdem alle fünf Schritte erfolgreich absolviert worden sind, können die Daten von beiden Parteien mit dem Session Key verschlüsselt, übertragen und entschlüsselt werden (vgl. [Rojahn07]).
Neben den bekannten SSL-Zertifikaten gibt es seit 2006 eine Erweiterung, nämlich die Extended Validation SSL-Zertifikate (EV-SSL). Diese Zertifikate bieten "in hochsicheren Webbrowsern Informationen zur eindeutigen Identifizierung des Unternehmens, das hinter einer Website steht" [VeriSign09]. Wie sich die EV-Zertifikate "sichtbar" machen lassen, wird ebenfalls im Kapitel 4.2 "Empfehlungen für die IT" genauer beschrieben.