Abbildung 1: TLS fügt eine kryptographische Schicht zwischen TCP und der Applikation ein. Es besteht selbst aus mehreren Teilprotokollen.

Zwischen TCP und der Applikation angesiedelt bietet das TLS-Protokoll Sicherheit während der Datenübertragung. Beim Einsatz für SMTP stößt TLS aber an Grenzen.

Die meisten Internet-Nutzer setzen TLS ein und wissen es gar nicht. Hinter den »https://«-URLs steckt das Transport- Layer-Security-Protokoll (TLS)[1] oder sein Vorgänger SSL (Secure Sockets Layer), der ursprünglich von Netscape stammt. Durch Netscape klärt sich der Bezug von SSL/TLS zum Web, aber das wird den Protokollen nicht gerecht: Sie sind universell einsetzbar.

TLS fügt zwischen TCP und der Anwendung eine weitere Protokollschicht ein (Abbildung 1). Für die Anwendung sieht sie aus wie TCP, leistet aber mehr. Sie …

• sorgt für die Vertraulichkeit der Daten (Verschlüsselung),
• authentifiziert den Server (einseitig) oder Client und Server gegenseitig,
• stellt die Integrität der Daten sicher.

Von diesen Ergänzungen muss die Applikation nichts wissen, man kann ihr TLS unterschieben. Das klappt zum Beispiel mit dem universellen SSL-Wrapper Stunnel[3] oder mit Hilfe von »LD_PRELOAD« und Libsslwrap[4]. Der bessere Weg zur TLS-fähigen Applikation ist, das Protokoll direkt einzubinden und dem Benutzer die Kontrolle über die Sicherheitsparameter zu geben.

TLS ist selbst aus mehreren Teilprotokollen aufgebaut (siehe Abbildung 1). Die Basis ist das TLS Record Protocol. Es zerteilt die Daten in handliche Pakete (Fragmentierung), führt die Verschlüsselung durch und stellt die Integrität der Daten sicher. In dieser Schicht ist auch eine Kompression möglich: Verschlüsselte Daten sind nicht mehr komprimierbar, daher muss dies vor der Verschlüsselung stattfinden.

Über dem Record Protocol sind zwei weitere Protokolle angesiedelt: Das Applikations-Protokoll und das TLS Handshake Protocol. Letzteres besteht wiederum aus drei Teilprotokollen:

• Das Alert Protocol gibt Fehlermeldungen innerhalb der TLS-Schicht weiter.
• Das Handshake Protocol handelt Sicherheitsparameter aus.
• Das Change Cipher Spec Protocol schaltet auf die neuen Sicherheitsparameter um.

Abbildung 1: TLS fügt eine kryptographische Schicht zwischen TCP und der Applikation ein. Es besteht selbst aus mehreren Teilprotokollen.

Verbindunsaufbau bei TLS

Abbildung 2 zeigt den Ablauf beim Start der Verbindung. Zunächst wissen beide Seiten noch nichts über ihr Gegenüber und können daher auch noch nicht verschlüsselt kommunizieren. Erst nach der Handshake-Phase schalten sie mit den »ChangeCipherSpec«-Paketen auf eine verschlüsselte Verbindung um.

Zu den Aufgaben des Handshake-Protokolls gehört die Authentifikation. Dazu benutzt es X.509-Zertifikate, die es mit überträgt. Das Protokoll legt auch fest, welche kryptographischen Algorithmen zum Einsatz kommen und aus welchen Zufallswerten der Sitzungsschlüssel berechnet wird.

Zertifikate sind vereinfacht gesagt eine Verknüpfung des öffentlichen Schlüssels mit dem Namen ihres Besitzers. Diesen Zusammenhang bestätigt ein vertrauenswürdiger Dritter, bei X.509 eine Certification Authority (CA). Neben dem Namen eines Benutzers oder eines Rechners (DNS-Name) enthalten die Zertifikate weitere Informationen, etwa die Gültigkeitsdauer.

Bei der Authentifizierung des Servers prüft ein TLS-Client folgende Fragen:

• Ist das Zertifikat derzeit gültig?
• Ist die CA vertrauenswürdig? (Vergleich mit eigener Liste)
• Ist die Signatur des Zertifikats gültig? (Prüfung mit dem öffentlichen Schlüssel der CA)
• Stimmt der Domain-Name aus dem Zertifikat mit dem gewünschten Rechner überein?
• Kann sich der Server mit seinem privaten Schlüssel authentifizieren?

Bevor irgendein TLS-Paket über die Leitung geht, müssen sich Client und Server einig sein, dass sie überhaupt TLS einsetzen. Der einfachste Ansatz ist, eigene Ports für die geschützten Dienste zu verwenden. Während HTTP Port 80 nutzt, setzt das Gespann aus TLS und HTTP auf Port 443, dieser Port trägt den Namen HTTPS. Ähnliches gilt für IMAP (Port 143) und IMAPS (Port 993) sowie POP3 (110) und POP3S (995).

Abbildung 2: Nach dem Aufbau der Verbindung (1) senden Server (2) und Client (3) Zertifikate. Nach der Authentifikation und dem Change-Cipher-Spec (3 und 4) werden die Applikationsdaten verschlüsselt übertragen (5).

Mit STARTTLS auf TLS umschalten

TLS lässt sich auch ohne einen zusätzlichen Port einbinden. Um zu nicht-TLS-fähigen Clients kompatibel zu bleiben, startet SMTP zunächst mit einer normalen Verbindung über TCP. Wenn ein ESMTP-Server TLS unterstützt, sagt er dies dem Client in seiner EHLO-Nachricht, das Schlüsselwort ist STARTTLS[5]. Kann auch der Client TLS, setzt er ein STARTTLS-Kommando ab und Client und Server schalten auf TLS-Betrieb um. Dieses Umschalten ist nicht trivial, weil beide Seiten während der Verbindung eine weitere Protokollschicht einfügen müssen, während das SMTP-Protokoll weiter abläuft.

STARTTLS ist auch für andere Protokolle wie IMAP oder POP3 definiert. Dort kann TLS seine Vorteile ausspielen: Wenn es der User wünscht, sichert TLS die Datenübertragung von Ende zu Ende und authentifiziert Client und Server. Nach ihrer Zustellung liegen die Mails wieder in der Ursprungsform vor. TLS ist daher kein Ersatz für PGP, GnuPG oder S/MIME, die E-Mails direkt in der Applikation verschlüsseln und nicht nur während der Übertragung.

Grenzen von STARTTLS im SMTP-Protokoll

Bei SMTP ergeben sich einige Probleme, die mit der Architektur des Mail-Systems zusammenhängen. Bei SMTP gibt es keine Ende-zu-Ende-Verbindung zwischen Absender und Empfänger einer E-Mail, die Nachrichten werden stattdessen in einem oder mehreren MTAs zwischengespeichert. Die einzelnen Abschnitte der Übertragung kann TLS zwar absichern, ein MUA oder MTA kann aber nicht wissen, ob später folgende Abschnitte TLS nutzen oder nicht.

Die Authentifizierung ist bei SMTP nur bedingt sinnvoll: Ein Client kann zwar prüfen, ob der Server authentisch ist. Die Information, welchen Server er überhaupt ansprechen soll, stammt aber aus dem (unsicheren) DNS und nicht vom Benutzer. Ein manipulierter MX-Record kann eine Mail umleiten und der falsche Server kann sich mit seinem eigenen Zertifikat ausweisen – er wurde ja unter seinem richtigen Namen angesprochen, er ist nur nicht zuständig.

Diese Problem lässt sich nur umgehen, indem man für Empfänger, die E-Mails über verschlüsseltes SMTP erhalten sollen, den MX-Lookup vermeidet und die Zustellung fest konfiguriert.

Damit enden die Probleme noch nicht: Bevor sie auf TLS umschalten, kommunizieren Client und Server über TCP. Diesen Teil der Verbindung kann ein Angreifer beliebig manipulieren, zum Beispiel kann er das STARTTLS-Schlüsselwort aus der EHLO-Meldung entfernen. Der Client weiß dann nicht, dass der Server TLS unterstützt. Aus Kompatibilitätsgründen werden beide ohne TLS weitermachen. RFC 2487[5] fordert sogar, dass ein öffentlich zugänglicher SMTP-Server nicht auf der Benutzung von STARTTLS bestehen darf.

In einer kontrollierten Umgebung kann STARTTLS einen hohen Schutz bieten, wenn alle beteiligten MTAs auf die MX-Lookups verzichten und E-Mails nur dann weiterleiten, wenn die Verbindung mit TLS abgesichert ist. Ohne diese Maßnahmen bietet STARTTLS immerhin Schutz vor passiven Angreifern, die nur das Netz belauschen, aber keine Pakete manipulieren.