Eidesstattliche Erklärung
Danksagung
Vorkenntnisstand
Verwendete Werkzeuge
1 Ziele der Diplomarbeit
2 Einführung
2.1 E-Mail-Komponenten
2.2 MIME
3 Protokolle
3.1 E-Mail Protokolle
3.1.1 SMTP
3.1.2 LMTP
3.1.3 POP3
3.1.4 IMAP
3.2 Sicherheits-Protokolle .
3.2.1 SSL/TLS
3.2.2 Plain-Authentifikation
3.2.3 Login-Authentifikation
3.2.4 Cram-MD5
3.2.5 PGP
4 Message-Store
4.1 Mbox
4.2 Mh
4.3 Maildir
4.4 Mailboxvergleich
5 Mail-User-Agent
5.1 Thunderbird
5.2 Mutt
5.3 Die Mutt-Kette
6 Mail-Delivery-Agent
6.1 Procmail
7 Mail-Travel-Agent
7.1 Geschichtlicher Überblick der MTAs
7.2 Sendmail
7.2.1 Sendmail Inc
7.2.2 Dokumentation
7.2.3 Konfiguration
7.2.4 Vorteile
7.2.5 Nachteile
7.3 Postfix
7.3.1 Ziele von Postfix
7.3.2 Dokumentation
7.3.3 Architektur
7.3.4 Konfiguration
7.3.5 Vorteile
7.3.6 Nachteile
7.4 Exim
7.4.1 Dokumentation
7.4.2 Konfiguration
7.4.3 Exim-Utilities
7.4.4 Vorteile
7.4.5 Nachteile
7.5 Qmail
7.5.1 Dokumentation
7.5.2 Konfiguration .
7.5.3 Vorteile
7.5.4 Nachteile
7.6 Zmailer
7.6.1 Dokumentation
7.6.2 Konfiguration
7.6.3 Vorteile
7.6.4 Nachteile
7.7 Masqmail
7.7.1 Dokumentation
7.7.2 Konfiguration
7.7.3 Vorteile
7.7.4 Nachteile
7.8 Comunigate Pro
7.8.1 Dokumentation
7.8.2 Konfiguration
7.8.3 Vorteile
7.8.4 Nachteile
7.9 Vergleichsmatrizen
8 Java-Mail-Travel-Agent
8.1 Programmaufbau
8.2 Installation
8.3 Konfiguration
8.4 Bedienung
8.5 Anwendungsbeispiele
8.5.1 Mutt mit JMTA
8.5.2 Perl-Scripte mit JMTA
8.6 Probleme und Nachteile
8.7 Ausblick in die Zukunft
9 Anhang
3.1 POP3 Befehle
3.2 Client Hello Message
3.3 Server Hello Message
4.1 Mailboxvergleich
4.2 Unterstützte Postfachsysteme in E-Mailprogrammen
7.1 Postfix-Parameter
7.2 Exim Utilities
7.3 MTAs
7.4 MTA Lizenzen
7.5 MTA Konfigurierbarkeit
7.6 MTA Sicherheit
7.7 MTA Relaying
8.1 JMTA Felder
8.2 JMTA Aufrufe
2.1 E-Mail-Komponenten, Weg einer E-Mail
2.2 Aufbau einer E-Mail
3.1 E-Mail-Versand
3.2 SSL/TLS Sicherheitsschicht
3.3 SSL/TLS Schichtenmodell
3.4 SSL/TLS Handshake
3.5 Digitale Signatur
3.6 PGP mit mehreren Empfängern
4.1 Mailbox
5.1 Thunderbird
5.2 Mutt
7.1 MTA Timeline
7.2 E-Mailprogramm
7.3 Postfix Architektur
7.4 Admin-GUI von Communigate Pro
8.1 Klassendiagramm
8.2 Zustandsdiagramm
8.3 Install-Script
8.4 JMTA config
8.5 JMTA receive
8.6 JMTA receive im Debugmode
8.7 JMTA send
8.8 JMTA send mit Anhang
8.9 index.html
8.10 Antwort auf index.hmtl
2.1 Aufbau einer E-Mail
3.1 SMTP via Telnet
3.2 ESMTP via Telnet
3.3 LMTP via Telnet
3.4 POP3 via Telnet
3.5 Login-Authentication
4.1 Mbox-Datei
6.1 Procmail-Regeln
6.2 Procmail-Regeln
7.1 linux.mc
7.2 /etc/sendmail.cf
7.3 aliases
7.4 Cram-MD5
7.5 smtp-policy.src
7.6 masqmail.conf
8.1 jmtaSettings.xml
8.2 index.html
8.3 message.pl
9.1 Start
9.2 Xml
9.3 Crypt
9.4 Account
9.5 Sender
9.6 Receiver
9.7 Gui
9.8 PasswordField
9.9 EraserThread
9.10 jmta
9.11 install
Ich versichere, dass ich die vorliegende Arbeit selbstständig und ohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe. Alle Stellen, die wörtlich oder sinngemäß aus veröffentlichten und nicht veröffentlichten Schriften entnommen wurden, sind als solche kenntlich gemacht. Die Arbeit hat in dieser oder ähnlicher Form keiner anderen Prüfungsbehörde vorgelegen.
Mannheim, den 9. November 2005
Robert Reiz
Dank gebührt Prof. Dipl.-Infrom. Günther Bengel für seine Unterstützung und Be- treuung im Rahmen dieser Diplomarbeit. Vielen Dank auch an Dipl.-Inform. Chri- stian Baun, der mir bei Problemen mit LATEX[Kop05] immer mit Rat und Tat zur Seite stand.
Desweiteren möchte ich mich hier auch bei meiner Schwester Johanna Maria Reiz bedanken, die mir gelegentlich bei der Formulierung meiner Sätze beistand. Großer Dank gebührt auch meinen Eltern Maria Reiz und Julius Reiz, die mir mein Studium erst ermöglicht haben und mich in dunklen Stunden meines Studiums immer ermutigten weiter zu machen.
Ich setze voraus, dass der Leser dieses Dokumentes über die Grundkenntnisse der Informatik und Kenntnisse in der Java-Programmierung verfügt. Das Verständnis für die UML[Kec05] 2.0 Notation sollte dem Leser ebenfalls nicht ganz fremd sein.
Diese Diplomarbeit entstand auf einem 12 Zoll PowerBook G4 unter dem Betriebs- system MacOS X Tiger von Apple4. Für die Textsetzung habe ich LATEX[Kop05] in Verbindung mit BibTeX5, für das Literaturverzeichnis, benutzt. Um aus dem LATEX-Code eine PDF zu erzeugen benutzte ich das Programm Pdflatex43 in der Version 3.1. Zur Editierung der LATEX-Dateien benutzte ich den UNIX-Editor E- macs21 in der Version 2.1.
Für das Erstellen der technischen Zeichnungen, wie z.B. Klassendiagramm, Zu- standsdiagramm etc., kam das Programm Dia18 in der Version 0.94 zum Einsatz.
Den Webbrowser Firefox37 in der Version 1.0.4 benutzte ich für meine Recherchen im Internet.
Zur Erstellung des JMTA-Projekts kamen die Entwicklungsumgebung Eclipse20 3.1, Apache Ant3 1.6.2 und die Programmiersprache Java30 1.4.2-54 von der Firma SUN53 zum Einsatz.
Diese Diplomarbeit bietet einen Überblick 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 OpenSource-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öglich sein die Konfiguration über eine grafischer Benutzeroberfläche abzuwickeln.
- Der MTA soll die heutigen Sicherheitsstandards gewährleisten. Das bedeutet: Die Passwörter die unverschlüsselt auf der Festplatte abgelegt oder über das Netz geschickt werden sind nicht akzeptabel.
- Konfigurationsdateien die keine systemweite Gültigkeit 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öglich sein.
Abschnitt 2 gibt eine Einführung in die Thematik, sowie einen Überblick über die E-Mail-Kommunikation. Die einzelnen Bausteine der heutigen E-Mail-Kommunikation sind hier vorgestellt und kurz erläutert.
Abschnitt 3 erläutert alle für die E-Mailkommunikation relevanten Protokolle. Dazu gehören mit SSL/TLS, Plain, Login, Cram-MD5 und PGP die Sicherheitspro- tokolle, genauso wie die E-Mail-Protokolle POP3, SMTP, LMTP und IMAP.
Abschnitt 4, 5 und 6 erklären ausführlich die Begriffe Message-Store, Mail-User- Agent und Mail-Delivery-Agent. Außerdem stellen sie zu den abstrakten Begriffen
Beispielprogramme vor, damit der Leser sich ein besseres Bild von diesen Systemen machen kann.
Abschnitt 7 stellt die gängigsten 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üllt.
Die heutigen E-Mailkomponenten sind in drei Kategorien aufgeteilt, Sender, Server und Empfänger. 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ür solche Programme sind Thunderbird von der Open Sour- ce Community auf www.mozilla.org37, Mutt von der Open Source Community auf www.mutt.org38 und Outlook von der Firma Microsoft auf www.microsoft.com36. Nachdem die Nachricht erstellt ist, wird diese an den Mail-Travel-Agent (MTA) des Rechners übergeben. Abbildung 2.1 zeigt den Weg, den eine E-Mail vom Sender bis zum Empfänger zurücklegt. Die Nummern eins bis acht zeigen die Reihenfolge der Stationen welche die E-Mail bis zum Empfänger passiert.
Abbildung 2.1: E-Mail-Komponenten, Weg einer E-Mail
Abbildung in dieser Leseprobe nicht enthalten
Der MTA ist eine Softwarekomponente die für das Versenden und Empfangen der E-Mails via SMTP-Protokoll (RFC1 2821) zuständig ist. Die E-Mail-Protokolle, zu denen auch SMTP gehört, sind in Abschnitt 3.1 auf Seite 7 ausführlich beschrieben. Der MTA schickt die E-Mail an den E-Mailserver des Benutzers Mike, z.B. gmx.net.
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 Ser- verseite steht ebenfalls ein MTA, der für eingehende Nachrichten zuständig ist, eine Authentifikation durchführt und die Empfängeradresse analysiert. In Abhängigkeit von der Analyse der Empfängeradresse 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ück zu schicken ist, weil die Empfängeradresse ungültig ist.
Hier ist ein simpler Fall beschrieben, in dem der Server die E-Mail intern weiter- verarbeitet. 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ührlich behandelt. Je nachdem welche Muster zutreffen, wird die Nachricht vom MDA entweder im Po- steingang, 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änger sie abholt.
Der Empfänger, z.B. der User Bob, der die Nachricht von Mike erhält, 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ängers, alle Nachrichten, die dem Empfänger gehören, aus dem Message-Store holt und dem MTA zur Verfügung stellt. Der Mail-Travel-Agent schreibt alle run- tergeladenen Nachrichten in den MS des Empfängers. Der Mail-User-Agent greift lesend auf den Message-Store zu und stellt sie dem Empfänger Bob zur Verfügung. Die Protokolle POP und IMAP gehören zu den E-Mailprotokollen und sind in Ab- schnitt 3.1.3(POP) auf Seite 12 und in Abschnitt 3.1.4(IMAP) auf Seite 15 erklärt.
MIME steht für “Multipurpose Internet Mail Extensions” oder auch “Multimedia In- ternet Message Extensions”. MIME ist ein Kodierstandard, das Struktur und Aufbau von E-Mails und Internetnachrichten beschreibt. Es ermöglicht dem Sender und dem Empfänger Informationen über den Typ der zu verschickenden Nachricht (Content- Type), sowie dessen Kodierung bei der Übertragung (Content-Transfer-Encoding) auszutauschen. Binärdaten werden vor der Übertragung immer in Base64 kodiert.
Eine E-Mailnachricht besteht immer aus einem Header, einem Body und und optional aus beliebig vielen Attachments (Anhang).
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.2: Aufbau einer E-Mail
Der Header enthält allgemeine Informationen über die E-Mail, wie z.B. Absenderadresse, Empfängeradresse und Betreff der Nachricht. Der Body enthalten die Nachricht in Textform. Attachments (Anhang) sind optional und beinhalten angehängte Dateien. Listing 2.1 zeigt eine typische E-Mail mit einem Header einem Body und einem Anhang.
Listing 2.1: Aufbau einer E-Mail
Abbildung in dieser Leseprobe nicht enthalten
Die Zeilen eins bis fünf enthalten den Header der Nachricht, in dem Absen- deradresse, Empfängeradresse, 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ält, dessen Inhalte unterschiedlich kodiert sind.
Zeile sieben bis Zeile elf enthält den Bodypart. Zeile acht enthält den Content- Type dieses Bodyparts, der besagt, dass dessen Inhalt Klartext in UTF-8 Kodierung enthält.
Die Zeilen zwölf bis 22 zeigen den Anhang, der laut Content-Type ein Bild im gif-Format enthält mit dem Namen “bild.gif”. Da es sich hierbei um Binärdaten handelt, ist das Bild in Base64 kodiert.
S/MIME (Secure MIME) ist eine Erweiterung des MIME Standards, mit dem eine Verschlüsselung der Nachrichten, sowie eine Signierung dieser möglich ist. Die Begriffe Verschlüsselung und Signierung sind in Abschnitt 3.2 auf Seite 16 erklärt.
PGP/MIME ist ebenfalls eine Erweiterung des Standards mit dem ein sicherer und zu PGP kompatibler Datenaustausch möglich ist. Der Begriff PGP ist in Abschnitt 3.2.5 auf Seite 26 erklärt.
Ein Protokoll ist ein im Voraus und nach bestimmten Regeln definierter Ablauf eines Prozesses. Zum Verständnis dieser Arbeit sind Kenntnisse über Sicherheitsprotokolle und E-Mailprotololle von Nöten, welche nachfolgend vorgestellt sind.
Die E-Mailprotokolle, die in diesem Abschnitt erklärt 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).
SMTP[Hun04] (Simple Mail Transfer Protocol) wurde 1982 in der RFC 821 definiert. Computernetze waren zu der Zeit noch recht überschaubar und jeder Mailserver war ein offenes Relay. Das bedeutet, dass der Mailserver blind darauf vertraut, dass die Absenderadresse und die Empfängeradresse der E-Mail authentisch sind. Wie auch Sendmail, wurde dieses Protokoll nicht für eine feindliche Umgebung geschaffen. Offene Relays und das standard SMTP Protokoll sind ein Segen für alle, die Spam- Mails versenden und ein Fluch für alle Spam-Mail geschädigten 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ür, dass die Nachricht über das Internet an den Empfänger zugestellt wird. Siehe Abbildung 3.1.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3.1: E-Mail-Versand
Ist die E-Mail beim E-Mail-Server A angekommen, routet er diese durch das Internet. Über 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ängers ist. Hier wird die Nachricht solange aufbewahrt, bis der Empfänger sie über 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 Telnet1, per Hand, eine E-Mail verschickt werden kann. Siehe Listing 3.1.
Listing 3.1: SMTP via Telnet
Abbildung in dieser Leseprobe nicht enthalten
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ür wird der standard SMTP-Port 25 verwendet. Zeile zwei bis fünf bezeichnet den Verbindungsaufbau. In Zeile sechs wird dem Server das initialisierende HELO geschickt, gefolgt von dem lokalen Rechnernamen, der beliebig gewählt werden kann. Wenn der Server das eingehende HELO akzeptiert, dann kann mit MAIL FROM und RCPT TO die Envelope-Absenderadresse und Envelope-Empfängeradresse eingegeben werden. Beim Routen der E-Mails durchs Netz lesen die Mailserver immer nur die Envelope-Adressen. Der Mail-Header ist für das Routen absolut unwichtig. Werden die Envelope-Adressen vom Server ak- zeptiert, kann wie in Zeile 12 mit der Erstellung der E-Mail begonnen werden. In Zeile 14 bis 16 werden einige Headerfelder gefüllt. In RFC 822 ist genau beschrie- ben 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 über einen Header verfügt, kann ein optionaler Text, wie in Zeile 18, angehängt 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 übernimmt die Durchführung der Protokolls. Für die SMTP Kommunikation ist immer der MTA zuständig.
Um SMTP für 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üßt, statt dem üblichen HELO, so wird als Antwort eine Liste der zusätzlichen Befehle ausgegeben die der Mailserver beherrscht. Siehe hierzu Listing 3.2.
Listing 3.2: ESMTP via Telnet
Abbildung in dieser Leseprobe nicht enthalten
Zeilen acht und neun zeigen, dass der Server eine Authentifikation verlangt. In Zeile neun ist zu sehen das der Server die Authentifikationsmethoden “Plain”, “Lo- gin” und “Cram-MD5” unterstützt, die in den Abschnitten 3.2.2, 3.2.3 und 3.2.4 erklärt sind. Zeile zehn beginnt mit der Erstellung einer Mail, in der darauf folgen- den Zeile verlangt der Server eine Authentifikation, denn dieser Server unterstützt 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ützt. Somit kann ein verschlüsselter Kanal zwischen Client und Server aufgebaut werden, durch das die Authentifikation und alle nachfolgenden Nachrichten getunnelt werden können. Diese Möglichkeit sollte immer genutzt werden, da ansonsten Passwort und Benut- zername in Klartext übertragen werden. Jemand, der die Leitung abhört, kann so recht leicht mit einem so genannten “sniffer-Programm” das Passwort und den Be- nutzernamen heraus filtern, mit den geklauten Daten in einer späteren Sitzung als einen Benutzer ausgeben, der er nicht ist, und in dessen Namen kriminelle Akti- vitäten ausüben.
Aber auch wenn der Sender das SMTP Protokoll durch einen sicheren TLS-Kanal tunnelt, wird die zu verschickende Nachricht nur auf dem kürzesten Teil der Strecke sicher übertragen. Abbildung 3.1 auf Seite 8 gibt hierzu Aufschluss.
Die durchgezogenen grünen Pfeile repräsentieren Protokolle, die durch einen sicheren TLS Kanal geschleust werden. Auf diese Strecken können Sender und Empfänger Einfluss nehmen. Die gestrichelten roten Pfeile stellen die Strecken zwischen den Servern im Internet da, auf welche weder Sender noch Empfänger Einfluss nehmen können. Die Nachrichten auf den roten Strecken werden meistens aus Kostengründen unverschlüsselt verschickt, somit kann jeder, der diese Leitung abhört, die E-Mails im Klartext lesen. Um das zu verhindern, sollte man die Nachrichten beispielsweise mit PGP verschlüsseln. Dann wird die Nachricht immer noch durch einen unsicheren Kanal geschickt, da jedoch die Nachricht selbst verschlüsselt ist, kann sie von niemandem gelesen werden, außer dem Empfänger.
LMTP (Local Mail Transfer Protocol) ist in der RFC 2033 genau beschrieben. Es ist eine Variante des SMTP-Protokolls und für die lokale Zustellung von Nachrichten zuständig.
Statt mit einem HELO oder EHLO, wie bei einem SMTP-Server, ist ein LMTPServer mit einem LHLO zu begrüssen. Listing 3.3 zeigt zur Veranschaulichung eine Telnetsitzung mit LMTP.
Listing 3.3: LMTP via Telnet
Abbildung in dieser Leseprobe nicht enthalten
Wie hier zu sehen ist, verhält sich das LMTP-Protokoll genauso wie das SMTPProtokoll. Der einzige Unterschied ist, dass LMTP die Nachrichten versucht lokal zu zustellen und dafür keine eigene Queue benötigt. Wenn die lokale Zustellung fehlschlägt, wir die Nachricht abgewiesen.
LMTP kommt unter anderem in den MTAs Sendmail, Exim und Postfix zum Einsatz.
Die Geschichte des POP[Hun04] (Post Office Protocol Version 3) Protokolls beginnt in den frühen 80ern. Damals war die Anzahl der Personen die E-Mails empfingen und versandten noch recht überschaubar. Der Benutzer logte sich damals von sei- nem 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ßrech- ner nicht nötig ist. Aus diesem Grund wurde 1984 RFC 918 veröffentlicht, in dem die erste Version der POP Protokolls beschrieben ist. Die RFC ist lediglich fünf Seiten lang (was für eine RFC sehr kurz ist). Das Protokoll in der Version eins ist sehr simpel gehalten, wobei es die Möglichkeit sich auf dem Server einzulogen bietet, und alle Nachrichten auf einmal downzuloaden und damit auch zu löschen. Eine einzelne Nachricht von Mehreren kann mit dem Protokoll nicht herunter geladen werden.
1985 wurde POP Version 2 in der RFC 937 veröffentlicht. In dieser nach gebesserten Version ist es auch möglich, einzelne Nachrichten vom Server zu downloaden und sie zu löschen. Es ist auch möglich, eine Nachricht zu downloaden und sie trotzdem auf dem Server zu lassen. Demnach hat ein Download nicht zwangsweise das Löschen der Nachricht zur Folge.
1988 wurde schließlich in der RFC 1081 POP Version 3 (POP3) veröffentlicht. In dieser Zeit gewannen die PCs immer mehr an Popularität, da sie Leistungsfähiger und für immer mehr Menschen erschwinglich wurden. POP3 ist sehr stark an POP2 angelehnt. Es wurde für User ausgelegt, die keine ständige Verbindung ins Internet haben. Das Internet entwickelte sich rasant und in Folge dessen wurde auch das POP3 Protokoll immer weiter angepasst. Die letzte Änderung erfuhr das Protokoll 1996 in der RFC 1939.
POP3 ist das Standardprotokoll im Internet zur Übertragung 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öschen. Tabelle 3.1 zeigt die standard POP3-Kommandos.
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 3.1: POP3 Befehle
Eine Telnetsitzung mit POP3 kann wie folgt aussehen.
Listing 3.4: POP3 via Telnet
Abbildung in dieser Leseprobe nicht enthalten
Zeile eins zeigt den Aufbau einer Telnetsitzung zum POP3-Server von GMX über den standard POP3-Port 110. Benutzername und Passwort werden in Zeile sechs und acht erfolgreich übermittelt. Nach der Anmeldung meldet der Server, dass fünf Nachrichten in der Mailbox eingegangen sind. Mit dem Befehl STATE, in Zeile zehn, wird nochmals die Gesamtzahl der Nachrichten und ihre Größe angezeigt. Der Befehl LIST aus Zeile zwölf listet abermals alle Nachrichten einzeln auf und zeigt ihre Größe an. Mit QUIT wird die Telnetsitzung schließlich beendet.
Auch hier sei ausdrücklich darauf hingewiesen, dass Benutzername und Passwort in Klartext übermittelt 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 aus- geführt wird.
Im POP3 Protokoll gibt es den optionalen Befehl APOP (Authenticated Post Office Protocol), mit dem eine sichere Authentifikation möglich ist. Beim APOP kommt schließlich das Cram-MD5 Verfahren aus Abschnitt 3.2.4 zum Einsatz. Wenn der Server die APOP Authentifizierung unterstützt, schickt er beim Verbindungsaufbau einen Zeitstempel mit, welcher folgenden Aufbau besitzt.
Abbildung in dieser Leseprobe nicht enthalten
Im oberen Beispiel zur Telnetsitzung mit POP3 ist in Zeile fünf dieser Wert zu sehen.
Abbildung in dieser Leseprobe nicht enthalten
Der Zeitstempel ist elementar für das APOP Verfahren. Auf der Clientseite wird ein MD5-Hashwert gebildet über den Zeitstempel und das bekannte Passwort. Dieser MD5-Digest wird via APOP an den Server geschickt. Der Server führt die gleiche Berechnung durch und vergleicht sein Ergebnis mit dem empfangenen Wert vom Client. Stimmen die beiden MD5-Digest überein, 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 über das Netz geschickt, nur ein Has- hwert, 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üsselt sind, empfiehlt es sich das POP3 Protokoll durch TLS zu tunneln. Aber auch wenn das POP3 Pro- tokoll durch TLS getunnelt wird, sollte nicht vergessen werden, dass die Nachricht dann nur auf dem letzten Abschnitt sicher über das Netz geschickt wird. Eine dauer- hafte Geheimhaltung der Nachricht kann beispielsweise durch PGP erreicht werden.
Das IMAP29 (Internet Message Access Protocol) Protokoll wurde 1986 an der Stanford Universität konzipiert. Ein Jahr später wurde IMAP Version 2.0 veröffent- licht 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ügig geändert, wobei die letzte Änderung IMAP 2003 erfuhr. Zur Zeit befindet sich das Protokoll in der Version 4rev1, beschrieben in der RFC 3501. Wer sich näher für das Protokoll interessiert, dem sei die URL www.imap.org29 empfohlen.
Das IMAP Protokoll kann alles was das POP3 Protokoll kann, bietet aber darüber 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öllig unterschiedliche Zielgruppen an. User die POP3 benutzen, gehen online, holen ihre E-Mails vom Server ab, löschen 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 Nach- richten 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önnen. Unabhängig 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ürlich bietet auch IMAP, wie POP3, die Möglichkeit E-Mails vom Server auf einen lokalen Rechner zu downloaden und E-Mails vom Server zu löschen. Zudem bietet IMAP noch folgende wichtige Funktionen:
- Es ist möglich auf dem Server, neben dem Posteingang, noch weitere Verzeich- 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önnte 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.
Sicherheitsprotokolle legen verschiedene Verfahren fest, die es zwei Rechnern ermöglichen verschlüsselt Daten auszutauschen. Einem Dritten ist dadurch der Zugang zu Nachrichten und Passwörtern erschwert. Eine hundert prozentige Sicherheit gibt es nicht, jedoch besteht die Möglichkeit es den Angreifern weitgehend zu erschweren. Das Ziel von Sicherheitsprotokollen ist es, die Privatsphäre des Einzelnen vor unberechtigtem Zugriff zu schützen.
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ändig zu verstehen, sind nachfolgend, die damit verbundenen Sicherheitsprotokolle erklärt.
Zunächst sind hier einige grundlegende Begriffe wie Symetrische, Asymetrische und Hybride Verfahren erklärt. Anschliesend folgt eine ausführliche Erklärung des SSL2 /TLS3 Protokolls gefolgt von den Authentifikationsverfahren Plain, Login und Cram-MD5. Zum Schluss dieses Abschnittes folgt eine Erklärung des PGP Verfah- rens.
Symmetrische Verfahren
Symmetrische Verfahren[Wob01] sind kryptographische Algorithmen, die zum Entschlüsseln und Verschlüsseln den gleichen Schlüssel K verwenden. Solche Algorithmen sind unter anderem IDEA4 27, Blowfish6, Twofish54, DES17, TripleDES17 und der jüngste Algorithmus nennt sich AES2.
Eine Nachricht N ist mit symetrischen Verfahren wie folgt zu verschlüsseln. S = e(N, K) Wobei e die Verschlüsselungsmethode ist und S die Verschlüsselte Nachricht. Dementsprechend gilt folgendes.
N = e(S, K)
Die Verschlüsselungsmethode e mit dem Schlüssel K angewand auf die verschlüsselte Nachricht S ergibt wieder die ursprüngliche unverschlüsselte Nachricht N.
Wenn eine Person mit Hilfe eines der eben genannten Algorithmen und einem geheimen Schlüssel K eine Nachricht N verschlüsselt und diese über das Internet an einen Empfänger schickt, so braucht der Empfänger den gleichen geheimen Schlüssel K zum Entschlüsseln der empfangenen Nachricht. Aber wie bekommt der Empfänger den geheimen Schlüssel?
Beim Versenden des geheimen Schlüssels über das Internet, besteht die Gefahr, dass ihn ein böswilliger Dritter abfängt und ihn zu unrechtmässigen Zwecken missbraucht. Die einzig sichere Möglichkeit ist darin gegeben, den Schlüssel K persönlich zum Empfänger zu bringen. Es ist unschwer zu erkennen, dass bei diesem Verfahren der Schlüsselaustausch sehr problematisch ist.
Asymmetrische Verfahren
1975 veröffentlichten Diffie und Hellmann[Wob01] ihre Idee zur asymmetrischen Verschlüsselung, bei dem zwei verschiedene Schlüssel zum Ver- und Entschlüsselung zum Einsatz kommen.
Das Verfahren sieht vor, einen privaten und einen öffentlichen Schlüssel zu erzeu- gen. Der öffentliche Schlüssel darf der Öffentlichkeit zum download bereit stehen, z.B. auf der Homepage seines Besitzers. Mit diesem Schlüssel kann jeder Anwender Nachrichten verschlüsseln. Das Entschlüsseln funktioniert jedoch nur mit dem privaten Schlüssel, welchen der Besitzer geheim hält. Somit ist er der Einzige, der die verschlüsselten Nachrichten entschlüsseln kann.
Eine Nachricht N ist mit asymetrischen Verfahren wie folgt zu verschlüsseln. S = e(N, Kp) Wobei e wieder die Verschlüsselungsmethode ist, S die verschlüsselte Nachricht und Kp der öffentliche Schlüssel (public Key). Dementsprechend gilt für die Ent- schlüsselung
N = e(S, Ks)
Wobei Ks der geheime private Schlüssel (secret Key) ist.
Dieses Verfahren löst die Probleme der symmetrischen Verschlüsselung. Schlüssel können problemlos ausgetauscht werden, ohne sie persönlich überbringen zu müssen. Jedoch haben Asymmetrische Verfahren den erheblichen Nachteil, dass sie, aus mathematischen Gründen deren Erklärung hier den Rahmen sprengen würde, um den Faktor 100 langsamer sind als symmetrische Verfahren.
Hybride Verfahren
Hybride Verfahren[Wob01] sind Kombinationen aus der symmetrischen und asymmetrischen Verschlüsselung. 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öglich einen symmetrischen Schlüssel zu vereinbaren. Die Kommunikation der Nutzdaten ist dannach symmetrisch verschlüsselt. Auf diese Weise ist die Sicherheit der asymmetrischen Verfahren und die Schnelligkeit der symmetrischen Verfahren gegeben.
SSL52 (Secure Socket Layer) und TLS52 (Transport Socket Security) sind Verfah- ren mit dem zwei Rechner einen gemeinsamen symmetrischen Schlüssel und einen Verschlüsselungsalgorithmus bestimmen, den beide Teilnehmer beherschen. Solche Verschlüsselungsalgorithmen sind unter anderem IDEA27, Blowfish6, Twofish54,
DES17, TripleDES17 und AES2. Die zwei Rechner benutzen für die Dauer der aktuellen Sitzung den vereinbarten Schlüssel und Algorithmus um ihre Nachrich- ten zu ver- und entschlüsseln. Hört ein Dritter die Leitung ab, kann er aus dem verschlüsselten 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ätigen.
Geschichte des SSL/TLS
SSL52 wurde von der Firma Netscape entwickelt und 1994 in der Version 1.0 veröffentlicht. Die Firma war zu der Zeit Marktführer für Webbrowser. Das Pro- tokoll in der Version 1.0 wies jedoch Sicherheitslücken auf, woraufhin Netscape 1995 ihren neuen Netscape Comunicator 2.0 mit der nachgebesserten SSL Version 2.0 veröffentlichte.
Zur gleichen Zeit veröffentlichte die Firma Microsoft36 einen eigenen Webbrowser, den Internet Explorer 1.0, mit dem PCT52 1.0 (Private Communication Technology) Protokoll. Das PCT war die direkte Konkurrenz zu SSL und bot anfangs auch einige erhebliche Vorteile gegenüber diesem.
- PCT 1.0 kann mit weniger Nachrichten als SSL 2.0 einen Verschlüsselungs- algorithmus zwischen zwei Rechnern aushandeln und ist damit um einiges schneller.
- Es unterstützt mehr Verschlüsselungsalgorithmen als SSL 2.0.
- Zur Authentifikation und zur Verschlüsselung der Nutzdaten kommen zwei unterschiedliche Schlüssel zum Einsatz.
Das alles hat schließlich mit dazu beigetragen, dass Netscape Marktanteile an Microsoft36 verlor.
1999 veröffentlichte 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 Microsoft36 Was dazu führte, dass das IETF28 (Internet Engineering Task Force) SSL 3.0, mit einigen Änderungen, 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ößte Unterschied liegt im kryptographischen Algorithmus Fortezza, was ein nicht veröffentlichter Algorithmus der NSA5 39 ist, der in SSL bis zur Version 3.0 zum Einsatz kommt. Da niemand genau sagen kann, ob es nicht vielleicht eine Hintertür gibt, durch die der NSA39 den Code knacken kann, hat das IETF28 den Algorithmus bei TLS 1.0 nicht mit aufgenommen.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3.2: SSL/TLS Sicherheitsschicht
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3.3: SSL/TLS Schichtenmodell
Das Handshake Protokoll initialisiert die Verbindung zwischen zwei Rechnern. Der Rechner, der die Initialisierung beginnt, ist der Client, der anderer Rechner ist der Server. Das Change Cipherspec Protokoll bestimmt einen Verschlüsselungsalgo- rithmus, der von beiden Rechnern verwendet wird. Übertragungsfehler erkennt das Alert Protokoll. Das Application Data Protokoll gibt nur Auskunft darüber, was mit den von einem Anwenungsprotokoll empfangenen Daten geschehen soll. Das darunter liegende Record Protokoll, fragmentiert, komprimiert und verschlüsselt die Nutzdaten, um sie anschließend an die Transportschicht weiterzuleiten.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3.4: SSL/TLS Handshake
Mit der ClientHello Message zum Server beginnt der Client den Handshake. In dieser ersten Nachricht teilt er dem Server verschiedene Informationen über seine Fähigkeiten mit. Die Tabelle 3.2 zeigt die fünf Elemente, die in der ersten Nachricht enthalten sind.
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 3.2: Client Hello Message
Die Variable Session ID kann auch leer sein. Wenn der Client zu einem früheren Zeitpunkt schon ein Handshake mit dem Server durchführte, kann er hier die Session ID der alten Sitzung mitsenden. War die Sitzung wiederfortsetzbar (resumable), so kommt eine verkürzte Version des Handshake Protokolls zum Einsatz und die alte Sitzung kann wieder aufgenommen werden. Bei diesem Beispiel handelt es sich um einen erstmaligen Handshake, aufgrund dessen die Session ID leer ist und das vollständige Handshake Protokoll ausgeführt wird.
Die ServerHello Message ist aufgebaut wie die Client Hello Message, jedoch mit anderen Inhalten, basierend auf dem Client Hello. Tabelle 3.3 gibt die genaue Auf- listung wieder.
Client Version Die höchste SSL Version die beide Parteien versteht Random Zufallszahl die für Kryptographie benutzt wird Session ID Sitzungsbezeichner variabler Länge, der für die folgende Sitzung verwendet wird. Hat der Client keine Session ID geschickt, wird jetzt eine vom Server erzeugt.
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 3.3: Server Hello Message
Mit dem ServerCertificate schickt der Server dem Client sein Zertifikat und sei- nen öffentlichen Schlüssel. Das Server Certificate ist optional. Ist im Chipher Suites die RSA Verschlüsselung ausgewählt, so ist auch ein Server Certificate erforderlich. Ist jedoch ein Diffie-Hellmann Schlüsselaustausch ausgewählt, ist das Server Certi- ficate nicht notwendig.
Die ServerKeyExchange Message ist nur dann erforderlich wenn kein Server Certificate vorhanden ist. In diesem Fall hängt der Inhalt von dem Verschlüsselungsalgorithmus ab, der ausgewählt ist.
Das CertificateRequest verlangt vom Client ebenfalls ein Zertifikat. Da diese Nachricht jedoch optional ist, verschicken sie die meisten Server nicht.
Mit ServerHelloDone signalisiert der Server dem Client, dass jetzt keine weite- ren Nachrichten von ihm zu erwarten sind und dass er auf die Antwort des Clients wartet.
Das ClientCertificate ist optional und ist nur dann zu verschicken, wenn es der Server implizit verlangt. Doch wie schon erwähnt ist das meistens nicht der Fall.
In dem ClientKeyExchange schickt der Client dem Server Informationen über den symmetrischen Schlüssel. Der Inhalt hängt auch hier wieder von dem gewählten Verschlüsselungsalgorithmus ab.
Das CertificateVerify ist nur erforderlich, wenn der Server von Client ein Zertifikat verlangt. In diesem Fall kann der Client hier sein Zertifikat verifizieren.
Die ChangeChipherSpec und die Finished Nachricht verschickt der Client sofort hintereinander. In der Change Chipher Spec teil der Client dem Server die endgültig gewählten Algorithmen, Schlüssel und vereinbarten Geheimnisse mit. Die Finish Nachricht ist bereits mit den getroffenen Vereinbarungen codiert, der Server schickt die gleiche Nachricht wieder zurück und damit ist das handshake Protokoll beendet. Jetzt ist es möglich, Nutzdaten der Anwendungsschicht zu übertragen.
SSL/TLS Implementierungen
OpenSSL42 ist eine sehr gute Open Source Version des SSL/TLS Protokolls. Es setzt auf dem SSLeay-Paket von Eric A. Young und Tim Hudson auf und bietet viele zusätzliche Funktionen an zur Erzeugung und Verwaltung von Zertifikaten. Die offizielle Homepage des Projekts ist www.openssl.org42. Die Implementierung unterliegt allerdings nicht der GPL6.
Eine andere Open Source Implementierung ist gnuTLS26. Wie der Name schon vermuten lässt, steht diese Implementierung unter der GPL und darf ohne Ein- schränkungen von der Allgemeinheit benutzt werden. GnuTLS kommt unter an- derem in Software-Paketen wie Gnome7 24, Centericq8 8, Exim22, Mutt38 und Cups9 15 zum Einsatz. Die Projekthomepage ist zu finden unter www.gnu.org/- software/gnutls/26
Dieser Abschnitt gibt nur eine grobe Übersicht über Kryptographie. Wenn der Leser mehr über Kryptographie erfahren will, wird ihm das Buch “Secrets & Lies” [Sch04] von Bruce Schneier empfohlen.
Die Plain-Authentifikation nach RFC 2595 kommt zum Einsatz, wenn ein Server eine Authentifizierung verlangt. Der Server erwartet vom Client einen Base64-kodierten String, der aus drei Substrings besteht, die jeweils durch eine binäre Null von einander getrennt sind. Hier der logische Aufbau des Strings:
first<null>user<null>secret Der erste Substring ist für die Authentifikation unwichtig und ist meistens ein Nullstring. Der zweit Substring enthält den Benutzernamen und der dritte das geheime Passwort. Der Base64-kodierte String wird dem Server in einer einzigen Kommandozeile übergeben:
AUTH PLAIN CiRlc3YKZ2VoZTltCu==
Bei einer erfolgreichen Authentifikation antwortet der Server mit: 235 Authentication successful
Diese Art der Authentifikation ist nicht besonders sicher, da es ein Leichtes ist einen Base64-kodierten String in Klartext zurück zu kodieren. Plain-Authentifikation sollte aus Sicherheitsgründen immer durch SSL/TLS getunnelt werden.
Die Login-Authentifikation ist in keinem RFC beschrieben und daher auch kein Standard. Trotzdem ist dieses Verfahren in vielen Softwarepaketen implementiert, so z.B. in Exim und Sendmail. Benutzername und Passwort werden hier genau wie bei der Plain-Authentifikation in Base64 kodiert. Aus dem Grund ist auch dieses Verfahren nicht als sicher einzustufen und sollte nur in Kombination mit SSl/TLS zum Einsatz kommen.
Eine Login-Authentifikation zwischen Client und Server zeigt Listing 3.5
Listing 3.5: Login-Authentication
Abbildung in dieser Leseprobe nicht enthalten
Der Client meldet sich in der ersten Zeile beim Server und teilt ihm mit, dass er die Authentifikation über das Login-Verfahren abwickeln will. Der Server verlangt daraufhin das Passwort vom Client. Dieser schickt in Zeile drei das Base64 kodierte Passwort an den Server. Anschließend verlangt der Server den Benutzername, den der Client in Zeile sechs ebenfalls Base64 kodiert übers Netz schickt. In der letzten
Zeile meldet der Server, dass die Authentifikation erfolgreich abgeschlossen ist.
Dieses Verfahren bietet keine Vorteile gegenüber der Plain-Authentifikation, hat jedoch den Nachteil, dass der zeitliche Aufwand höher ist. Im Gegensatz zum letz- teren Verfahren sind bei diesem fünf statt nur einer Zeile für die Authentifikation nötig.
Bei dem Cram-MD5 Verfahren handelt es sich um eine sichere Methode der Authentifikation, da hier kein Passwort über das Netz geht. Sobald der Client dem Server mitteilt, dass er eine Cram-MD5 Authentifikation durchführen will, kriegt er von diesem einen Challenge-String zugeschickt, der wie folgt aufgebaut ist:
Abbildung in dieser Leseprobe nicht enthalten
Den Benutzernamen schickt der Client mit der Aufforderung zum Cram-MD5 Verfahren mit. Der erste Teil ist eine Prozess-ID gefolgt von einem Punkt und einem Zeitstempel. Der zweite Teil gibt den Rechnernamen der Servers an. Ein solcher String ist hier zu sehen.
Abbildung in dieser Leseprobe nicht enthalten
Elementar für das Verfahren ist der Zeitstempel. Der Client bildet über das Passwort des Benutzers und dem Zeitstempel des Servers ein MD5-Hashwert. Dieser Hashwert heisst MD5-Digest, welchen der Client an den Server schickt. Der Server berechnet seinerseits sein MD5-Digest mit Hilfe seiner Passworttabelle und vergleicht sein Ergebnis mit dem empfangenen Wert vom Client. Die Authentifikation ist erfolgreich, wenn beide Digest übereinstimmen.
Dieses Verfahren ist wesentlich sicherer als Plain und Login und ist unbedingt zu empfehlen, vor allem, wenn kein sicherer SSL/TLS-Tunnel zur Verfügung steht.
PGP (Pretty Good Privacy) ist ein hybrides Verschlüsselungssystem, das Phil Zimmermann[Zim99] 1991 veröffentlichte. Es basiert auf der Idee der öffentlichen und geheimen Schlüssel von Diffie und Hellmann[Wob01]. PGP ist so erfolgreich das es Heute das am meist verbreitete E-Mail Verschlüsselungssystem der Welt ist. Bei diesem System sind folgende Ziele sichergestellt:
[...]
1 Request for Comments oder RFCs sind eine Reihe von Dokumenten die den technischen und organisatorischen Aufbau des Internets beschreiben.
1 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 Kommuni- kationsmöglichkeit an, welches dazu benutzt wird Benutzern über die Kommandozeile Zugang zu Internetrechnern zu bieten.
2 Secure Socket Layer
3 Transport Socket Security
4 IDEA (International Data Encryption Algorithm) ist ein symetrischer Algorithmus der 1990 entwickelt wurde.
5 Die National Security Agency (NSA) ist der grösste Geheimdienst der Erde und eine Unterabteilung des Pentagon (Verteidigungsministerium) der USA (United Sates of America).
6 GNU General Public License
7 Gnome ist eine Desktop-Umgebung für Unix-Systeme, die unter der GPL steht.
8 Centericq ist ein ICQ-Kommandozeilen-Client.
9 CUPS (Common Unix Printing System), ist ein Softwarepacket, welches das Drucken unter den verschiedenen Linux und UNIX Betriebssystemen steuert.
