Seite 2: IMAP über TLS

Inhaltsverzeichnis

IMAP über TLS

Auch weniger paranoide Systemadministratoren sollte es bedenklich stimmen, wenn alle fünf bis zehn Minuten die Paßwörter sämtlicher Mitarbeiter im Klartext durchs Netz schwirren. Genau das passiert, wenn ein Mail-Programm sich regelmäßig beim POP-Server anmeldet, um auf neue Mail zu prüfen. Einfache Netzwerkscanner, die diese Paßwörter mitschneiden können, sind mittlerweile auf jedem Windows-PC auch von Laien zu installieren. Sogar die Mail-Inhalte können so während der Übertragung vom Server zum Client abgelauscht werden.

Einige wenige Mail-Programme bringen zumindest die Möglichkeit zur verschlüsselten Authentifizierung von Haus aus mit. Eudora beherrscht zum Beispiel APOP, ein optionales POP3-Kommando, bei dem das Paßwort mit RSA-MD5-Verschlüsselung übertragen wird, sowie KPOP (POP mit Kerberos-Authentifizierung). Andere Clients wie Netscape lassen sich durch Tricks - Konfiguaration von Movemail mit einem Kerberos-fähigen externen Mail-Transfer-Programm (kpopclient) - zu solchen Kunststücken überreden.

Allerdings setzt all das ein funktionierendes Kerberos-Authentifizierungssystem und POP-Server voraus, die hierbei mitspielen. Herausforderungen, die nicht wenig trivial und zeitaufwendig sind, von der entsprechenden Einrichtung einiger hundert Arbeitsplatzrechner einmal abgesehen. Und die Mail-Inhalte gehen davon unbenommen nach wie vor unverschlüsselt übers Netz.

Erheblich einfacher sichert man die EMail-Leser mit einem IMAP-Server. Mit relativ geringem Aufwand kann man eine Lösung ins Werk setzen, die sowohl die Authentifizierung als auch die Übertragung der EMail selbst mittels der zunehmend verbreiteten TLS-Verschlüsselung (Transport Layer Security - früher SSL) vornimmt. Voraussetzung ist allerdings, daß die Mail-Clients dieses Protokoll beherrschen. Bei Netscape 4.x und MS Outlook Express sowie MS Outlook 98 ist dies der Fall.

Das Funktionsprinzip basiert auf einem anstelle des imapd-Prozesses per inetd gestarteten Mini-TLS-Proxy. Dieser übernimmt einerseits die TLS-Kommunikation mit der TLS-Schicht des Mail-Client, andererseits leitet er die IMAP-Kommunikation zwischen IMAP-Server und Client weiter.

Es gibt verschiedene freie Implementierungen dieser simplen TLS-Proxies im Internet, die allesamt auf SSLeay basieren. Ich habe mich für sslwrap von Rick Kaseguma entschieden, weil mir diese Variante am besten konfigurierbar erschien.

Zunächst muß SSLeay als auch für den kommerziellen Einsatz frei verfügbare SSLv2/v3/TLSv1-Implementierung installiert werden. Mit den so erzeugten Bibliotheken libssl.a und libcrypto.a kompiliert man sslwrap.

Nun fehlt noch ein selbstsigniertes Zertifikat. Dank SSLeay ist es nicht nötig, hierfür eine CA (Certification Authority) zu bemühen, außerdem darf das Zertifikat nicht verschlüsselt werden, da der inetd, der sslwrap startet, schlecht eine Passphrase für den privaten Serverschlüssel eingeben kann.

Ein derart gestaltetes Zertifikat erhält man folgendermaßen:

cd /usr/local/ssl/certs
/usr/local/ssl/bin/req \
-new -x509 -nodes -out imapd.pem \
-keyout imapd.pem -days 365
`/usr/local/ssl/bin/x509 -noout -hash <
imapd.pem`.0

imapd.pem sollte mit den Rechten 0600 für den User cyrus ausgestattet werden, damit niemand sonst Zugriff auf das Zertifikat hat.

IMAP über TLS/SSL benutzt den TCP-Port 993, deshalb ergänzt man /etc/services um:

imaps 993/tcp # IMAP over TLS

Die Konfigurationsdatei (inetd.conf) des inetd-Daemon wird um die folgende Zeile erweitert:

imaps   stream  tcp     nowait  cyrus  \ 
 /usr/local/sbin/sslwrap sslwrap -cert \ 
 /usr/local/ssl/certs/imapd.pem -port 143

Nach einem Neustart des inetd (kill -HUP ‘PID des inetd’) kann die Geheimniskrämerei beginnen.

Mit dem gleichen Mechanismus ließe sich auch das POP3-Protokoll verschlüsseln, allerdings wird POP3 über TLS nur von sehr wenigen Mail-Clients unterstützt. Microsofts Outlook Express und Outlook 98 machen hier eine rühmliche Ausnahme.

Natürlich muß für einen sinnvollen Betrieb des IMAP-Servers mit TLS-Verschlüsselung etwas Rechenleistung geboten werden, denn vor jedem Start eines imapd-Prozesses wird ein Session-Key berechnet.

Meine ersten Versuche mit einer alten SPARC 2 ergaben beim Start einer verschlüsselten IMAP-Verbindung Wartezeiten von 30 bis 45 Sekunden. In Erwägung des Client-Verhaltens von zum Beispiel Netscape, der bei jeder Selektion eines Folders eine Verbindung aufbaut, ist so kein sinnvolles Arbeiten möglich. Ein PC mit 400 MHz Pentium II hingegen lieferte die benötigten Session-Keys hinreichend zügig aus. (js)