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

Viele Mail-Anbieter nehmen E-Mails ihrer Kunden verschlüsselt an. Zum Empfänger geht es häufig unverschlüsselt weiter. ZDNet testet die großen Anbieter und zeigt, wer mit den anvertrauten Mails verantwortungsvoll umgeht und wer nicht.

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).

Themenseiten: Big Data, Datenschutz, Security-Praxis

Fanden Sie diesen Artikel nützlich?
Content Loading ...
Whitepaper

ZDNet für mobile Geräte
ZDNet-App für Android herunterladen Lesen Sie ZDNet-Artikel in Google Currents ZDNet-App für iOS

Artikel empfehlen:

Neueste Kommentare 

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

Kommentar hinzufügen
  • Am 24. Oktober 2008 um 16:39 von Beat Weber

    TLS-fähige Mailserver .ch und .li
    In einer Studie 2004 wurden im Rahmen einer wissenschaftlichen Arbeit alle Mailserver mit .ch und .li gescannt (471’000 aktive Domänen).
    Dabei handelte es sich um 33’000 physikalische Maschinen.
    Davon waren gerade mal 5’570 TLS-fähig, von denen hatten ganze 2’510 ein Server-Zertifikat installiert.
    Von diesen waren 117 (einhundertsiebzehn !) Zertifikate von einer vertrauenswürdigen CA ausgestellt. Dies entspricht gerade mal 0.04 Promille aller Mailserver.

    Diese Erkenntnisse waren sehr bedenklich – sie lassen darauf schliessen, dass im Backbone-Bereich eine Verschlüsselung praktisch nicht stattfindet.

    In der Zwischenzeit gibt es sicher viel mehr Server – doch die Anzahl der TLS-fähigen wird wohl immer noch im Promille-Bereich liegen.

    siehe auch: http://security.hsr.ch/docs/IW18_KH_EMAIL.pdf

    Daraus sieht man, es ist absolut notwendig, aktiv für die Sicherheit seiner Mails besorgt zu sein.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *