Die sichere Übertragung elektronischer Post über TLS ersetzt zwar nicht die individuelle Verschlüsselung einzelner Mails. Doch obwohl moderne Mail-Programme auch ersteres können, machen sie es ihren Anwender(inne)n unnötig schwer, dieses Mehr an Privatsphäre zu nutzen.

E-Mails sind wie Postkarten – jeder “Briefträger” kann sie lesen. Zwar tun die meisten Admins einen Teufel, sich an privater Post anderer zu ergötzen, doch prinzipiell haben zumindest die berechtigten und unberechtigten (sprich: Hacker) root-Passwort-Inhaber jeder Maschine, über die eine Mail geht oder auf der sie permanent lagert, Zugang. Geheimdienste aller Couleur bedanken sich ohnehin für die Tatsache, dass die Väter und Mütter des Internets so vertrauensselig waren, jeglichen Datenverkehr im Klartext durch’s Netz zu schicken.

Was in der realen Welt der Briefumschlag ist, heißt in der virtuellen Welt der elektronischen Post Verschlüsselung, z. B. mit GnuPG und PGP [1,2]. Doch hier gibt es ein Problem: Sobald ein Staat – meist mit dem Hinweis auf das Ziel Verbrechensbekämpfung – seinen Bürgern sichere Verschlüsselungsmethoden verbietet, spielt das Mail-Transport-Protokoll SMTP (Simple Mail Transfer Protocol) den Denunzianten: Zwar können den Netzverkehr Mitlauschende den Inhalt einer PGP- oder GnuPG-verschlüsselten Mail nicht lesen. Aber sie sehen, welche Mail verschlüsselt ist und welche nicht. Mit dem handfesten Beweis, dass jemand starke Verschlüsselung benutzt, lassen sich so all jene Gesetzesbrecher überführen, die Privatsphäre für ihre Mails einfordern.

Um dieser gläsernen Welt keinen Vorschub zu leisten, gehen immer mehr Betreiber von Mailservern dazu über, Mail nicht mehr im Klartext auszutauschen, sondern das SMTP-Protokoll innerhalb eines verschlüsselten “Tunnels” namens TLS (Transport Layer Security) gegen Mitlauscher abgeschirmt zu sprechen. Doch es gibt auch wesentlich weniger idealistische Gründe, diesem Trend weg von der Klartext-Übertragung zu folgen, für den der Einsatz von SSH anstelle des Protokoll-Veteranen Telnet oder auch die https-URLs von Web-Seiten, die persönliche Daten abfragen, weitere Beispiele sind.

So bringt es vielerlei Probleme mit sich, allen Mitarbeiter(inne)n einer über verschiedene Standorte verteilten Firma das Verschlüsseln ihrer E-Mails vorzuschreiben: Was passiert, wenn an einer Kommunikation nicht beteiligte Dritte im Nachhinein Zugriff auf Mails bekommen sollen? Was geschieht mit den Schlüsseln ausscheidender Kolleg(inn)en und deren verschlüsselter geschäftlicher Korrespondenz? Da es hier oft “nur” darum geht, Firmeninterna nicht im Klartext über’s Netz zu schicken, setzt man gern auf die Server-seitige und für die Anwender/innen vollkommen transparente Lösung SMTP/TLS.

Geheimabsprache

Sie hat zudem den Vorteil, dass sich nach einer initialen Konfiguration des Servers niemand mehr darum kümmern muss: “Sprechen” ein Mailclient und ein Mailserver beide TLS, einigen sie sich von alleine auf die sichere Übertragung. Dazu tauschen die beiden Rechner bei der Begrüßung, dem Handshake, Zertifikate aus, mit denen sie sich voreinander authentifizieren. Sie zeigen sich sozusagen die Personalausweise. Im Mail-Verkehr ist es aus pragmatischen Gründen in der Regel so, dass sich nur der die Mail entgegennehmende Server gegenüber dem Client ausweist. Ob der Client ein anderer Mailserver ist, der Nachrichten weiterleiten will, oder das Mail-Programm eines Users, ist dabei gleichgültig. Nun, da der Client dem Server vertrauen kann, einigen sich beide auf einen Verschlüsselungsalgorithmus und die geheimen Verschlüsselungsschlüssel, mit der sie den nachfolgenden Datenverkehr für Außenstehende unlesbar machen.

Dass Menschen Personalausweisen glauben, liegt daran, dass sie der ausstellenden Behörde vertrauen. Genauso akzeptiert der Mailclient das Zertifikat eines Servers nur dann, wenn er davon überzeugt ist, dass der Aussteller selbiges nach bestem Wissen und Gewissen ausgeschrieben hat. Jener bezeugt die Echtheit des Zertifikats dadurch, dass er es mit seinem eigenen Zertifikat unterschreibt, welches wiederum von einer höheren Vertrauensinstanz beglaubigt sein kann.

Damit der Client überhaupt vertrauen kann, muss er zumindest die Zertifikate der höchsten Vertrauensinstanzen kennen, die Root-Zertifikate.

Gewusst wie

Während Mailserver (“Mail Transfer Agents”) wie Postfix oder Sendmail tatsächlich automatisch TLS verwenden, wenn beide Partner es können, schreiben die Entwickler gängiger Mail-Programme (“Mail User Agents”) Benutzerunfreundlichkeit in diesem Zusammenhang groß: Statt “SMTP/TLS wenn möglich” von sich aus sofort verwendbar vorzukonfigurieren, erwarten sie, dass die Anwenderin sich eingehend mit der Materie beschäftigt, um dann zu suchen, wie sie dem Programm diese sinnvolle Voreinstellung beibringt.

Abbildung 1: KMail überlässt es dem User zu testen, ob ein Mailserver TLS kann

Wer bei KMail aus KDE 3.x via Einstellungen / KMail einrichten… im Reiter Versand des Punktes Netzwerk ein neues “Ausgangspostfach” mit der Versandart SMTP anlegt oder ein bereits bestehendes verändert, muss im nun erscheinenden Dialog die Karteikarte Sicherheit anwählen (Abbildung 1). Hier gibt es immerhin die Möglichkeit, den in der Karte Allgemein eingetragenen Smarthost mit dem Button Fähigkeiten des Servers testen auf seine Verschlüsselungswilligkeit zu prüfen. Nach einer positiven Antwort (bei der Alternative SSL (“Secure Socket Layer”) handelt es sich um den Vorgänger von TLS) bedarf es noch eines Klicks auf OK, damit sich KMail auf verschlüsselte Übertragung einlässt.

Abbildung 2: Warum nicht per Default so?

Evolution bietet zwar bereits in Version 1.0.x die Möglichkeit, für den Smarthost eine sichere Verbindung via SSL einzurichten. Doch das Ankreuzen von Sichere Verbindung (SSL) verwenden erweist sich allzu leicht als Falle: Die meisten Server unterstützen die veraltete Methode SMTP über SSL nicht – Evolution 1.0.x wiederum spricht kein TLS. Will man in dieser Konstellation Mail abliefern, weigert sich das Mail-Programm mit der vielsagenden Fehlermeldung Verbindung zu name.des.mailservers (Port 465) konnte nicht hergestellt werden. Die Verbindung wurde vom Kommunikationspartner zurückgesetzt. Es versucht dann nicht einmal, die Mail unverschlüsselt abzuliefern, solange man das vermaledeite Häkchen im Mail-Einstellungen-Dialog nicht wieder entfernt.

Version 1.2 behebt beide Probleme, auch wenn der Eintrag Sichere Verbindung (SSL) verwenden im Wizard oder im Konfigurationsdialog (Abbildung 2) weiterhin nur auf SSL, nicht aber auf das jetzt ebenfalls unterstützte TLS verweist. Warum der an dieser Stelle wählbare Wert Immer, wenn möglich nicht die Voreinstellung ist, steht allerdings in den Sternen.

Beim ersten Versuch, eine Mail auf verschlüsseltem Weg abzuliefern, zeigt Evolution Informationen zum Zertifikat des Servers an und bittet den User, es zu akzeptieren oder auf den SSL/TLS-Tunnel zu verzichten (Abbildung 3). Da das Programm jedoch keinerlei Entscheidungshilfe bietet (“Was bedeutet ist, wenn eine Signatur SCHLECHT ist?”), sollte es die Entscheidung besser selbst treffen, als bei der Anwenderin für Verunsicherung zu sorgen.

Abbildung 3: Trauen Sie diesem Zertifikat?

Das Kommandozeilenprogramm mutt fällt da schon fast positiv auf: Da es ausgehende Mail grundsätzlich einem lokalen Mailserver über die /usr/sbin/sendmail-Schnittstelle überträgt, braucht es SMTP/TLS selbst gar nicht unterstützen. Den Weg ins Netz nimmt die Nachricht immer dann über einen sicheren Tunnel, wenn der lokale Mail Transfer Agent und der Zielserver einen aufbauen können; die Anwenderin muss sich gar nicht darum kümmern. Auf dem eigenen Rechner kommt sie jedoch nicht umhin, dem lokalen Mailserver die entsprechende Fähigkeit beizubringen …