Email-System und Email-Sicherheit

Rheinisch-Westfälische Technische Hochschule Aachen
Lehrstuhl für Informatik IV
Prof. Dr. rer. nat. Otto Spaniol
E-Mail-Systeme und E-Mail-Sicherheit
Seminar: Kommunikationsprotokolle
Sommersemester 2003
Schamil Wackenhut
Matrikelnummer: 232502
Betreuung:
Yuri Babich
Lehrstuhl für Informatik IV, RWTH Aachen
Inhaltsverzeichnis
1
Einführung
1
2
Grundlagen
1
2.1
Mail User Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
2.2
Mail Transport Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2.3
Mail Delivery Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
3
4
5
Protokolle
3
3.1
SMTP - Simple Mail Transfer Protocol . . . . . . . . . . . . . . . . . . . . . . . . .
3
3.2
POP3 - Post Office Protocol 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
3.3
IMAP - Internet Message Access Protocol . . . . . . . . . . . . . . . . . . . . . . .
8
3.4
Aufbau einer E-Mail, Attachments (multi-part) . . . . . . . . . . . . . . . . . . . .
10
3.5
Probleme der Protokolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
Sicherheit
13
4.1
Verschlüsselung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
4.1.1
Symmetrische Verschlüsselung . . . . . . . . . . . . . . . . . . . . . . . . .
13
4.1.2
Public Key Verfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
4.1.3
Hybride Verschlüsselung . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
4.2
Digitale Signatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
4.3
TLS/SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
4.3.1
Aufbau der Verbindung bei TLS . . . . . . . . . . . . . . . . . . . . . . . .
20
4.3.2
STARTTLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
4.3.3
Grenzen von STARTTLS im SMTP . . . . . . . . . . . . . . . . . . . . . .
21
Zusammenfassung
22
Abbildungsverzeichnis
1
E-Mail System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2
Symmetrische Verschlüsselung
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
3
Hybride Verschlüsselung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
4
POP3 Plain Text Kommunikation
. . . . . . . . . . . . . . . . . . . . . . . . . . .
19
5
TLS Schicht
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
1
Einführung
Diese Arbeit beschreibt das wohl am weitesten verbreitete Medium der elektronischen Kommunikation im Internet, die ,,E-Mail”. E-Mail hat sicherlich jeder schon einmal benutzt oder zumindest etwas
davon gehört.
Diese Arbeit versucht die Grundlagen und die Funktionsweise der E-Mail-Systemen sowie die Sicherheitsaspekte zu erklären. Es werden Beispielsessions zur Kommunikation einzelner Komponenten des
Systems vorgestellt, unter anderem wird auf die Verschlüsselung von E-Mail-Inhalten, sowie auf die
Verschlüsselung bei der Kommunikation eingegangen.
Diese Ausarbeitung fasst die wichtigsten Informationen zum Thema zusammen, versucht aber, nicht
zu technisch zu wirken, so dass die Personen, die sich mit dem Thema noch nicht auseinander gesetzt
haben, motiviert sind, sich diese Arbeit durchzulesen.
Der erste Teil beschäftigt sich mit der grundlegenden Funktionsweise des E-Mail-Systems und dem
Aufbau einer E-Mail.
Im zweiten Teil wird es ein wenig technischer. Es werden Protokolle vorgestellt, die während des
Verschickens bzw. Abholens der E-Mail verwendet werden. Der zweite Teil beinhaltet viele Beispiele,
die die vorgestellte Theorie veranschaulichen.
Im dritten und letzten Teil werden die gängigen Verschlüsselungsmechanismen und -verfahren vorgestellt und erklärt.
2
Grundlagen
Sehen wir uns zuerst einmal die Grundlagen an, auf welche Weise eine E-Mail vom Absender zum
Empfänger gelangt.
2.1 Mail User Agent
Zuerst wird ein Text mit Hilfe eines Editors erstellt, der verschickt werden soll. Der Editor wird meistens bei dem verwendeten Mail User Agent (MUA)1 mitgeliefert. Mail User Agents stellen also sozusagen die Mensch-Maschine Schnittstelle dar, die dem User hilft E-Mails zu verfassen, verschlüsseln,
verwalten und zu ,,verschicken”. Den eigentlichen Versand der E-Mail übernimmt der sogennante
Mail Transport Agent (MTA), der dafür sorgt, dass die E-Mail beim Empfänger ankommt, gegebenenfalls auch über mehrere Stationen. Das heißt, dass E-Mails evtl. zuerst an andere Mail Transport
Agents weitergegeben werden, bis sie beim gewünschten Client ankommen.
1
z.B. mutt, Outlook Express etc.
1
2.2 Mail Transport Agent
Die Mail Transport Agents (MTA) sind so genannte Mailserver. Der Weg vom Mail User Agent
zum Mail Transport Agent sieht nicht immer gleich aus. Manchmal wird ein eigener Mail Transport
Agent betrieben, an den die E-Mail weitergegeben wird und der dann für die Zustellung sorgt. Nicht
jeder hat die Möglichkeit, einen eigenen Mail Transport Agent zu betreiben, also muss der Mail User
Agent in der Lage sein, eine TCP/IP Verbindung zu einem Server, z.B. SMTP.gmx.de, aufzubauen.
Die anschließende Übergabe erfolgt über das Simple Mail Transfer Protocol (SMTP), auf das ich im
zweiten Teil näher eingehen werde.
Sobald die E-Mail an den MTA übergeben wurde, wird sie verschickt, und wandert per SMTP von
einem Mail Transport Agent zum nächsten, bis irgendwann der MTA erreicht ist, der die Mailbox
des Empfängers betreibt. Der Versand erfolgt direkt von einem Client-MTA zu einem Server-MTA,
wenn die beiden direkt verbunden sind (z.B. LAN). Ist dies nicht der Fall, erfolgt der Versand über
ein oder mehrere Relay-MTAs. Der zwischenliegende Host kann entweder ein Relay-MTA oder ein
Gateway sein, das das Ganze in eine andere Versandumgebung einpackt (z.B. statt TCP wird NITS2
oder X.25 benutzt). Dieser Host wird mit Hilfe der DNS3 Mail eXchanger Funktion ausgewählt.
Üblicherweise werden diese Hosts nicht per explizitem ,,source routing” ausgewählt, sondern durch
die oben genannten DNS MX records.
Sobald die E-Mail bei dem zuständigen Mail Transport Agent angekommen ist, so übergibt dieser die
angenommene E-Mail an den Mail Delivery Agent.
2.3 Mail Delivery Agent
Der Mail Delivery Agent kümmert sich um die endgültige Auslieferung der E-Mails an die Mailbox. Er sorgt dafür, dass sich zwei gleichzeitige Zugriffe auf die Mailbox gegenseitig nicht in die
Quere kommen. Einige Mail Delivery Agents erledigen zusätzlich komplexere Aufgaben, z.B. Filtern
von Werbung bzw. Spam, Verwaltung von Mailinglisten (lokal), Scannen der E-Mails aif Viren oder
automatische Beantwortung bestimmter Anfragen. Ein klassisches Beispiel für einen Mail Delivery
Agent ist das Programm ,,mail”, das auf jedem UNIX System vorhanden ist. Ein wenig mächtiger ist
,,procmail”.
Falls die E-Mails über einen Provider, wie z.B GMX, empfangen werden, müssen die E-Mails, nachdem sie auf dem GMX Server in eine für den User vorgesehene Mailbox geschrieben wurden, abgeholt werden. Dazu wird wieder eine TCP/IP Verbindung zum Server aufgebaut, die E-Mails mit Hilfe
von Post Office Protocol Version 3 (POP3) abgeholt und entweder in die lokale Mailbox geschrieben
oder an den lokalen Mail Transport Agent (MTA) übergeben. Dieser leitet die E-Mails an den lokalen
Mail Delivery Agent (MDA) weiter, der die E-Mails in die entsprechende lokale Mailbox schreibt.
Alternativ zu POP3 kann Internet Message Access Protocol (IMAP) verwendet werden. Im Gegensatz zu POP3 werden die E-Mails hier nicht abgeholt, sondern es wird direkt auf die Mailbox auf
2
3
Network Independent Transport Service
Domain Name Service
2
MTA
MDA
MUA
Mehrere
MTAs
POP3/IMAP
Mailbox
lokal
POP3/IMAP
Mailbox
Anbieter
MDA
MTA
Abbildung 1: E-Mail System
dem Server zugegriffen. Dies ist z.B. für vielreisende Leute vorteilhaft, da von jedem Rechner mit
Internetzugang die gesamte Korrespondenz verwaltet werden kann.
Der schematische Aufbau ist in Abb.1 dargestellt.
3
Protokolle
Nun verfolgen wir eine E-Mail von ihrem Startpunkt aus bis zum Ende. Zunächst muss vom MUA
eine E-Mail erstellt werden. Der Benutzer gibt die Information, die verschickt werden soll, sowie den
Empfänger und evtl. Dateien, die mit der E-Mail verschickt werden sollen ein.
Eine E-Mail sieht danach (minimal) folgendermaßen aus:
From: Schamil Wackenhut <[email protected]>
To: [email protected]
Subject: test
Hallo, das ist ein test
Danach wird diese E-Mail vom MUA über eine TCP/IP Verbindung an den MTA übergeben. Und
zwar wird eine TCP Verbindung aufgebaut. Die Kommunikation zwischen MUA und MTA ist in
Simple Mail Transfer Protocol (SMTP) [1] festgelegt.
3.1 SMTP - Simple Mail Transfer Protocol
SMTP ist das Protokoll, welches für Mailtransport und -zustellung verantwortlich ist. Die Übergabe
der E-Mail vom MUA an den MTA kann am einfachsten mit einer telnet Sitzung nachgespielt werden:
$ telnet mail 25
Trying 10.0.0.2...
3
Connected to mail.wackes.netz.
Escape character is ’ˆ]’.
220 mail.wackes.netz ESMTP Sendmail 8.12.7/8.12.4; \
Thu, 20 Mar 2003 14:41:12 +0100
Nachdem die Verbindung aufgebaut wurde, meldet sich der Mailserver mit einer Zeile, die als erstes
den Erfolgsstatuscode 220 und danach den Rechnernamen sowie Informationen zum verwendeten
MTA, in unserem Fall Sendmail, enthält. Anschließend gibt der Client seinen Rechnernamen mit
dem Befehl helo4 bekannt:
helo localhost
250-mail.wackes.netz Hello localhost [127.0.0.1], pleased to meet you
Die Antwort besteht aus einer Zeile. Der MTA teilt mit, dass er für die Kommunikation bereit ist.
Somit ist der SMTP Handshake abgeschlossen.
Falls es sich um einen MTA handelt, der eine erweiterte Version von SMTP unterstuetzt (ESMTP)
(dies erkennt man an der Begrüßungszeile, falls dort das Schlüßelwort ESMTP vorkommt), so vertauscht man die ersten beiden Buchstaben in dem String helo:
ehlo localhost
250-mail.wackes.netz Hello localhost [127.0.0.1], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-EXPN
250-VERB
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-DELIVERBY
250 HELP
Nun teil der MTA teilt, welche Optionen bei der Übergabe der E-Mail zusätzlich benutzt werden
dürfen. Zum Beispiel können die E-Mails dank 8BITMIME in einem 8-Bit Format vorliegen und
müssen nicht vor dem Transport auf 7-Bit ASCII-Transport-Format [2] gebracht werden. SIZE erlaubt die Frage, ob eine evtl. überlange E-Mail zum Versand angenommen wird. DSN steht für Delivery Status Notification und ermöglicht eine Feineinstellung für den Versand von Fehler- und Erfolgsmeldungen.
Heutzutage wird aufgrund der zahlreichen Zusatzoptionen vorwiegend die erweiterte Version von
SMTP eingesetzt.
4
alle SMTP Befehle bestehen aus 4 Buchstaben
4
Als nächstes wird der Envelope der E-Mail übermittelt. Dieser enthält die Adresse des Empfängers
und die Adresse des Senders. Dabei werden die From: und To: Informationen aus dem Header der
E-Mail vom MTA in den Envelope übernommen. Während der Übertragung beachten die MTAs nur
das, was im Envelope steht. Der Headerinhalt ist nicht von Bedeutung, er wird ignoriert.
Der Unterschied zwischen Header und Envelope wird bei Mailinglisten ziemlich deutlich. Hier steht
die Mailingliste selbst im Header. Im Envelope werden aber die einzelnen Empfänger aufgeführt.
mail from:<[email protected]>
250 2.1.0 <[email protected]>... Sender ok
rcpt to:<[email protected]>
250 2.1.5 <[email protected]>... Recipient ok
MTA prüft die Adressen auf Fehler und reagiert jeweils mit einer Erfolgsmeldung mit dem Status
250.
data
354 Enter mail, end with "." on a line by itself
Der Befehl data leitet die eigentliche E-Mail ein. Dabei wechselt der MTA vom KommandozeilenModus zum Datenmodus, der durch eine Zeile abgeschlossen wird, die nur aus einem Punkt ”.” besteht.
From: Schamil Wackenhut <[email protected]>
To: [email protected]
Subject: test
Hallo das ist ein test
.
250 2.0.0 h2KDfCUZ001079 Message accepted for delivery
Zur E-Mail gehört wiederum ein Header und ein Body (der eigentliche Inhalt der Mail). Die E-Mail
wird mit einem Punkt abgeschlossen und die Nachricht vom MTA in die Warteschlange aufgenommen. Ab jetzt beginnt der Weg der E-Mail von einem MTA zum anderen. Nach der Übertragung der
E-Mail wird die Sitzung mit dem Befehl quit beendet:
quit
221 2.0.0 mail.wackes.netz closing connection
5
Nach einiger Zeit erreicht die E-Mail den für sie zuständigen MTA, der sie annimmt und an den MDA
übergibt, der sie wiederum in eine für den User vorgesehene Mailbox schreibt.
Da die E-Mails normalerweise nicht direkt in die lokale Mailbox geschrieben werden, sondern zunächst
beim Provider landen, müssen diese E-Mails von dort abgeholt werden. Dafür sind die beiden Protokolle Post Office Protocol 3 (POP3) [3] und Internet Message Access Protocol (IMAP) [5] zuständig.
Der Abholvorgang funktioniert folgendermaßen: Ein Programm auf dem Rechner des Empfängers
(zum Beispiel ,,fetchmail”) oder eine besondere Routine des MUA baut eine TCP Verbindung zum
Mailserver des Providers auf, wo sich die Mailbox des Users befindet. Es holt die E-Mails dort ab
und schreibt sie in die lokale Mailbox oder übergibt sie an den lokalen MTA, der sie wiederum an den
lokalen MDA weiterleitet, der die E-Mails dann auch in die lokale Mailbox schreibt.
Im Folgenden werden die beiden Protokolle vorgestellt.
3.2 POP3 - Post Office Protocol 3
Bei POP3 handelt es sich um ein relativ einfaches Protokoll, das zum Abholen der E-Mails von einem
entfernten Server auf die lokale Maschine eingesetzt wird.
Dazu wird im Folgenden einmal eine Beispielsitzung gezeigt:
$ telnet pop3 110
Trying 10.0.0.2...
Connected to pop3.wackes.netz.
Escape character is ’ˆ]’.
+OK
Nach dem Aufbau der Verbindung meldet sich der Server mit einer Erfolgsmeldung +OK. Danach
muss sich der Client authentifizieren. Sind die Angaben korrekt, so meldet der Server +OK, falls nicht
antwortet er mit -ERR.
USER test
+OK May I have your password, please?
PASS [S<8pfI5
+OK mailbox has 3 messages (4383 octets)
Die Anzahl und Gesamtgröße der wartenden E-Mails in der Mailbox lässt sich mit dem Befehl STAT
abfragen.
STAT
+OK 3 4383
6
Ähnlich lässt sich mit LIST entweder die Größe jeder E-Mail oder die Größe einer bestimmten Mail
anzeigen.
LIST
+OK mailbox has 3 messages (4383 octets)
1 1100
2 1343
3 1940
.
LIST 1
+OK mailbox has 3 messages (4383 octets)
1 1100
.
Zum Abholen der Mails vom Server dient der Befehl RETR. Daraufhin zeigt der Server die angegebene E-Mail an, welche von einer Zeile, die aus einem Punkt besteht, beendet wird.
RETR 1
+OK message follows
Return-Path: <[email protected]>
Received: ...
Date: Thu, 20 Mar 2003 17:10:55 +0100
From: Schamil Wackenhut <[email protected]>
To: [email protected]
Subject: test
Message-ID: <20030320161055.GA1574@fckp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.3i
Hallo das ist ein test
.
Zum Löschen wird das Kommando DELE benutzt, zum Beenden der Verbindung dient QUIT
DELE 1
7
+OK message deleted
QUIT
+OK bye
Connection closed by foreign host.
$
Wie man sieht, sind Aufbau und Funktionsweise von POP3 recht einfach.
3.3 IMAP - Internet Message Access Protocol
Komplizierter als POP3, dafür aber auch leistungsfähiger, ist IMAP [5]. Das Protokoll beinhaltet
auch Funktionen wie die dauerhafte Zuordnung und Speicherung der Attributen (Flags) zu einzelnen
E-Mails oder die Verwaltung komplexer hierarchischer Verzeichnisstrukturen und damit aller MailOrdner auf dem Server.
Innerhalb gewisser Grenzen kann ein IMAP Server mehrere Befehle gleichzeitig bebarbeiten. Noch
bevor die Antwort auf den ersten Befehl angekommen ist, sendet der Client bereits den nächsten.
Damit dabei nichts durcheinander kommt, schickt der Client am Anfang des Befehls ein eindeutiges
Tag mit, das der Server in der letzten Zeile der zugehörigen Antwort wiederholt.
Oft wird dazu ,,a0001”, ,,a0002”, ,,a0003”, ,,a0004” etc. benutzt. Ein IMAP Login mit dem vom
Client gewählten und vom Server fuer die Antwort übernommenen Tag sieht beispielsweise so aus:
$ telnet kasten 143
Trying 10.0.0.1...
Connected to kasten.
Escape character is ’ˆ]’.
* OK [CAPABILITY IMAP4REV1 LOGIN-REFERRALS STARTTLS AUTH=LOGIN]\
KASTEN.wackes.netz IMAP4rev1 2002.336 at Thu, 20 Mar 2003 22:15:35\
+0100 (CET)
Der erste Befehl fragt den Funktionsumfang (capability) des Servers ab. Dieser reagiert zunächst mit
einer unmarkierten Antwort. An Stelle des Tags steht hier ein Sternchen.
Danach folgt der Login des Benutzers, wobei der Benutzername und Passwort mitgeteilt werden:
a01 capability
* CAPABILITY IMAP4REV1 IDLE NAMESPACE MAILBOX-REFERRALS BINARY SCAN\
SORT THREAD=REFERENCES THREAD=ORDEREDSUBJECT MULTIAPPEND LOGIN-REFERRALS\
STARTTLS AUTH=LOGIN
a01 OK CAPABILITY completed
a02 login test /H),%$Da8!\g
8
a02 OK [CAPABILITY IMAP4REV1 IDLE NAMESPACE MAILBOX-REFERRALS BINARY\
SCAN SORT THREAD=REFERENCES THREAD=ORDEREDSUBJECT MULTIAPPEND] User\
test authenticated
Anschließend wählt der Befehl select einen Ordner aus. Neben den benutzerdefinierten Ordnern
gibt es immer einen virtuellen Ordner namens ,,INBOX”, in dem ankommende und ungefilterte EMails abgelegt werden. Der IMAP Server schickt daraufhin eine Reihe von Informationen über diesen
Ordner an den Client, unter anderem die Anzahl der neuen Nachrichten:
a03 select INBOX
* 1 EXISTS
* 1 RECENT
* OK [UIDVALIDITY 1048194957] UID validity status
* OK [UIDNEXT 2] Predicted next UID
* FLAGS (\Answered \Flagged \Deleted \Draft \Seen)
* OK [PERMANENTFLAGS (\* \Answered \Flagged \Deleted \Draft \Seen)]\
Permanent flags
* OK [UNSEEN 1] first unseen message in /var/mail/test
a03 OK [READ-WRITE] SELECT completed
fetch überträgt eine E-Mail, wobei Art und Umfang der gewünschten Daten angegeben sind. Das
hier verwendete Schlüsselwort RFC822 fordert eine dementsprechend formatierte E-Mail [2] an. Eine
Alternative wäre zum Beispiel ENVELOPE, wodurch die Daten aus dem SMTP Envelope angezeigt
werden. Der Befehl BODY.PEEK[HEADER], fordert nur den Header der E-Mail an. Damit kann
zum Beispiel ein Filterprogramm schon vor der Übertragung entscheiden, ob diese E-Mail überhaupt
erwünscht ist.
a04 fetch 1 RFC822
* 1 FETCH (RFC822 {335}
Return-Path: <[email protected]>
Received: (from freak@localhost)
by KASTEN.ram.rwth-aachen.de (8.11.6/8.11.3) id h2KLFN210203
for test; Thu, 20 Mar 2003 22:15:23 +0100 (CET)
Date: Thu, 20 Mar 2003 22:15:23 +0100 (CET)
From: Schamil Wackenhut <[email protected]>
Message-Id: <[email protected]>
To: test
hallo
FLAGS (\Recent \Seen))
a04 OK FETCH completed
9
Nach dem Text werden die aktuellen Flags der E-Mail angezeigt. Zum Löschen fügt man hier ein
Flag \Deleted hinzu und räumt anschließend die Mailbox mit expunge auf:
a05
* 1
a05
a06
* 1
* 0
* 0
a06
store 1 +FLAGS(\Seen \Deleted)
FETCH (FLAGS (\Recent \Seen \Deleted))
OK STORE completed
expunge
EXPUNGE
EXISTS
RECENT
OK Expunged 1 messages
Die Verbindung zum Server wird durch das Kommando logout beendet:
a07 logout
* BYE KASTEN.ram.rwth-aachen.de IMAP4rev1 server terminating connection
a07 OK LOGOUT completed
Connection closed by foreign host.
3.4 Aufbau einer E-Mail, Attachments (multi-part)
Im Folgenden ist Aufbau der E-Mail gezeigt:
From [email protected] Thu Mar 20 13:12:05 2003
Return-Path: <[email protected]>
Die erste Zeile zeigt den Absender aus dem Envelope der E-Mail. Die zweite Zeile gibt den ReturnPath an. An diese Adresse wird die E-Mail zurückgesendet, wenn der Empfänger nicht erreicht werden kann.
Received: from myhost.wackes.netz (localhost [127.0.0.1])
by myhost.wackes.netz (8.12.7/8.12.4) with ESMTP id h2KCC4UZ000730
for <[email protected]>; Thu, 20 Mar 2003 13:12:04 +0100
Received: (from sw@localhost)
by myhost.wackes.netz (8.12.7/8.12.4/Submit) id h2KCC4H2000729
for test@myhost; Thu, 20 Mar 2003 13:12:04 +0100
Diese beiden Zeilen beschreiben die Route der E-Mail durch die Mail Transport Agents (MTA). Die
Reihenfolge ist umgekehrt, d.h man liest von unten nach oben. Es ist zu sehen, dass die E-Mail
zuerst von dem User ,,sw” an den MTA (myhost.wackes.netz) übergeben wurde. Der MTA hat diese
akzeptiert, und hat sie in die Warteschlange gelegt. Die E-Mail ist an den User ,,test” adressiert. Der
hier verwendete MTA betreibt eine Mailbox für diesen User, also übergibt er diese an sich selbst, die
E-Mail wird also zugestellt.
10
Date: Thu, 20 Mar 2003 13:12:04 +0100
From: Schamil Wackenhut <[email protected]>
To: [email protected]
Subject: test
In diesem Abschnitt erkennt man die Zeit, wann die E-Mail abgeschickt wurde, den Absender (From:)
und den Empfänger (To:) sowie eine Betreffzeile (Subject:).
Message-ID: <20030320121204.GA726@fckp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Dies ist ein sehr wichtiger Teil der E-Mail. Zuerst wird der E-Mail mit der Message-ID ein eindeutiger
String zugewiesen. Dies ist besonders für Mailinglisten mit Archiven oder im Usenet5 wichtig, damit
jede E-Mail eindeutig identifiziert und gefunden werden kann.
Mime-Version: 1.0 steht für ,,Multipurpose Internet Mail Extensions” [4] und sagt dem Client,
dass diese E-Mail eine erweiterte Kodierung des Inhalts benutzen darf.
Content-Type: text/plain; charset=us-ascii besagt, dass es sich um eine nach RFC822
[2] standardisierte E-Mail handelt.
Content-Disposition: inline sagt dem Client, dass sich die komplette E-Mail inklusive
Attachments in einer Datei befinden, d.h. sobald der User diese E-Mail betrachtet, bekommt er auch
die Attachments zu sehen. Eine Variation davon wäre:
Content-Disposition: attachment, filename=datei.bsp
In diesem Fall kann der User entscheiden, ob er das Attachment ansehen möchte oder nicht.
Möchte man eine E-Mail mit Attachments verschicken, sieht die Content-Type Zeile zum Beispiel
folgendermaßen aus:
Content-Type: multipart/mixed; boundary="JgQwtEuHJzHdouWu"
Hier richtet sich der Inhalt der E-Mail nach dem String, der hinter boundary steht. Jeder Teil der
E-Mail begint mit diesem String, zum Beispiel:
--JgQwtEuHJzHdouWu
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Hallo das ist eine Mail mit Attachment
5
http://isc.faqs.org/faqs/usenet/what-is/part1/
11
Hier wird der Content-Type sowie Content-Disposition für dieses Teil deklariert. Das
eigentliche Attachment sieht wie folgt aus:
--JgQwtEuHJzHdouWu
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="fs.c"
void main(void){
printf("%08x.%08x.%08x.%08x.%08x.%08x.%08x\n");
}
--JgQwtEuHJzHdouWu
Hier ist zu sehen, dass Content-Disposition ein Attachment beschreibt, dessen Name ,,fs.c”
ist. In diesem Fall handelte es sich um eine Textdatei, die durch Content-Type: text/plain;
charset=us-ascii bezeichnet wird. Sollen zum Beispiel Binaries, also Programme, Archive etc.
verschickt werden, so sieht das Attachment-Abschnitt etwas anders aus:
--JgQwtEuHJzHdouWu
Content-Type: application/octet-stream
Content-Disposition: attachment; filename=test
Content-Transfer-Encoding: base64
f0VMRgEBAQAAAAAAAAA....
Content-Type wird nun anders codiert, und die folgende Zeile wird hinzugefügt:
Content-Transfer-Encoding: base64
Diese Zeile beschreibt, wie dieses Attachment in 7-Bit Form gebracht wurde. Dies ist aus Rücksicht auf alte SMTP-Versionen nötig. Dafür gibt es die acht Möglichkeiten. 7bit, 8bit, binary, quotedprintable, base64, ietf-token und x-token. Die Erklärung dieser Kodierungsverfahren würde den Rahmen dieser Ausarbeitung sprengen, deshalb verweise ich an dieser Stelle auf RFC2045 zur Beschreibung dieser Verfahren.
Zurück zu unserer E-Mail, die keine Attachments beinhaltete. Auf den Header folgt der Rest der EMail, der Body. Im Body stehen die Informationen, die übermittelt werden sollen, also der eigentliche
Inhalt der E-Mail.
Hallo,
heute sind’s 16 Grad draussen!
3.5 Probleme der Protokolle
Der Nachteil dieser teilweise einfachen Protokolle ist die Klartextübertragung der Passwörter im Netz,
wodurch die Möglichkeit der Manipulation der Daten und des Verkehrs erleichtert wird.
12
So können zum Beispiel ohne Probleme in einem lokalen Netz die Passwörter ausspioniert werden.
Der Header der E-Mail kann manipuliert werden, wodurch die Vertrauenswürdigkeit der E-Mail abnimmt. Der Inhalt der E-Mail kann sozusagen ,,on the fly” verändert werden.
Um Manipulationen zu verhindern, werden die im nächsten Kapitel vorgestellten Verschlüsselungsmechanismen, die beim Transport und beim Versand bzw. Empfang der E-Mails eingesetzt werden,
verwendet.
4
Sicherheit
Jeder, der eine E-Mail abschicken möchte, benötigt einen Internetzugang. Das Internet ist eine Infrastruktur, die viele Schwächen und Angriffspunkte aufweist. Betrachten wir zuerst einmal folgende
fiktive Situation:
Person1 trifft auf Person2, er will ihm Information mitteilen über seinen neuen Plan, wie man kostengünstig Wasserbomben herstellen kann. Es ist nun ein leichtes Spiel für Person3, das komplette
Gespräch mitzuverfolgen, um selbst die Wasserbomben zu basteln. Genau das will Person1 vermeiden. Also muss das Gespräch in einer Sprache ablaufen, der Person3 nicht mächtig ist.
Genauso ist es auch im Internet. Es ist sehr leicht, fremde E-Mails zu lesen bzw. manipulieren. Soll
vermieden werdem, dass Informationen an Dritte gelangen, kann der Inhalt der E-Mail auf unterschiedliche Weisen verschlüsselt werden.
Da man sich im Internet nicht gegenüber steht und demzufolge eine gewisse Anonymität herrscht, ist
oft nicht klar, ob die vorliegende E-Mail auch wirklich von dem richtigen Gesprächspartner, der in
der From:-Zeile steht, abgeschickt wurde.
Um die E-Mails durch Verschlüsselung und Signatur vertrauenswürdig zu machen, wurde PGP6 entwickelt, eine Später wurden OpenPGP und GnuPG entwickelt, die frei erhältlich sind. Diese beiden
Softwarepakete ermöglichen es dem Benutzer, seine E-Mails zu verschlüsseln und zu signieren.
4.1 Verschlüsselung
OpenPGP und GnuPG basieren auf dem [10]Prinzip der Public Key Kryptosysteme, der klassischen
symmetrischen Kryptosysteme sowie Einweg-Hashing.
4.1.1 Symmetrische Verschlüsselung
Der Sinn der symmetrischen Verschlüsselung [7] besteht darin, dass sich der Sender und der Empfänger
vor dem Informationsaustausch auf einen Schlüssel einigen, der zum Ver- und Entschlüsseln gebraucht wird. Solange dieser Schlüssel nur den beiden bekannt ist, ist diese Kommunikation sicher.
6
Pretty Good Privacy
13
Schluessel
verschluesseln
Sender
entschluesseln
Krypto−
text
Krypto−
text
Empfaenger
Angreifer
Abbildung 2: Symmetrische Verschlüsselung
Es ist also für einen Angreifer nahezu unmöglich, aus dem Kryptotext auf den ursprünglichen Text zu
schließen (Abb.2). Da die gesamte Sicherheit dieses Verfahrens auf der Geheimhaltung des Schlüssels
basiert, muss besonderer Wert darauf gelegt werden, dass dieser Schlüssel nicht zu erraten ist. Das
bedeutet insbesondere, dass eine große Anzahl von Schlüsseln existieren muß (key space). Aktuelle
Rechner haben solch große Rechenleistung, dass sie innerhalb einer kurzen Zeit große Key Spaces
überprüfen können, deshalb ist es besonders wichtig, sehr lange Schlüssel zu verwenden. Die DES7
Verschlüsselung [14] verwendet zum Beispiel Schlüssel der Länge 256 , die aber für einen normalen
Desktop PC kein wirkliches Problem darstellt. Spezialisierte Rechner brauchen für die Prüfung des
Key Spaces ca. 2-3 Stunden. Die modernen Algorithmen, so wie z.B. blowfish [15], setzen Schlüssel
der Länge 2128 ein. Dieser Key Space ist derart groß, dass es nicht möglich ist ihn in einer annehmbaren Zeit zu überprüfen. Sogar dann nicht, wenn dazu die komplette Rechneleistung der Welt benutzt
wird. Die Zeit, die dafür nötig ist, übersteigt das Alter unseres Universums.
Eins der einfachsten Beispiele für die symmetrische Verschlüsselung ist CAESAR. Dieser Algorithmus wird nachfolgend vorgestellt:
7
Data Encryption Standard
14
#define ALPHABET_LAENGE 26
int i=0;
int c=0;
lese String und k ein;
initialisiere Alphabet mit Buchstaben a-z;
for(i=0; i < strlen(String); i++){
while (String[i] != Alphabet[c])
c++;
String[i] = Alphabet[(c+k) mod ALPHABET_LAENGE];
}
return String;
Nun übergeben wir diesem Algorithmus z.B. den String:
DASISTDERKLARTEXT
und unseren Schlüssel k = 1337. Als erster Buchstabe des Kryptotextes ergibt sich ein O. D ist der
4.te Buchstabe im Alphabet ⇒ 4 + 1337 mod 26 = 15, 15.ter Buchstabe ist O. Der vollständige
Kryptotext lautet also
OLDTDEOPCVWLCEPIE
Der Entschlüsselungsvorgang läuft umgekehrt ab. Zur Entschlüsselung muss lediglich der Schlüssel
k bekannt sein.
4.1.2 Public Key Verfahren
Ein großes Problem bei symmetrischen Verschlüsselungsverfahren ist der Schlüsselaustausch. Deshalb ist es für einen Angreifer viel effizienter, den Schlüssel beim Austausch abzufangen, als jedes
Element des Key Space auszuprobieren. Problematisch ist weiterhin, dass für jede Sender-Empfänger n
Paarung ein Schlüssel ausgetauscht werden muss: Für n Personen benötigt man also
Schlüssel.
2
Dies führt schon bei recht wenigen Teinehmern zu einer großen Anzahl von erforderlichen Schlüsseln.
Um diese Problematik zu umgehen greift man auf die sogenannte Public Key Verfahren zurück. Hierbei wirde sogenannte Einweg-Funktion f eingesetzt, die folgende Eigenschaften erfüllt:
- f ist effizient berechenbar
- f −1 ist nicht effizient berechenbar
- f −1 ist effizient berechenbar, mit geheimer Information
15
Gibt nun der Empfänger seinen öffentlichen Schlüssel, der mit Einweg-Funktion f berechnet wurde, an den Sender, so kann dieser seine Nachrichten für diesen Empfänger verschlüsselt abschicken.
Durch die zweite Eigenschaft der Einweg-Funktion ist garantiert, dass niemand außer dem Empfänger
f −1 effizient berechnen kann. Somit stellt es keine Gefahr dar, öffentlichen Schlüssel zu veröffentlichen.
Die Lösung des zweiten Problems ist einfach, da jeder, der mit dem Empfänger kommunizieren
möchte, zum Verschlüsseln den Public Key des Empfängers verwendet, so braucht man bei n Benutzern n Schlüssel.
Wie bei der symmetrischen Verschlüsselung beruht die Sicherheit des Public Key Verfahrens auf
dem Schlüssel. Es wird empfohlen, Schlüssel der Länge 2048 Bit zu benutzen, um den Key Space
möglichst groß zu halten.
Dieses Verfahren soll nun anhand eines Beispiels erläutert werden:
Man sucht für jeden Buchstaben des Klartextes einen Namen aus dem Telefonbuch, der mit diesem Buchstaben anfängt, und setzt für diesen Buchstaben die Telefonnummer ein, die mit Nullen
aufgefüllt wird, falls die Länge kleiner als 10 ist. Das Ganze wird für den kompletten Klartext durchgeführt. Am Ende hat man einen Kryptotext der aus Telefonnummern der Länge 10 besteht. Da die
gesamten Telefonbücher nach Namen und nicht nach Telefonnummern sortiert sind, und nur der
Empfänger ein Telefonbuch hat, was nach Telefonnummern sortiert ist, so ist er der Einzige, der
den Kryptotext effizient entschlüsseln kann.
4.1.3 Hybride Verschlüsselung
OpenPGP und GnuPG benutzen hybride Verschlüsselungsverfahren, die eine Mischung der oben aufgeführten Verfahren darstellen. Es wird pro Verschlüsselung ein einzigartiger, zufallsgenerierter Sitzungsschlüssel benutzt, der mit dem Public Key des Empfängers verschlüsselt wird und mit welchem
die Nachricht symmetrisch kodiert wird. Beides wird in eine Nachricht zusammengefasst und abgeschickt. Mit dem Private Key des Empfängers kann nun der Sitzungschlüssel entschlüsselt und die
eigentliche Nachricht dann endgültig dekodiert werden. Abb. 3.
Die Vorteile bestehen darin, dass:
- die Anzahl der Schlüssel n beträgt
- keine gleichen Schlüssel zum Kodieren - Dekodieren benutzt werden
- und potentielle Angreifer jedes mal den Sitzungsschlüssel dekodieren müssten, um an die Informationen heran zu kommen.
Eine nach diesem Verfahren verschlüsselte Nachricht sieht folgendermaßen aus:
16
KRYPTOTEXT
Public−Key
(Empfaenger)
3.
Sitzungs−
schluessel
/dev/random
2.
KLARTEXT
1.
1. Sitzungschluessel randomisiert erstellen
2. KLARTEXT mit dem erstellten Key verschluesseln
3. Sitzungsschluessel mit dem Public−Key verschluesseln
Abbildung 3: Hybride Verschlüsselung
$ echo Hallo Welt | gpg -e -a -r 2A8037EA
-----BEGIN PGP MESSAGE----Version: GnuPG v1.0.7 (GNU/Linux)
hQQOA6beKBbn7I6ZEBAAwlzZoB/pnfZVboJCsruj94l19Mygmn+XiV/AcJylB40s
zp+klV81pABtzAbjsEyrd+g7MreRP8C+43qt1WwlxF1Cf2ODUflFn5H5+jLFqEyP
1KoPhqyMALHuDDK/Qg9YnHOjHtAxkPKTPf+T72QJ54eEsCoBtxPzzT7MgSTs4CbR
DECc8xMxndy+3HQ8Eoi1fBYjbWO/Y6wlQtpZB8fUXMM3VfYPBrq1Sgy8F0018HB8
TWb1DzE/qSzoWihdlOkhqPs5wuORvsMDBzgHhXfFZFmafUMkfwPXCnWV8G8e3Jx6
eutnOiM+iReymdny+lFBla8czE1go0hxTWk+wmbOX5GFeLTnXG5kRKK9PD0aydhK
fEzoIO9jhz4hFfGbXJzfjo7NYvLZlBwXgwsxI34lh/lIRQ97wzwAAiN5JF8SuswZ
fXE/zZoG89i+mFoNmy5OkCoOh7LZyBe+QKnvJzHfrLxk8nkkeCDn9Znlyb3PhSaJ
GFfiUCuj7btiNaT/y31xGcZr+i94Inj2h3PVVTiikF9B73UQKVvSzD1gVCXXlxsl
cScxTf+jgEKCi8ygSLw4X6pS85VVU6jeKLPoJdB6M8gdHFZuNJQg4otVNwzc5pLz
0g04/3/k6Nbv1dpBdU9kJYtnmFJsCvUI5JXN6meUyjH7qSNQTu+Bk0seOkjq//UP
/ieQlrnuPZvMkVZULlLvy9BScdWK+Rzlvt/K0A6Q0vWimQpXWWc/lv5eODbEjhK6
x3azapdlvpNP+/hquLEAEYU/PyivvPHLjovxukKSiIicnop7mkMIjCtCNYNZXOK3
Y3HrEywYDiuQ7qGOaWaujIDOY+lz1G0E8I3uum4l5iC9RyGTZcnjBlS1huBWR4oU
joTNwlwq7hAECzqwvf9xNCoh7CDETdvLuQL7P1QJKVctbUj5Ztg9MJba3xP/pRw3
RP8Oz4TB0tWoZlbTbIPA86houHn25yOy6jPku8Szl0XNRJZ04hvHSvC780qxR1ZK
ggNJ4WfbGL0BYNLrVHxs59I+nLGprQz3oHcITlDNMogQIfDNW4vAqutKxwUJ2rbJ
4ltDGP/7r/AxsVv1gQQ+TXoH0N+meFXU2M+h5hMhxx2tUalSjOpf+HpocpAiHIOP
csl9FX09JxL0JlS0MWJ89w93JLWa7htclJW66scKj/62wDT+in8AKdToi4kascc0
2wmrWb6VkDWThJo+h+Sc5dA9PijNKAVv9S76NK2SDXChW4FKH9J39Ic3KTnc47l7
7XxENLuiQl6p0JRUyXmxu1EemFFn0ECXIifeJv39m0n/GAINgeMxyYm+0TbzI5aN
guPZzcKxckQCB2Pqkw4pcSMM"oLhZ+tmZP/ssp9V9T7IySEXygM9FOXrSQemK1gj
n/YhUnwDd+POBrvvssP0PDSRw30=
=l+ds
-----END PGP MESSAGE-----
17
Auf Anhieb ist es nicht leicht, einen Zusammenhang zu dem ursprünglichen Text herzustellen, deswegen ist es nicht trivial zu entschlüsseln.
4.2 Digitale Signatur
Jeder Mensch hinterlässt Fingerabdrücke, die jeweils einmalig sind. So kann z.B. das Bundeskriminalamt prüfen, ob Verbrecher 1 oder Verbrecher 2 die Bank ausgeraubt hat. Problematisch wird es z.B.
bei Dateien, die keine Fingerabdrücke hinterlassen. Wie kann man also prüfen, ob eine Datei genau
die ist, die man erwartet? Man kann den Inhalt einer Datei mit Hilfe einer Hash-Funktion injektiv auf
eine kürzere eindeutige Datensequenz abbildeni, d.h., sobald der Inhalt einer Datei modifiziert wird,
ändert sich das Ergebnis der Hash-Funktion für diese Datei. Dies bezeichnet man in der Computerwelt als Fingerprinting. Dazu wurden auch einige Algorithmen entwickelt, wie z.B. US Secure Hash
Algorithm 1 (SHA1) [11] oder Message Digest Algorithm 5 (MD5) [12]. Die digitale Unterschrift ist
nichts anderes als das Fingerprinting der zu versendenden Nachricht. Mit einer Einschränkung, dass
die Hash-Funktion die beide folgenden Eigenschaften erfüllen muss:
• es ist unwahrscheinlich, zwei Dokumente mit gleichem Hash-Wert zu finden
• bei einem gegebenen Hash-Wert soll es möglichst schwer sein, das Dokument zu bestimmen.
Das eigentliche Signieren läuft dann wie folgt ab: Der Inhalt wird auf einen Hash-Wert abgebildet,
der nach dem Public Key Verfahren mit dem Private Key des Senders verschlüsselt wird. Danach kann
jeder mit dem Public Key des Senders diese Unterschrift überprüfen. Das bedeutet also: Auch wenn
der Sender die Nachricht mit seiner Unterschrift signiert hat, die Nachricht danach bearbeitet und
dann erst abschickt, wird die Überprüfung der Unterschrift eine Nichtübereinstimmung bemerken.
Auf diese Weise funktioniert der Digital Signature Algorithm (DSA) [13] der bei GnuPG/OpenPGP
zum Signieren eingesetzt wird.
4.3 TLS/SSL
Das Transport-Layer-Security-Protokoll (TLS) sowie sein Vorgänger Secure Socket Layer (SSL) wurden von Netscape mit der Funktion entwickelt, die Kommunikation zwischen Server und Client zu
sichern. Die meisten Protokolle übertragen die Daten im Klartext. Dadurch sind sie (Abb. 4) natürlich
leicht abzuhören oder zu manipulieren.
TLS fügt zwischen TCP und Anwendung eine weitere Protokollschicht ein, die von der Anwendung
transparent verwendet werden kann. Diese Schicht sorgt für folgendes:
- Verschlüsselung der Daten
- Authentifizierung des Servers (einseitig) oder von Server und Client (beidseitig)
18
USER test
+OK
Client
PASS 6;x2,Ru%}
POP3
Server
+OK
Abbildung 4: POP3 Plain Text Kommunikation
TLS Handshake Application
Protokoll
− IMAP
− Handshake
− POP3
− Alert
− HTTP
− Change
Cipher Spec − SMTP
TLS Record Protocol
TCP
IP
Abbildung 5: TLS Schicht
- Sicherstellen der Integrität der Daten
Diese TLS Schicht besteht aus mehreren Teilprotokollen (Abb. 5). Als Basis dient das TLS Record
Protocol, welches für die Zerteilung der Daten in handliche Pakete (Fragmentierung) zuständig ist,
sowie für die Verschlüsselung und Sicherstellung der Integrität der Daten. Optional kann auch eine
Kompression der Daten vorgenommen werden. Da die verschlüsselten Daten nicht mehr komprimierbar (Aufgrund der hohen Entropie dieser Daten) sind, muss die Komprimierung vor der Verschlüsselung durchgeführt werden.
Nach dem TLS Record Protocol folgen zwei weitere Protokolle, das TLS Handshake Protocol und
das Applikations-Protokoll. Das TLS Handshake Protocol besteht wiederum aus drei Teilprotokollen:
- Handshake Protocol - Bestimmung der Sicherheitsparameter
- Alert Protocol - Weitergabe der Fehlermeldungen innerhalb der TLS Schicht
- Change Cipher Protocol - Umschaltung auf die neuen Sicherheitsparameter
19
4.3.1 Aufbau der Verbindung bei TLS
Zunächst wissen Client und Server nichts voneinander, daher ist die verschlüsselte Kommunikation
erst nach der Handshake-Phase möglich. Erst mit den ,,ChangeCipherSpec”-Paketen wird auf eine
verschlüsselte Verbindung umgeschaltet.
Zu den Aufgaben des Handshake-Protocols gehört die Authentifikation. Dazu werden X.509-Zertifikate
eingesetzt, die von diesem Protokoll mit übertragen werden. Es legt auch fest, welche Verschlüsselungsalgorithmen verwendet werden und aus welchen Zufallswerten der Sitzungsschlüssel berechnet
wird.
Zertifikate kann man sich als eine Verknüpfung des Public Key mit dem Namen des Besitzers vorstellen, die von einem vertrauenswürdigen Dritten bestätigt wurde. Bei X.509 ist dieser dritte eine
Certification Authority (CA). Ein Zertifikat kann auch weitere Informationen beinhalten, z.B. Gültigkeitszeitraum, DNS-Name des Rechners etc.
Bei der Authentifizierung des Servers prüft der Client folgende Punkte:
- Gültigkeit des Zertifikats
- Vertrauenswürdigkeit der CA (Vergleich mit eigener Liste)
- Gültigkeit der Signatur des Zertifikats (Prüfung mit dem Public Key der CA)
- Übereinstimmung des angegebenen Rechners mit dem antwortenden Rechner.
- Fähigkeit des Servers sich mit seinem Private Key zu authentifizieren
Bevor ein Paket über die Leitung geht, müssen sich Server und Client einig sein, ob TLS eingesetzt
wird. Diese Problematik ist einfach lösbar, indem man bestimmte Ports für Dienste nimmt, die TLS
einsetzen. Beispiele dafür sind HTTP - Port 80 und HTTPS - Port 443, POP3 - Port 110 und POP3S
- Port 995 und IMAP - Port 143 und IMAPS - Port 993.
4.3.2 STARTTLS
TLS lässt sich auch ohne zusätzlichen Port einbinden. Um zu normalen Clients kompatibel zu bleiben,
startet SMTP zunächst mit einer normalen Verbindung über TCP. Wenn ein ESMTP-Server TLS
unterstützt, teilt er dies dem Client in seiner EHLO Antwort [9] mit. Das Schlüsselwort ist STARTTLS.
Unterstützt der Client TLS, schickt er dem Server den Befehl STARTTLS und beide schalten auf TLS
Betrieb um. Dieses Umschalten ist keineswegs trivial, da beide Seiten während der Verbindung eine
weitere Protokollschicht einbinden müssen, während SMTP weiter abläuft.
STARTTLS ist auch für andere Protokolle wie IMAP oder POP3 definiert. Hier zeigen sich die Vorteile von TLS: Es sichert die Datenübertragung vom Server bis zum Client und authentifiziert Server
und Client. Nach der Zustellung liegen E-Mails jedoch in unverschlüsselter Form vor, so dass TLS
keinesfalls eine Alternative zu OpenPGP/GnuPG darstellt.
20
4.3.3 Grenzen von STARTTLS im SMTP
Bei SMTP ergeben sich einige Probleme, die mit der Architektur des E-Mail-Systems zusammenhängen.
Bei SMTP gibt es keine Ende-zu-Ende Verbindung zwischen Sender und Empfänger einer E-Mail.
Die Nachrichten werden stattdessen in einem oder mehreren MTAs zwischengespeichert. Die einzelnen Abschnitte kann TLS zwar absichern, ein MUA oder MTA kann aber nicht wissen, ob nachfolgende Abschnitte auch durch TLS abgesichert werden können.
Die Authentifizierung ist bei SMTP nur bedingt sinnvoll: Ein Client kann zwar prüfen, ob der Server
authentisch ist, die Information, welchen Server er überhaupt ansprechen soll, stammt aber aus dem
(unsicheren) DNS und nicht vom Benutzer. Ein manipulierter MX Record kann eine E-Mail umleiten und ein falscher Server kann sich mit eigenem Zertifikat ausweisen - er wurde ja unter seinem
richtigen Namen angesprochen, er ist nur nicht zuständig.
Dieses Problem ließe sich nur umgehen, indem für Empfänger, die E-Mails über verschlüsseltes
SMTP erhalten sollen, der MX Lookup vermieden und die Zustellung fest konfiguriert wird.
Es ergibt sich ein weiteres Problem. Bevor Client und Server auf TLS umschalten, unterhalten sie
sich über TCP, was von einem Angreifer wiederum leicht zu manipulieren ist. Er kann z.B. aus der
Antwort des MTAs das STARTTLS Schlüsselwort entfernen. Der Client kann nicht erkennen, dass
der Server TLS unterstützt, und die Verbindung wird nicht durch TLS abgesichert.
In einer kontrollierten Umgebung kann STARTTLS einen hohen Schutz bieten, wenn alle beteiligten
MTAs auf MX Lookups verzichten und E-Mails nur dann weiterleiten, wenn eine TLS abgesicherte
Verbindung aufgebaut wurde. Ohne diese Maßnahmen bietet STARTTLS zumindest einen Schutz vor
passiven Angreifern, die das Netz belauschen aber keine Pakete manipulieren.
21
5
Zusammenfassung
Wie man sieht, ist das E-Mail-System recht einfach organisiert, und basierend auf den Standards leicht
zu implementieren. Es sind aber auch, wie wir gesehen haben, viele Schwächen in diesem System,
die teilweise in Erweiterungen der Standards behoben sind.
Es wurden die Grundlagen des E-Mail-Systems vorgestellt, die in diesem System benutzte Protokolle,
der Aufbau einer E-Mail mit und ohne Attachment und auch die Grundlagen der Verschlüsselung der
Daten sowie der sicheren Kommunikation zwischen dem Absender und Empfänger.
Ebenso wurde auf die Schwächen der Protokolle, sowie deren Vorteile und Nachteile eingegangen, so
dass man einen umfassenden Einblick in das Thema erhalten hat.
In the beginning was the word. And the word was ”Content-Type: text/plain”.
22
Literatur
[1] RFC0821, RFC2821 - Simple Mail Transfer Protocol
[2] RFC0822 - Standard for the format of arpa text messages
[3] RFC1939 - Post Office Protocol - Version 3
[4] RFC2045 - RFC2049 - Multipurpose Internet Mail Extension (MIME)
[5] RFC2060 - Internet Message Access Protocol - Version 4rev1
[6] Zwicky, Cooper und Chapman - Einrichten von Internet Firewalls, O’Reilly 2001
[7] Juraj Hromkovic - Algorithmische Konzepte der Informatik, Teubner 2001
[8] RFC2246 - The TLS Protocol - Version 1.0
[9] RFC2487 - SMTP Service Extension for Secure SMTP over TLS
[10] http://www.gnupg.org/(en)/documentation/faqs.html
[11] RFC3174 - US Secure Hash Algorithm (SHA1)
[12] RFC1321 - The MD5 Message Digest Algorithm
[13] RFC2536, RFC2537 - DSA/RSA Algorithmen
[14] http://www.tropsoft.com/strongenc/des.htm
[15] http://www.counterpane.com/bfsverlag.html
23