Eidesstattliche Erkl¨ arung

Ich versichere, dass ich die vorliegende Arbeit selbstst¨ andig und ohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe. Alle Stellen, die w¨ ortlich oder sinngem¨ aß aus ver¨ offentlichten und nicht ver¨ offentlichten Schriften entnommen wurden, sind als solche kenntlich gemacht. Die Arbeit hat in dieser oder ¨ ahnlicher Form keiner anderen Pr¨ ufungsbeh¨ orde vorgelegen.

Mannheim, den 9. November 2005

Robert Reiz

i

Danksagung

Dank geb¨ uhrt Prof. Dipl.-Infrom. G¨ unther Bengel f¨ ur seine Unterst¨ utzung und Betreuung im Rahmen dieser Diplomarbeit. Vielen Dank auch an Dipl.-Inform. Christian Baun, der mir bei Problemen mit L ^A T E X[Kop05] immer mit Rat und Tat zur Seite stand.

Desweiteren m¨ ochte ich mich hier auch bei meiner Schwester Johanna Maria Reiz bedanken, die mir gelegentlich bei der Formulierung meiner S¨ atze beistand. Großer Dank geb¨ uhrt auch meinen Eltern Maria Reiz und Julius Reiz, die mir mein Studium erst erm¨ oglicht haben und mich in dunklen Stunden meines Studiums immer ermutigten weiter zu machen.

ii

Vorkenntnisstand

Ich setze voraus, dass der Leser dieses Dokumentes ¨ uber die Grundkenntnisse der

Informatik und Kenntnisse in der Java-Programmierung verf¨ ugt. Das Verst¨ andnis f¨ ur die UML[Kec05] 2.0 Notation sollte dem Leser ebenfalls nicht ganz fremd sein.

iii

Verwendete Werkzeuge

Diese Diplomarbeit entstand auf einem 12 Zoll PowerBook G4 unter dem Betriebssystem MacOS X Tiger von Apple[4]. F¨ ur die Textsetzung habe ich L ^A T E X[Kop05] in Verbindung mit BibTeX[5], f¨ ur das Literaturverzeichnis, benutzt. Um aus dem L ^A T E X-Code eine PDF zu erzeugen benutzte ich das Programm Pdflatex[43] in der Version 3.1. Zur Editierung der L ^A T E X-Dateien benutzte ich den UNIX-Editor E-macs[21] in der Version 2.1.

F¨ ur das Erstellen der technischen Zeichnungen, wie z.B. Klassendiagramm, Zu-standsdiagramm etc., kam das Programm Dia[18] in der Version 0.94 zum Einsatz.

Den Webbrowser Firefox[37] in der Version 1.0.4 benutzte ich f¨ ur meine Recherchen im Internet.

Zur Erstellung des JMTA-Projekts kamen die Entwicklungsumgebung Eclipse[20] 3.1, Apache Ant[3] 1.6.2 und die Programmiersprache Java[30] 1.4.2-54 von der Firma SUN[53] zum Einsatz.

iv

Inhaltsverzeichnis

Eidesstattliche  Erkl arung  i

Danksagung   ii

Vorkenntnisstand   iii

Verwendete  Werkzeuge  iv

1  Ziele der Diplomarbeit  1

2  Einf uhrung  3

2.1  E-Mail-Komponenten  3

2.2  MIME  4

3  Protokolle  7

3.1  E-Mail Protokolle  7

3.1.1  SMTP  7

3.1.2  LMTP  11

3.1.3  POP3  12

3.1.4  IMAP  15

3.2  Sicherheits-Protokolle  16

3.2.1  SSL/TLS  18

3.2.2  Plain-Authentifikation  24

3.2.3  Login-Authentifikation  25

3.2.4  Cram-MD5  26

3.2.5  PGP  26

4  Message-Store  33

4.1  Mbox  34

4.2  Mh  36

4.3  Maildir  36

4.4  Mailboxvergleich  37

v

Inhaltsverzeichnis

5  Mail-User-Agent  39

5.1  Thunderbird  39

5.2  Mutt  41

5.3  Die Mutt-Kette  42

6  Mail-Delivery-Agent  44

6.1  Procmail  44

7  Mail-Travel-Agent  46

7.1  Geschichtlicher  

Uberblick  der MTAs  46

7.2  Sendmail  49

7.2.1  Sendmail Inc.  50

7.2.2  Dokumentation  50

7.2.3  Konfiguration  50

7.2.4  Vorteile  53

7.2.5  Nachteile  54

7.3  Postfix  54

7.3.1  Ziele von Postfix  55

7.3.2  Dokumentation  55

7.3.3  Architektur  56

7.3.4  Konfiguration  57

7.3.5  Vorteile  59

7.3.6  Nachteile  60

7.4  Exim  60

7.4.1  Dokumentation  60

7.4.2  Konfiguration  61

7.4.3  Exim-Utilities  63

7.4.4  Vorteile  64

7.4.5  Nachteile  64

7.5  Qmail  65

7.5.1  Dokumentation  65

7.5.2  Konfiguration  65

7.5.3  Vorteile  66

7.5.4  Nachteile  66

7.6  Zmailer  67

7.6.1  Dokumentation  67

7.6.2  Konfiguration  67

7.6.3  Vorteile  68

vi

Inhaltsverzeichnis

7.6.4  Nachteile  69

7.7  Masqmail  69

7.7.1  Dokumentation  69

7.7.2  Konfiguration  69

7.7.3  Vorteile  70

7.7.4  Nachteile  70

7.8  Comunigate Pro  71

7.8.1  Dokumentation  71

7.8.2  Konfiguration  72

7.8.3  Vorteile  72

7.8.4  Nachteile  73

7.9  Vergleichsmatrizen  73

8  Java-Mail-Travel-Agent  76

8.1  Programmaufbau  77

8.2  Installation  82

8.3  Konfiguration  83

8.4  Bedienung  87

8.5  Anwendungsbeispiele  92

8.5.1  Mutt mit JMTA  92

8.5.2  Perl-Scripte mit JMTA  93

8.6  Probleme und Nachteile  96

8.7  Ausblick in die Zukunft  97

9  Anhang  98

vii

Tabellenverzeichnis

3.1 POP3 Befehle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.2 Client Hello Message . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.3 Server Hello Message . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.1 Mailboxvergleich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 4.2 Unterst¨ utzte Postfachsysteme in E-Mailprogrammen . . . . . . . . . . 38

7.1 Postfix-Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 7.2 Exim Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 7.3 MTAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 7.4 MTA Lizenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 7.5 MTA Konfigurierbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . 74 7.6 MTA Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 7.7 MTA Relaying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

8.1 JMTA Felder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 8.2 JMTA Aufrufe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

viii

Abbildungsverzeichnis

2.1 E-Mail-Komponenten, Weg einer E-Mail . . . . . . . . . . . . . . . . 3 2.2 Aufbau einer E-Mail . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.1 E-Mail-Versand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2 SSL/TLS Sicherheitsschicht . . . . . . . . . . . . . . . . . . . . . . . 20 3.3 SSL/TLS Schichtenmodell . . . . . . . . . . . . . . . . . . . . . . . . 21 3.4 SSL/TLS Handshake . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.5 Digitale Signatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.6 PGP mit mehreren Empf¨ angern . . . . . . . . . . . . . . . . . . . . . 30

4.1 Mailbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.1 Thunderbird . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 5.2 Mutt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

7.1 MTA Timeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 7.2 E-Mailprogramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 7.3 Postfix Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 7.4 Admin-GUI von Communigate Pro . . . . . . . . . . . . . . . . . . . 72

8.1 Klassendiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 8.2 Zustandsdiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 8.3 Install-Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 8.4 JMTA config . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 8.5 JMTA receive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 8.6 JMTA receive im Debugmode . . . . . . . . . . . . . . . . . . . . . . 89 8.7 JMTA send . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 8.8 JMTA send mit Anhang . . . . . . . . . . . . . . . . . . . . . . . . . 91 8.9 index.html . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 8.10 Antwort auf index.hmtl . . . . . . . . . . . . . . . . . . . . . . . . . . 96

ix

Listings

2.1 Aufbau einer E-Mail . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1 SMTP via Telnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2 ESMTP via Telnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3 LMTP via Telnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.4 POP3 via Telnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.5 Login-Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.1 Mbox-Datei . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 6.1 Procmail-Regeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 6.2 Procmail-Regeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 7.1 linux.mc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 7.2 /etc/sendmail.cf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 7.3 aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 7.4 Cram-MD5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 7.5 smtp-policy.src . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 7.6 masqmail.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 8.1 jmtaSettings.xml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 8.2 index.html . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 8.3 message.pl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 9.1 Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 9.2 Xml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 9.3 Crypt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 9.4 Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 9.5 Sender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 9.6 Receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 9.7 Gui . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 9.8 PasswordField . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 9.9 EraserThread . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 9.10 jmta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 9.11 install . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

x

1 Ziele der Diplomarbeit

Diese Diplomarbeit bietet einen ¨ Uberblick und Vergleich von vorhanden Mail-Travel-Agents (MTAs) auf Linux-Systemen. Das Hauptaugenmerk liegt dabei auf den neuen, kleinen und leichten Mail-Travel-Agents deren Entwicklung von der Open-Source-Gemeinde angetrieben wird. Das Ziel dieser Diplomarbeit ist es einen MTA mit den folgenden Eigenschaften heraus zu kristallisieren.

• Open-Source-Software die unter der GNU (GNU ist Not Unix) General Public License steht.

• Der MTA soll leicht zu konfigurieren sein.

• Optional soll es auch m¨ oglich sein die Konfiguration ¨ uber eine grafischer Benutzeroberfl¨ ache abzuwickeln.

• Der MTA soll die heutigen Sicherheitsstandards gew¨ ahrleisten. Das bedeutet: Die Passw¨ orter die unverschl¨ usselt auf der Festplatte abgelegt oder ¨ uber das

Netz geschickt werden sind nicht akzeptabel.

• Konfigurationsdateien die keine systemweite G¨ ultigkeit besitzen, sollen im Homeverzeichnis des entsprechenden Users liegen.

• Eine Weiterleitung (Relaying) zu einem renommierten E-Mailanbieter, z.B. gmx.de, soll schnell und einfach m¨ oglich sein.

Abschnitt 2 gibt eine Einf¨ uhrung in die Thematik, sowie einen ¨ Uberblick ¨ uber die

E-Mail-Kommunikation. Die einzelnen Bausteine der heutigen E-Mail-Kommunikation sind hier vorgestellt und kurz erl¨ autert.

Abschnitt 3 erl¨ autert alle f¨ ur die E-Mailkommunikation relevanten Protokolle. Dazu geh¨ oren mit SSL/TLS, Plain, Login, Cram-MD5 und PGP die Sicherheitsprotokolle, genauso wie die E-Mail-Protokolle POP3, SMTP, LMTP und IMAP.

Abschnitt 4, 5 und 6 erkl¨ aren ausf¨ uhrlich die Begriffe Message-Store, Mail-User-Agent und Mail-Delivery-Agent. Außerdem stellen sie zu den abstrakten Begriffen

1

1 Ziele der Diplomarbeit

Beispielprogramme vor, damit der Leser sich ein besseres Bild von diesen Systemen machen kann.

Abschnitt 7 stellt die g¨ angigsten MTAs vor, mit ihren Vor- und Nachteilen und vergleicht diese miteinander durch Vergleichsmatrizen.

Abschnitt 8 stellt den, im Rahmen dieser Diplomarbeit entwickelten, Java-Mail-Travel-Agent vor, der alle Ziele der Diplomarbeit erf¨ ullt.

2

2 Einf¨ uhrung

2.1 E-Mail-Komponenten

Die heutigen E-Mailkomponenten sind in drei Kategorien aufgeteilt, Sender, Server und Empf¨ anger. Auf der Senderseite steht der User, eine Person, die eine Nachricht erstellt, und sie verschickt, nennen wir ihn Mike. Er erstellt mit einem Mail-User-Agent (MUA), mit dem man Nachrichten lesen und schreiben kann, eine Nachricht bzw. E-Mail. Beispiele f¨ ur solche Programme sind Thunderbird von der Open Source Community auf www.mozilla.org[37], Mutt von der Open Source Community auf www.mutt.org[38] und Outlook von der Firma Microsoft auf www.microsoft.com[36]. Nachdem die Nachricht erstellt ist, wird diese an den Mail-Travel-Agent (MTA) des Rechners ¨ ubergeben. Abbildung 2.1 zeigt den Weg, den eine E-Mail vom Sender bis zum Empf¨ anger zur¨ ucklegt. Die Nummern eins bis acht zeigen die Reihenfolge der Stationen welche die E-Mail bis zum Empf¨ anger passiert.

Der MTA ist eine Softwarekomponente die f¨ ur das Versenden und Empfangen der E-Mails via SMTP-Protokoll (RFC ¹ 2821) zust¨ andig ist. Die E-Mail-Protokolle, zu denen auch SMTP geh¨ ort, sind in Abschnitt 3.1 auf Seite 7 ausf¨ uhrlich beschrieben. Der MTA schickt die E-Mail an den E-Mailserver des Benutzers Mike, z.B. gmx.net.

¹ Request for Comments oder RFCs sind eine Reihe von Dokumenten die den technischen und organi-

satorischen Aufbau des Internets beschreiben.

3

2 Einf¨ uhrung

Als solche MTAs sind sowohl die Softwarepakete Sendmail, Postfix als auch Exim zu nennen, die in Abschnitt 7 auf Seite 46 genauer beschrieben sind. Auf der Serverseite steht ebenfalls ein MTA, der f¨ ur eingehende Nachrichten zust¨ andig ist, eine Authentifikation durchf¨ uhrt und die Empf¨ angeradresse analysiert. In Abh¨ angigkeit von der Analyse der Empf¨ angeradresse entscheidet der MTA auf dem Server, ob er die E-Mail intern weiterverarbeitet, sie an einen anderen Server weiterleitet, oder diese an den Absender zur¨ uck zu schicken ist, weil die Empf¨ angeradresse ung¨ ultig ist.

Hier ist ein simpler Fall beschrieben, in dem der Server die E-Mail intern weiterverarbeitet. Der MTA leitet die E-Mail weiter an den Mail-Delivery-Agent (MDA). Ein Mail-Delivery-Agent durchsucht E-Mails nach bestimmten Mustern und kate-gorisiert diese. MDAs sind in Abschnitt 6 auf Seite 44 ausf¨ uhrlich behandelt. Je nachdem welche Muster zutreffen, wird die Nachricht vom MDA entweder im Posteingang, Spamverdachtordner, oder in einem anderen Ordner im Message-Store (MS) abgelegt. Der Message-Store ist der Ablageort der E-Mails und in Abschnitt 4 auf Seite 33 genau beschrieben. E-Mails bleiben im MS solange liegen, bis der Empf¨ anger sie abholt.

Der Empf¨ anger, z.B. der User Bob, der die Nachricht von Mike erh¨ alt, beauftragt seinen MUA E-Mails vom Server abzuholen. Dieser leitet den Auftrag weiter an den MTA, der per POP/IMAP-Protokoll (RFC 1939/RFC 3501) eine Verbindung zum POP/IMAP-Server aufbaut. Welcher, nach der erfolgreichen Authentifizierung des Empf¨ angers, alle Nachrichten, die dem Empf¨ anger geh¨ oren, aus dem Message-Store holt und dem MTA zur Verf¨ ugung stellt. Der Mail-Travel-Agent schreibt alle runtergeladenen Nachrichten in den MS des Empf¨ angers. Der Mail-User-Agent greift lesend auf den Message-Store zu und stellt sie dem Empf¨ anger Bob zur Verf¨ ugung. Die Protokolle POP und IMAP geh¨ oren zu den E-Mailprotokollen und sind in Abschnitt 3.1.3(POP) auf Seite 12 und in Abschnitt 3.1.4(IMAP) auf Seite 15 erkl¨ art.

2.2 MIME

MIME steht f¨ ur “Multipurpose Internet Mail Extensions” oder auch “Multimedia Internet Message Extensions”. MIME ist ein Kodierstandard, das Struktur und Aufbau von E-Mails und Internetnachrichten beschreibt. Es erm¨ oglicht dem Sender und dem Empf¨ anger Informationen ¨ uber den Typ der zu verschickenden Nachricht (Content-Type), sowie dessen Kodierung bei der ¨ Ubertragung (Content-Transfer-Encoding)

4

2 Einf¨ uhrung

auszutauschen. Bin¨ ardaten werden vor der ¨ Ubertragung immer in Base64 kodiert.

Eine E-Mailnachricht besteht immer aus einem Header, einem Body und und optional aus beliebig vielen Attachments (Anhang).

Der Header enth¨ alt allgemeine Informationen ¨ uber die E-Mail, wie z.B. Absenderadresse, Empf¨ angeradresse und Betreff der Nachricht. Der Body enthalten die Nachricht in Textform. Attachments (Anhang) sind optional und beinhalten angeh¨ angte Dateien. Listing 2.1 zeigt eine typische E-Mail mit einem Header einem Body und einem Anhang.

1 From : absender@example . com

2 To : empfaenger@example . com

3 Subject : Betreff der Nachricht

4 MIME - Version : 1.0

5 Content - type multipart / mixed ; boundary = " ------_ =

6

7 ------_ = _NextPart_11089233564218d3dc5ba8f6 .81706686

8 Content - type : text / plain ; charset = utf -8 9

10 Dies ist eine Beispielnachricht f \ " ur meine

11

12 ------_ = _NextPart_11089233564218d3dc5ba8f6 .81706686

13 Content - type : image / gif ; name = " bild . gif "

14 Content - Transfer - Encoding : base64

5

15

16 R0lGODlhIgFGAOYAAABmmYCruf /// zCIpa / S3QCZzECZtgCNv

17 C Q lN b2 Rl cyA gI CA iO DAw eD Yw MC IgI jY 0M Hg 0O DAi Cg lF bm RTd

18 I C JE aX Nw bGF 5I go JC URl cH Ro IC AgI CA 0C gk JT W9k ZX Mg IC AgI

19 R W 5k U3 Vi U2V jd Gl vb goJ U3 Vi U2 Vjd Gl vb iA iR Glz cG xh eS IKC

20 I C Ag IC I4 MDB 4N jA wI iAi Nj Qw eD Q4M CI KC UV uZ FN1 Yl Nl Y3 Rpb

21 Y X ki Cg kJ RGV wd Gg gI CAg ID E1 Cg kJT W9 kZ XM gI CAg IC Ix Nj gwe

22 ...

23 ------_ = _NextPart_11089233564218d3dc5ba8f6 .81706686 - -

DieZeilen eins bis f¨ unf enthalten den Header der Nachricht, in dem Absenderadresse, Empf¨ angeradresse, Betreff, MIME-Version und Content-Type enthalten sind. Der Content-Type in Zeile 5 hat den Wert “multipart/mixed”, was bedeutet, dass die Nachricht Attachments enth¨ alt, dessen Inhalte unterschiedlich kodiert sind.

Zeile sieben bis Zeile elf enth¨ alt den Bodypart. Zeile acht enth¨ alt den Content-Type dieses Bodyparts, der besagt, dass dessen Inhalt Klartext in UTF-8 Kodierung enth¨ alt.

Die Zeilen zw¨ olf bis 22 zeigen den Anhang, der laut Content-Type ein Bild im gif-Format enth¨ alt mit dem Namen “bild.gif”. Da es sich hierbei um Bin¨ ardaten handelt, ist das Bild in Base64 kodiert.

S/MIME (Secure MIME) ist eine Erweiterung des MIME Standards, mit dem eine Verschl¨ usselung der Nachrichten, sowie eine Signierung dieser m¨ oglich ist. Die Begriffe Verschl¨ usselung und Signierung sind in Abschnitt 3.2 auf Seite 16 erkl¨ art.

PGP/MIME ist ebenfalls eine Erweiterung des Standards mit dem ein sicherer und zu PGP kompatibler Datenaustausch m¨ oglich ist. Der Begriff PGP ist in Abschnitt 3.2.5 auf Seite 26 erkl¨ art.

6

3 Protokolle

Ein Protokoll ist ein im Voraus und nach bestimmten Regeln definierter Ablauf eines Prozesses. Zum Verst¨ andnis dieser Arbeit sind Kenntnisse ¨ uber Sicherheitsprotokolle und E-Mailprotololle von N¨ oten, welche nachfolgend vorgestellt sind.

3.1 E-Mail Protokolle

Die E-Mailprotokolle, die in diesem Abschnitt erkl¨ art sind, legen verschiedene Verfahren fest, die es erlauben E-Mails zu versenden (SMTP/LMTP), zu empfangen (POP/IMAP) und auf dem Server zu verwalten (IMAP).

3.1.1 SMTP

SMTP[Hun04] (Simple Mail Transfer Protocol) wurde 1982 in der RFC 821 definiert. Computernetze waren zu der Zeit noch recht ¨ uberschaubar und jeder Mailserver war

ein offenes Relay. Das bedeutet, dass der Mailserver blind darauf vertraut, dass die Absenderadresse und die Empf¨ angeradresse der E-Mail authentisch sind. Wie auch Sendmail, wurde dieses Protokoll nicht f¨ ur eine feindliche Umgebung geschaffen. Offene Relays und das standard SMTP Protokoll sind ein Segen f¨ ur alle, die Spam-Mails versenden und ein Fluch f¨ ur alle Spam-Mail gesch¨ adigten User.

SMTP ist das Protokoll, welches in Computernetzwerken den Versand von E-Mails regelt. SMTP sendet eine E-Mail vom Client (Sender) an den E-Mail-Server. Der Server sorgt dann daf¨ ur, dass die Nachricht ¨ uber das Internet an den Empf¨ anger zugestellt wird. Siehe Abbildung 3.1.

7

Ist die E-Mail beim E-Mail-Server A angekommen, routet er diese durch das Internet. ¨ Uber die E-Mail-Server B, C und D gelangt die E-Mail schließlich zu E-Mail-Server E, der der E-Mailanbieter des Empf¨ angers ist. Hier wird die Nachricht solange aufbewahrt, bis der Empf¨ anger sie ¨ uber das POP3/IMAP Protokoll abholt.

SMTP setzt voraus, dass der Sender/Client den Verbindungsaufbau zum Server initialisiert. Das Protokoll ist einfach genug gestaltet, dass auch mit Telnet ¹ , per Hand, eine E-Mail verschickt werden kann. Siehe Listing 3.1.

1 > telnet mail . server . net 25

2 < Trying 213.165.64.20...

3 < Connected to mail . server . net .

4 < Escape character is ’ ^{}] ’

5 < 220 { mp030 } Mailserver SMTP

6 > HELO mail . example . org

7 < 250 Ok

8 > MAIL FROM : < martin . mueller@example . org >

¹ Telnet ist ein im Internet weit verbreitetes Protokoll welches in der RFC 854 und RFC 855 be-

schrieben ist. Das Telnet-Protokoll bietet eine bi-direktionale, 8-bit-pro-Byte-orientierte Kommunikationsm¨ oglichkeit an, welches dazu benutzt wird Benutzern ¨ uber die Kommandozeile Zugang zu Internetrechnern zu bieten.

8

3 Protokolle

9 < 250 Ok

10 > RCPT TO : < foo@example . com >

11 < 250 Ok

12 > DATA

13 < 354 End data with < LF >. < CR > < LF >

14 > From : < martin . mueller@example . org >

15 > To : < foo@example . com >

16 > Subject : Testmail

17 >

18 > Testmail

19 > .

20 < 250 OK

21 > quit

Eingaben des Benutzers sind mit > gekennzeichnet, < wiederum zeigen die Ant-worten des Servers. In der ersten Zeile wird eine Telnetverbindung zum SMTP-Server mail.server.net aufgebaut, daf¨ ur wird der standard SMTP-Port 25 verwendet. Zeile zwei bis f¨ unf bezeichnet den Verbindungsaufbau. In Zeile sechs wird dem Server das initialisierende HELO geschickt, gefolgt von dem lokalen Rechnernamen, der beliebig gew¨ ahlt werden kann. Wenn der Server das eingehende HELO akzeptiert, dann kann mit MAIL FROM und RCPT TO die Envelope-Absenderadresse und Envelope-Empf¨ angeradresse eingegeben werden. Beim Routen der E-Mails durchs Netz lesen die Mailserver immer nur die Envelope-Adressen. Der Mail-Header ist f¨ ur das Routen absolut unwichtig. Werden die Envelope-Adressen vom Server akzeptiert, kann wie in Zeile 12 mit der Erstellung der E-Mail begonnen werden. In Zeile 14 bis 16 werden einige Headerfelder gef¨ ullt. In RFC 822 ist genau beschrieben wie eine E-Mail auf zu bauen ist. Jede E-Mail besteht aus einem Header und optional aus einem Text, wobei einige Headerfelder “From”, “To” und “Subject” sind. Eine komplette Auflistung aller Headerfelder ist in der RFC 822 zu finden. Nachdem die E-Mail ¨ uber einen Header verf¨ ugt, kann ein optionaler Text, wie in Zeile 18, angeh¨ angt werden. Mit einem Punkt in einer neuen Zeile wird dem Server mitgeteilt, dass jetzt die Nachricht erstellt ist und die Mail zustellt werden kann. In Zeile 21 wird die Telnetsitzung schließlich beendet.

Ein Mailprogramm ¨ ubernimmt die Durchf¨ uhrung der Protokolls. F¨ ur die SMTP Kommunikation ist immer der MTA zust¨ andig.

Um SMTP f¨ ur eine feindliche Umgebung zu wappnen wurde es 1995 um einige Funktionen erweitert zu Extended SMTP/ESMTP, welches in der RFC 1869 genau beschrieben ist. Wird ein Mailserver mit einem EHLO (Extended HELO) begr¨ ußt, statt dem ¨ ublichen HELO, so wird als Antwort eine Liste der zus¨ atzlichen Befehle

9

3 Protokolle

ausgegeben die der Mailserver beherrscht. Siehe hierzu Listing 3.2.

1 > telnet mail . server . net 25

2 < Trying 213.165.64.20...

3 < Connected to mail . server . net .

4 < Escape character is ’ ^{}] ’

5 < 220 { mp030 } Mailserver SMTP

6 > EHLO

7 < 8 BITMIME

8 < ENHANCEDSTATUSCODES

9 < AUTH = LOGIN CRAM - MD5 PLAIN

10 < AUTH CRAM - MD5 LOGIN PLAIN

11 < STARTTLS

12 > MAIL FROM : martin . mueller@server . net

13 < Need to authenticate via SMTP - AUTH - Login

Zeilen acht und neun zeigen, dass der Server eine Authentifikation verlangt. In Zeile neun ist zu sehen das der Server die Authentifikationsmethoden “Plain”, “Login” und “Cram-MD5” unterst¨ utzt, die in den Abschnitten 3.2.2, 3.2.3 und 3.2.4 erkl¨ art sind. Zeile zehn beginnt mit der Erstellung einer Mail, in der darauf folgenden Zeile verlangt der Server eine Authentifikation, denn dieser Server unterst¨ utzt nicht nur eine Authentifikation, sondern verlangt auch eine explizit. Es handelt sich hierbei um kein offenes Relay. E-Mails werden nur noch von Usern angenommen die auf dem Server ein Account haben und sich erfolgreich authentifiziert haben, wobei die meisten der großen Mailserver Heute nach dieser Art aufgebaut sind.

Zeile elf verdeutlicht, dass der Server außerdem TLS unterst¨ utzt. Somit kann ein verschl¨ usselter Kanal zwischen Client und Server aufgebaut werden, durch das die Authentifikation und alle nachfolgenden Nachrichten getunnelt werden k¨ onnen. Diese M¨ oglichkeit sollte immer genutzt werden, da ansonsten Passwort und Benutzername in Klartext ¨ ubertragen werden. Jemand, der die Leitung abh¨ ort, kann so recht leicht mit einem so genannten “sniffer-Programm” das Passwort und den Benutzernamen heraus filtern, mit den geklauten Daten in einer sp¨ ateren Sitzung als einen Benutzer ausgeben, der er nicht ist, und in dessen Namen kriminelle Aktivit¨ aten aus¨ uben.

Aber auch wenn der Sender das SMTP Protokoll durch einen sicheren TLS-Kanal tunnelt, wird die zu verschickende Nachricht nur auf dem k¨ urzesten Teil der Strecke sicher ¨ ubertragen. Abbildung 3.1 auf Seite 8 gibt hierzu Aufschluss.

10

3 Protokolle

Die durchgezogenen gr¨ unen Pfeile repr¨ asentieren Protokolle, die durch einen sicheren TLS Kanal geschleust werden. Auf diese Strecken k¨ onnen Sender und Empf¨ anger Einfluss nehmen. Die gestrichelten roten Pfeile stellen die Strecken zwischen den Servern im Internet da, auf welche weder Sender noch Empf¨ anger Einfluss nehmen k¨ onnen. Die Nachrichten auf den roten Strecken werden meistens aus Kostengr¨ unden unverschl¨ usselt verschickt, somit kann jeder, der diese Leitung abh¨ ort, die E-Mails im Klartext lesen. Um das zu verhindern, sollte man die Nachrichten beispielsweise mit PGP verschl¨ usseln. Dann wird die Nachricht immer noch durch einen unsicheren Kanal geschickt, da jedoch die Nachricht selbst verschl¨ usselt ist, kann sie von niemandem gelesen werden, außer dem Empf¨ anger.

3.1.2 LMTP

LMTP (Local Mail Transfer Protocol) ist in der RFC 2033 genau beschrieben. Es ist eine Variante des SMTP-Protokolls und f¨ ur die lokale Zustellung von Nachrichten zust¨ andig.

Statt mit einem HELO oder EHLO, wie bei einem SMTP-Server, ist ein LMTP-Server mit einem LHLO zu begr¨ ussen. Listing 3.3 zeigt zur Veranschaulichung eine Telnetsitzung mit LMTP.

1 > telnet mail . server . net 25

2 < Trying 213.165.64.20...

3 < Connected to mail . server . net .

4 < Escape character is ’ ^{}] ’

5 < 220 { mp030 } Mailserver SMTP \ index { SMTP }

6 > LHLO mail . example . org

7 < 250 Ok

8 > MAIL FROM : < martin . mueller@example . org >

9 < 250 Ok

10 > RCPT TO : < foo@example . org >

11 < 250 Ok

12 > DATA

13 < 354 End data with < CRLF >. < CRLF >

14 > From : < martin . mueller@example . org >

15 > To : < foo@example . com >

16 > Subject : Testmail

17 >

18 > Testmail

19 > .

20 < 250 OK

21 > quit

3 Protokolle

Wie hier zu sehen ist, verh¨ alt sich das LMTP-Protokoll genauso wie das SMTP-Protokoll. Der einzige Unterschied ist, dass LMTP die Nachrichten versucht lokal zu zustellen und daf¨ ur keine eigene Queue ben¨ otigt. Wenn die lokale Zustellung fehlschl¨ agt, wir die Nachricht abgewiesen.

LMTP kommt unter anderem in den MTAs Sendmail, Exim und Postfix zum Einsatz.

3.1.3 POP3

Die Geschichte des POP[Hun04] (Post Office Protocol Version 3) Protokolls beginnt in den fr¨ uhen 80ern. Damals war die Anzahl der Personen die E-Mails empfingen und versandten noch recht ¨ uberschaubar. Der Benutzer logte sich damals von seinem Terminal aus per Telnet auf dem Großrechner ein und las und schrieb dort seine E-Mails, denn Personalcomputer waren damals noch sehr teuer und nicht weit verbreitet.

Die Entwickler erkannten jedoch, dass es bestimmte Vorteile bietet, wenn E-Mails auf einem lokalen Rechner gespeichert werden und das Einlogen auf dem Großrechner nicht n¨ otig ist. Aus diesem Grund wurde 1984 RFC 918 ver¨ offentlicht, in dem die erste Version der POP Protokolls beschrieben ist. Die RFC ist lediglich f¨ unf Seiten lang (was f¨ ur eine RFC sehr kurz ist). Das Protokoll in der Version eins ist sehr simpel gehalten, wobei es die M¨ oglichkeit sich auf dem Server einzulogen bietet, und alle Nachrichten auf einmal downzuloaden und damit auch zu l¨ oschen. Eine einzelne Nachricht von Mehreren kann mit dem Protokoll nicht herunter geladen werden.

1985 wurde POP Version 2 in der RFC 937 ver¨ offentlicht. In dieser nach gebesserten Version ist es auch m¨ oglich, einzelne Nachrichten vom Server zu downloaden und sie zu l¨ oschen. Es ist auch m¨ oglich, eine Nachricht zu downloaden und sie trotzdem auf dem Server zu lassen. Demnach hat ein Download nicht zwangsweise das L¨ oschen der Nachricht zur Folge.

1988 wurde schließlich in der RFC 1081 POP Version 3 (POP3) ver¨ offentlicht. In dieser Zeit gewannen die PCs immer mehr an Popularit¨ at, da sie Leistungsf¨ ahiger und f¨ ur immer mehr Menschen erschwinglich wurden. POP3 ist sehr stark an POP2 angelehnt. Es wurde f¨ ur User ausgelegt, die keine st¨ andige Verbindung ins Internet haben. Das Internet entwickelte sich rasant und in Folge dessen wurde auch das POP3 Protokoll immer weiter angepasst. Die letzte ¨ Anderung erfuhr das Protokoll

12

3 Protokolle

1996 in der RFC 1939.

POP3 ist das Standardprotokoll im Internet zur ¨ Ubertragung von E-Mails vom

Server zum Client, welches in der RFC 1939 exakt beschrieben ist. Das Protokoll ist sehr simpel gestaltet und dient lediglich dem Zweck E-Mails vom Server zu holen und sie von dort zu l¨ oschen. Tabelle 3.1 zeigt die standard POP3-Kommandos.

Tabelle 3.1: POP3 Befehle

Eine Telnetsitzung mit POP3 kann wie folgt aussehen.

1 > telnet pop . gmx . net 110

2 < Trying 213.165.64.20...

3 < Connected to pop . gmx . net .

4 < Escape character is ’ ^{}] ’

5 < + OK GMX POP3 StreamProxy ready <22132.1114520671

6 > USER 666666

7 < + OK May I have your password , please ?

8 > PASS 666666

9 < + OK mailbox has 5 messages (81766 octets )

10 > STATE

11 < + OK 5 81766

12 > LIST

13 < + OK mailbox has 5 messages (81766 octets )

14 < 1 1167

15 < 2 2364

16 < 3 2640

17 < 4 72129

18 < 5 3466

19 > QUIT

20 < + OK bye

Zeile eins zeigt den Aufbau einer Telnetsitzung zum POP3-Server von GMX ¨ uber

den standard POP3-Port 110. Benutzername und Passwort werden in Zeile sechs

13

3 Protokolle

und acht erfolgreich ¨ ubermittelt. Nach der Anmeldung meldet der Server, dass f¨ unf Nachrichten in der Mailbox eingegangen sind. Mit dem Befehl STATE, in Zeile zehn, wird nochmals die Gesamtzahl der Nachrichten und ihre Gr¨ oße angezeigt. Der Befehl LIST aus Zeile zw¨ olf listet abermals alle Nachrichten einzeln auf und zeigt ihre Gr¨ oße an. Mit QUIT wird die Telnetsitzung schließlich beendet.

Auch hier sei ausdr¨ ucklich darauf hingewiesen, dass Benutzername und Passwort in Klartext ¨ ubermittelt werden. Dadurch besteht die gleiche Problematik wie beim SMTP Protokoll. Wie auch beim SMTP Protokoll kriegen die meisten Benutzer nichts von dem Ablauf dieses Protokolls mit, weil es von einem Mailprogramm ausgef¨ uhrt wird.

Im POP3 Protokoll gibt es den optionalen Befehl APOP (Authenticated Post Office Protocol), mit dem eine sichere Authentifikation m¨ oglich ist. Beim APOP kommt schließlich das Cram-MD5 Verfahren aus Abschnitt 3.2.4 zum Einsatz. Wenn der Server die APOP Authentifizierung unterst¨ utzt, schickt er beim Verbindungsaufbau einen Zeitstempel mit, welcher folgenden Aufbau besitzt.

Im oberen Beispiel zur Telnetsitzung mit POP3 ist in Zeile f¨ unf dieser Wert zu sehen.

<22132.1114520671@mp018>

Der Zeitstempel ist elementar f¨ ur das APOP Verfahren. Auf der Clientseite wird ein MD5-Hashwert gebildet ¨ uber den Zeitstempel und das bekannte Passwort. Dieser

MD5-Digest wird via APOP an den Server geschickt. Der Server f¨ uhrt die gleiche Berechnung durch und vergleicht sein Ergebnis mit dem empfangenen Wert vom Client. Stimmen die beiden MD5-Digest ¨ uberein, hat sich der Client erfolgreich authentifiziert. Die APOP Syntax sieht wie folgt aus.

APOP name digest

Der Name wird in Klartext geschickt. Das Digest ist der berechnete Hashwert. Bei diesem Verfahren wird kein Passwort ¨ uber das Netz geschickt, nur ein Hashwert, dessen Wert auf Grund des Zeitstempels jedes mal verschieden ist. Diese Art der Authentifikation ist unbedingt zu empfehlen. Da alle Nachrichten, die nach der Authentifikation zum Server geschickt werden, jedoch unverschl¨ usselt sind, empfiehlt

14

3 Protokolle

es sich das POP3 Protokoll durch TLS zu tunneln. Aber auch wenn das POP3 Protokoll durch TLS getunnelt wird, sollte nicht vergessen werden, dass die Nachricht dann nur auf dem letzten Abschnitt sicher ¨ uber das Netz geschickt wird. Eine dauerhafte Geheimhaltung der Nachricht kann beispielsweise durch PGP erreicht werden.

3.1.4 IMAP

Das IMAP[29] (Internet Message Access Protocol) Protokoll wurde 1986 an der Stanford Universit¨ at konzipiert. Ein Jahr sp¨ ater wurde IMAP Version 2.0 ver¨ offentlicht und ein UNIX-IMAP-Server implementiert. 1988 wurde es von der IETF als Standard aufgenommen und in der RFC 1064 genau beschrieben. Im laufe der Jahre wurde das Protokoll immer weiter entwickelt, bis es schließlich 1994 die Version 4.0 erreichte in den RFC 1730-1733. Seitdem wurde das Protokoll nur sehr geringf¨ ugig ge¨ andert, wobei die letzte ¨ Anderung IMAP 2003 erfuhr. Zur Zeit befindet sich das

Protokoll in der Version 4rev1, beschrieben in der RFC 3501. Wer sich n¨ aher f¨ ur das Protokoll interessiert, dem sei die URL www.imap.org[29] empfohlen.

Das IMAP Protokoll kann alles was das POP3 Protokoll kann, bietet aber dar¨ uber hinaus noch Funktionen an, um E-Mails auf dem Server zu verwalten. Die genaue Beschreibung des Protokolls ist in RFC 3501 zu finden.

POP3 und IMAP sprechen v¨ ollig unterschiedliche Zielgruppen an. User die POP3 benutzen, gehen online, holen ihre E-Mails vom Server ab, l¨ oschen sie dort, gehen wieder offline und verwalten ihre E-Mails auf ihrem lokalen Rechner. User die IMAP benutzen sind meistens viel unterwegs und haben kein Interesse daran, ihre Nachrichten vom Server auf einen Rechner zu laden, der nicht andauernd online ist. Sie wollen viel mehr ihre Nachrichten an einer zentralen Stelle, auf einem Server im Internet verwalten. Das bietet den Vorteil, dass sie von mehreren Rechnern auf ihre E-Mails zugreifen k¨ onnen. Unabh¨ angig davon ob der User zu Hause, in der Arbeit, unterwegs oder im Urlaub ist, kann er von jedem Computer mit Internetzugang auf alle seine E-Mails zugreifen.

Nat¨ urlich bietet auch IMAP, wie POP3, die M¨ oglichkeit E-Mails vom Server auf einen lokalen Rechner zu downloaden und E-Mails vom Server zu l¨ oschen. Zudem bietet IMAP noch folgende wichtige Funktionen:

• Es ist m¨ oglich auf dem Server, neben dem Posteingang, noch weitere Verzeich-

15

3 Protokolle

nisse anzulegen.

• Dem User ist es gestattet Sortierungsregeln festzulegen, die es erlauben, E-Mails die einem bestimmten vordefinierten Muster entsprechen, in ganz bestimmte vordefinierte Verzeichnisse abzulegen. So k¨ onnte z.B. eine Regel festlegen, das E-Mails die von ebay.de verschickt sind, nicht im Posteingang, sondern im Ordner ebay landen.

Ein weiterer großer Vorteil von IMAP ist, dass Such- und Sortieroperationen serverseitig ablaufen. Ein User, der nur einen Computer mit schwacher CPU besitzt, kann trotzdem an einer großen Mailbox sehr effizient arbeiten.

3.2 Sicherheits-Protokolle

Sicherheitsprotokolle legen verschiedene Verfahren fest, die es zwei Rechnern erm¨ oglichen verschl¨ usselt Daten auszutauschen. Einem Dritten ist dadurch der Zugang zu Nachrichten und Passw¨ ortern erschwert. Eine hundert prozentige Sicherheit gibt es nicht, jedoch besteht die M¨ oglichkeit es den Angreifern weitgehend zu erschweren. Das Ziel von Sicherheitsprotokollen ist es, die Privatsph¨ are des Einzelnen vor unberechtigtem Zugriff zu sch¨ utzen.

Sicherheitsprotokolle sind fester Bestandteil der heutigen E-Mailkommunikation und in den E-Mailprotokollen fest verankert. Um die E-Mailprotokolle in Abschnitt 3.1 auf Seite 7 vollst¨ andig zu verstehen, sind nachfolgend, die damit verbundenen Sicherheitsprotokolle erkl¨ art.

Zun¨ achst sind hier einige grundlegende Begriffe wie Symetrische, Asymetrische und Hybride Verfahren erkl¨ art. Anschliesend folgt eine ausf¨ uhrliche Erkl¨ arung des SSL ² /TLS ³ Protokolls gefolgt von den Authentifikationsverfahren Plain, Login und Cram-MD5. Zum Schluss dieses Abschnittes folgt eine Erkl¨ arung des PGP Verfahrens.

² Secure Socket Layer

³ Transport Socket Security

16

3 Protokolle

Symmetrische Verfahren

Symmetrische Verfahren[Wob01] sind kryptographische Algorithmen, die zum Entschl¨ usseln und Verschl¨ usseln den gleichen Schl¨ ussel K verwenden. Solche Algorithmen sind unter anderem IDEA ⁴ [27], Blowfish[6], Twofish[54], DES[17], TripleDES[17] und der j¨ ungste Algorithmus nennt sich AES[2].

Eine Nachricht N ist mit symetrischen Verfahren wie folgt zu verschl¨ usseln.

S = e(N, K)

Wobei e die Verschl¨ usselungsmethode ist und S die Verschl¨ usselte Nachricht. Dementsprechend gilt folgendes.

N = e(S, K)

Die Verschl¨ usselungsmethode e mit dem Schl¨ ussel K angewand auf die verschl¨ usselte Nachricht S ergibt wieder die urspr¨ ungliche unverschl¨ usselte Nachricht N.

Wenn eine Person mit Hilfe eines der eben genannten Algorithmen und einem geheimen Schl¨ ussel K eine Nachricht N verschl¨ usselt und diese ¨ uber das Internet an

einen Empf¨ anger schickt, so braucht der Empf¨ anger den gleichen geheimen Schl¨ ussel K zum Entschl¨ usseln der empfangenen Nachricht. Aber wie bekommt der Empf¨ anger den geheimen Schl¨ ussel?

Beim Versenden des geheimen Schl¨ ussels ¨ uber das Internet, besteht die Gefahr,

dass ihn ein b¨ oswilliger Dritter abf¨ angt und ihn zu unrechtm¨ assigen Zwecken missbraucht. Die einzig sichere M¨ oglichkeit ist darin gegeben, den Schl¨ ussel K pers¨ onlich zum Empf¨ anger zu bringen. Es ist unschwer zu erkennen, dass bei diesem Verfahren der Schl¨ usselaustausch sehr problematisch ist.

Asymmetrische Verfahren

1975 ver¨ offentlichten Diffie und Hellmann[Wob01] ihre Idee zur asymmetrischen Verschl¨ usselung, bei dem zwei verschiedene Schl¨ ussel zum Ver- und Entschl¨ usselung zum Einsatz kommen.

Das Verfahren sieht vor, einen privaten und einen ¨ offentlichen Schl¨ ussel zu erzeugen. Der ¨ offentliche Schl¨ ussel darf der ¨ Offentlichkeit zum download bereit stehen,

⁴ IDEA (International Data Encryption Algorithm) ist ein symetrischer Algorithmus der 1990 entwickelt

wurde.

17

3 Protokolle

z.B. auf der Homepage seines Besitzers. Mit diesem Schl¨ ussel kann jeder Anwender Nachrichten verschl¨ usseln. Das Entschl¨ usseln funktioniert jedoch nur mit dem privaten Schl¨ ussel, welchen der Besitzer geheim h¨ alt. Somit ist er der Einzige, der die verschl¨ usselten Nachrichten entschl¨ usseln kann.

Eine Nachricht N ist mit asymetrischen Verfahren wie folgt zu verschl¨ usseln.

S = e(N, Kp)

Wobei e wieder die Verschl¨ usselungsmethode ist, S die verschl¨ usselte Nachricht und Kp der ¨ offentliche Schl¨ ussel (public Key). Dementsprechend gilt f¨ ur die Entschl¨ usselung

N = e(S, Ks)

Wobei Ks der geheime private Schl¨ ussel (secret Key) ist.

Dieses Verfahren l¨ ost die Probleme der symmetrischen Verschl¨ usselung. Schl¨ ussel k¨ onnen problemlos ausgetauscht werden, ohne sie pers¨ onlich ¨ uberbringen zu m¨ ussen.

Jedoch haben Asymmetrische Verfahren den erheblichen Nachteil, dass sie, aus mathematischen Gr¨ unden deren Erkl¨ arung hier den Rahmen sprengen w¨ urde, um den Faktor 100 langsamer sind als symmetrische Verfahren.

Hybride Verfahren

Hybride Verfahren[Wob01] sind Kombinationen aus der symmetrischen und asymmetrischen Verschl¨ usselung. Hybride Verfahren kommen oft bei Netzwerkkommunikation zum Einsatz, so auch bei SSL(Secure Socket Layer) und TLS(Transport Socket Security), zu denen Abschnitt 3.2.1 genauer Auskunft gibt. Mit Hilfe von asymmetrischen Verfahren ist es m¨ oglich einen symmetrischen Schl¨ ussel zu vereinbaren. Die Kommunikation der Nutzdaten ist dannach symmetrisch verschl¨ usselt. Auf diese Weise ist die Sicherheit der asymmetrischen Verfahren und die Schnelligkeit der symmetrischen Verfahren gegeben.

3.2.1 SSL/TLS

SSL[52] (Secure Socket Layer) und TLS[52] (Transport Socket Security) sind Verfahren mit dem zwei Rechner einen gemeinsamen symmetrischen Schl¨ ussel und einen Verschl¨ usselungsalgorithmus bestimmen, den beide Teilnehmer beherschen. Solche Verschl¨ usselungsalgorithmen sind unter anderem IDEA[27], Blowfish[6], Twofish[54],

18

3 Protokolle

DES[17], TripleDES[17] und AES[2]. Die zwei Rechner benutzen f¨ ur die Dauer der aktuellen Sitzung den vereinbarten Schl¨ ussel und Algorithmus um ihre Nachrichten zu ver- und entschl¨ usseln. H¨ ort ein Dritter die Leitung ab, kann er aus dem verschl¨ usselten Datenstrom keine Information gewinnen. SSL/TLS kommt bei der E-Mailkommunikation zum Einsatz, wenn es darum geht die Authentifikation und die darauf folgenden Nachrichten zwischen Client und Server durch einen sicheren Kanal zu t¨ atigen.

Geschichte des SSL/TLS

SSL[52] wurde von der Firma Netscape entwickelt und 1994 in der Version 1.0 ver¨ offentlicht. Die Firma war zu der Zeit Marktf¨ uhrer f¨ ur Webbrowser. Das Protokoll in der Version 1.0 wies jedoch Sicherheitsl¨ ucken auf, woraufhin Netscape 1995 ihren neuen Netscape Comunicator 2.0 mit der nachgebesserten SSL Version 2.0 ver¨ offentlichte.

Zur gleichen Zeit ver¨ offentlichte die Firma Microsoft[36] einen eigenen Webbrowser, den Internet Explorer 1.0, mit dem PCT[52] 1.0 (Private Communication Technology) Protokoll. Das PCT war die direkte Konkurrenz zu SSL und bot anfangs auch einige erhebliche Vorteile gegen¨ uber diesem.

• PCT 1.0 kann mit weniger Nachrichten als SSL 2.0 einen Verschl¨ usselungs-algorithmus zwischen zwei Rechnern aushandeln und ist damit um einiges schneller.

• Es unterst¨ utzt mehr Verschl¨ usselungsalgorithmen als SSL 2.0.

• Zur Authentifikation und zur Verschl¨ usselung der Nutzdaten kommen zwei unterschiedliche Schl¨ ussel zum Einsatz.

Das alles hat schließlich mit dazu beigetragen, dass Netscape Marktanteile an Microsoft[36] verlor.

1999 ver¨ offentlichte Netscape schließlich ihren Netscape Comunicator 4.7 mit dem neuen SSL 3.0. Diese Version des Protokolls beherrschte auch alle Features des PCT von Microsoft[36] Was dazu f¨ uhrte, dass das IETF[28] (Internet Engineering Task Force) SSL 3.0, mit einigen ¨ Anderungen, noch im selben Jahr zum Standard er-

hob und es umbenannte in TLS 1.0 (Transport Layer Security), welches in RFC 2246 dokumentiert ist. TLS 1.0 unterscheidet sich in einigen Punkten von SSL 3.0. Der gr¨ oßte Unterschied liegt im kryptographischen Algorithmus Fortezza, was ein

19