E-Mail-Provider im Praxistest: Verschlüsselung oft mangelhaft

Anfang September erregte ein privater Blog einiges Aufsehen. Dort war zu lesen, dass der Mobilfunkprovider O2 die E-Mail-Verschlüsselung für seine UMTS-Kunden abgeschaltet habe. O2 gab zu, einen Fehler gemacht zu haben, und schaltete die Verschlüsselung wieder auf.

Oft glauben Anwender, wenn sie in ihrem E-Mail-Client Verschlüsselung aktiviert haben, dass die Übertragung sicher ist. Allerdings bedeutet die verschlüsselte Kommunikation zwischen einem E-Mail-Client und seinem Server nicht, dass die E-Mail auch tatsächlich verschlüsselt durch das Internet gesendet wird.

Anders als das World Wide Web ist E-Mail kein transaktionsorientierter Dienst mit einer direkten Verbindung zwischen Sender und Empfänger, sondern ein sogenannter Store-and-forward-Dienst, bei dem eine E-Mail immer wieder an verschiedene E-Mail-Server weitergereicht werden kann, bis sie letztendlich die Mailbox des Empfängers erreicht.

Verschlüsselt wird eine E-Mail immer dann übertragen, wenn zwei SMTP-Server, die an der Übertragung beteiligt sind, die Verschlüsselung unterstützen und aushandeln. Dabei gibt es zwei verschiedene Verfahren.

Zunächst führte man zur Verschlüsselung von SMTP-Verbindung das SMTPS-Verfahren ein. Dabei wird die Verbindung analog zu HTTP und HTTPS durch SSL/TLS getunnelt. Ein SSL/TLS-Tunneling kann man mit jeder TCP-Verbindung leicht durchführen. Alte Programme, die diese Technik nicht beherrschen, lassen sich mit einem Program wie stunnel nachrüsten. Voraussetzung für dieses Verfahren ist jedoch, dass SMTPS auf einem anderen Port als dem Standard-Port 25 abgewickelt wird. Dafür hatte die IANA den Port 465 vorgesehen.

Es ergaben sich praktische Probleme. Um herauszufinden, an welchen Server ein SMTP-Server E-Mail für eine bestimmte Domain ausliefern kann, fragt er per DNS die sogenannten MX-Records ab. Das ist ein sehr altes Verfahren. Die MX-Records enthalten einen oder mehrere Server und eine Priorität, die die Reihenfolge angibt, in der der Versender die einzelnen Server durchprobieren soll, falls einer der Server nicht erreichbar ist. Allerdings enthalten MX-Records keine Portnummern, so dass für E-Mail immer die Standard-Ports 25 und 465 verwendet werden müssen, siehe Bild 2.

Ein SMTP-Server, der an einen Empfänger verschlüsselt ausliefern will, muss also zunächst Port 465 ausprobieren. Wenn dort keine Verbindung angenommen wird oder ein anderer Dienst läuft, muss er es unverschlüsselt über Port 25 versuchen.

Viele Firewalls schlucken beim "Ausprobieren" von Ports die Antwort des Servers, dass auf diesem Port kein Dienst läuft, um Portscans zu erschweren. Das führt dazu, dass SMTP-Server oft lange auf Time-outs warten mussten, was natürlich Verzögerungen verursacht. Das Versenden von E-Mail über den verschlüsselten Port 465 setzte sich also nicht durch.

Stattdessen wurde das STARTTLS-Verfahren entwickelt. Dabei wird die Verbindung immer auf Port 25 aufgebaut. Im Rahmen des ESMTP-Handshake teilt der Server dem Client mit, dass er STARTTLS beherrscht. Danach baut er eine zweite TCP-Verbindung mit SSL/TLS auf demselben Port auf.

Oft spricht man bei der Verschlüsselung durch einen SSL/TLS-Tunnel auf einem anderen Port von SSL-Verschlüsselung und bei der Anwendung von STARTTLS von TLS-Verschlüsselung, was allerdings nicht korrekt ist. Das zunächst proprietäre SSL wurde bei seiner Standardisierung in TLS umbenannt.

E-Mail-Clients, die sich wahlweise mit SSL- oder TLS-Verschlüsselung konfigurieren lassen, meinen dabei, ob der SSL/TLS-Verbindungsaufbau über einen getrennten Port (Einstellung SSL) oder das STARTTLS-Verfahren auf demselben Port vorgenommen werden soll (Einstellung TLS).