Startseite  

Zum Inhalt  

Aktualisierungen  

  Zum Autor  

 

Impressum  

DSB-MIT-SYSTEM®  

 

 

 

Das bewährte Praxishandbuch
im Rahmen von DSB-MIT-SYSTEM®

 

E-Mail Transport mit TLS verschlüsseln

Im TOM-Guide® (Juli 2014) wurde berichtet, dass die E-Mail Kommunikation auf dem Transportweg zwischen E-Mail Servern verschlüsselt werden kann. Hier wird beschrieben, wie man prüfen kann, ob ein E-Mail Server TLS "versteht". Eine Beschreibung, wie man TLS auf einem Server aktiviert, findet sich hier.

Aktualisiert im April 2019.

1.) Informationsquellen
    1.1) Kann TLS unterwegs belauscht werden?
    1.2 Wie kann man TLS-verschlüsselte E-Mails nachweisen?
2.) TLS beim Senden
3.) TLS beim Empfangen
4.) Sonstige Kontrollmöglichkeiten
5.) Weiterführende Links

1.) Informationsquellen

Die Transportverschlüsselung von E-Mails ist nicht zuletzt angesichts der NSA-Enthüllungen ein wichtiges Thema geworden. Die Zeitschrift c't hat beispielsweise im Heft 09/2014 Seite 30 darauf hingewiesen.

Ergänzend zum TOM-Guide® seien hier zusätzliche Infos zu TLS im SMTP-Protokoll genannt:

Das Thema ist wirklich außerordentlich komplex. Die folgenden Ausführungen beziehen sich darauf, wie man eine TLS-Verschlüsselung beim Senden und Empfangen von E-Mails prüfen kann.

1.1) Kann TLS unterwegs belauscht werden?

(Überarbeitet am 08.05.2019): Wie sich herausgestellt hat, so gibt es scheinbar verschiedene Meinungen zu diesem Thema. Das Problem löst sich auf, sobald man sich Folgendes klar macht:

  • Es gibt eine "Ende-zu-Ende"-Verschlüsselung, die vom persönlichen Computer des Absender zum persönlichen Computer des Empfängers funktioniert. Dies ist beispielsweise S/MIME oder PGP. In diesem Fall kann kein anderer Mensch jemals auf die Inhalte der E-Mails zugreifen. Dies kann TLS nicht leisten.
     
  • Es gibt eine "Punkt-zu-Punkt"-Verschlüsselung, die vom E-Mail-Server des Absenders (z.B. mail.de zum E-Mail-Server des Empfängers (z.B. gmx.de) funktioniert. Auf dem Weg zwischen diesen beiden Servern befinden sich nur "dumme" Router (z.B. in den USA) und Glasfaserkabel. Auf diesem Transportweg können die Administratoren und Geheimdienste nicht auf die Daten zugreifen. Dies kann TLS leisten.

Daraus folgt:

  1. Wenn man also den beiden E-Mail-Provider vertraut, dann kann man auch vertrauliche Inhalte per E-Mail austauschen, indem man im Hintergrund per TLS verschlüsseln lässt. Hierfür müssen Absender und Empfänger nichts konkretes tun (außer z.B. mittels www.checktls.com prüfen, ob die beiden beteiligten E-Mail-Provider prinzipiell per TLS kommunizieren können).
     
  2. Wenn man niemandem vertraut, dann sollte man jede einzelne E-Mail verschlüsseln, bevor sie den persönlichen Computer verlässt (z.B. mit S/MIME oder PGP oder ZIP-Anhang-Verschlüsselung). Hier besteht die Herausforderung u.a. darin, dass man sicherstellen muss, dass man das Passwort vertraulich übermittelt und die andere Person generell zuverlässig identifiziert. (Von den rein technischen Herausforderungen mal ganz abgesehen, denn der Umgang mit PGP und S/MIME ist nicht trivial.)

Soweit die Fakten.

Aber nun gibt es aber einzelne Berichte darüber, dass TLS unsicher sei, weil die E-Mails in einer Kette von E-Mail-Severn immer wieder ent- und verschlüsselt werden. Siehe hier, hier, hier und in der Fachzeitschrift DuD 02/2019. Dies bezieht sich auf den Sachverhalt, dass eine E-Mail im Internet über eine ganze Kette von Servern transportiert wird, bis sie endlich beim Empfänger (-Server) ankommt.

... das stimmt in gewisser Weise. Doch um welche E-Mail-Server handelt es sich da? Es sind keineswegs "irgendwelche" Server in den USA, die zwischendurch entschlüsseln. Nein, es handelt sich um diverse Server die seitens der E-Mai-Provider eingeschaltet werden ("Serviceorientierten Strukturen"). Manchmal wird eine E-Mail hausintern über verschiedene Server geleitet (z.B. Anti-SPAM-Server oder Archvierungs-Server), bis sie dann endlich "das Haus" verlässt und das öffentliche Internet betritt. In dieser "internen" Server-Kette könnte eine E-Mail durchaus unverschlüsselt übertragen werden; doch all dies geschieht nur im Herrschaftsgebiet der beiden E-Mail-Provider.

Das BSI aktualisierte übrigens im April 2019 den Mindeststandard von TLS:

    "Bei der Übertragung von Informationen über Kommunikationsnetze besteht die Gefahr, dass Informationen unbefugt abgehört oder unbefugt manipuliert werden. Um die Vertraulichkeit und die Integrität der Informationen sicherzustellen, müssen entsprechende Maßnahmen zur Absicherung der Übertragung ergriffen werden.
    Eine mögliche Maßnahme ist der Einsatz des Protokolls Transport Layer Security (TLS). Ein wirksamer Schutz wird dann erzielt, wenn eine aktuelle und sichere Version dieses Protokolls mit der korrekten Konfiguration eingesetzt wird.
    "

Der Vollständigkeit halber wollen wir hinzufügen:

  • Wenn der Empfänger-Server keine "offiziellen" Zertifikate nutzt, sondern eine selbst erstellte Schlüsseldatei, dann ist der Schlüssel vom Absender nicht validierbar und somit wäre die Kommunikation durch "man-in-the-middle" möglich.
  • Wenn TLS in einer alten Version (also kleiner 1.2) genutzt wird, dann könnte die Kommunikation möglicherweise störanfällig sein.

Unser Fazit: TLS ist auf dem Übertragungsweg nicht belauschbar, wenn die Systeme ordnungsgemäß konfiguriert sind. Deswegen akzeptieren die deutschen Datenschutz-Aufsichtsbehörden prinzipiell die TLS-Verschlüsselung von E-Mails und bezeichnen dies als "Stand der Technik".

(P.S. Wir danken den Supportmitarbeitern von www.mail.de ganz ausdrücklich. Dort hat man sich alle Mühe gegeben diese Problematik zu analysieren und zu erklären. Damit hat jener Provider seine Kompetenz deutlich unter Beweis gestellt.)

(P.S. Selbst mit PGP bzw. S/MIME ist man nicht sicher, wie man hier nachlesen kann.)

1.2) Wie kann man TLS-verschlüsselte E-Mails nachweisen?

Als Absender kann man meist keine TLS-Veschlüsselung erzwingen ("mandatory TLS"), weil die Mail-Dienstleister dies nicht anbieten.

Insofern kann der "Nachweis" der Verschlüsselung nur statistisch gelingen. Facebook hat festgestellt, dass über 99% aller E-Mail Server verschlüsselt kommunizieren können (Video). Eigene Untersuchungen unserer Kunden bestätigen dieses Ergebnis voll und ganz. Im Ergebnis lässt sich festhalten: TLS ist wirklich "Stand der Technik".

Der Absender hat aber dennoch gewisse Möglichkeiten nachzuweisen, dass er seinerseits TLS dauerhaft nutzt (dies wird auch beim BSI empfohlen):

  • Wöchentlich kann der Verantwortliche den eigenen Server testen (siehe folgendes Kapitel 2). Das Ergebnis sollte er dokumentieren.
     
  • Die IT-Abteilung und die zuständigen Dienstleister werden explizit schriftlich darauf hingewiesen, dass jede Änderung an den E-Mail Servern (oder eventuellen Serviceprovidern) zum versehentlichen Abschalten der TLS-Verschlüsselung führen könnte. Daher ist hier höchste Aufmerksamkeit geboten.

Unser Fazit: Es gibt meist keine zwingenden Nachweismöglichkeit, dass jede einzelne E-Mail mit TLS verschlüsselt gesendet bzw. empfangen wurde. Statistisch gesehen kann es aber als gesichert gelten. Durch eine engmaschige Selbstkontrolle sollte der Verantwortliche seine Anstrengungen dokumentieren.

2.) TLS beim Senden

Wie kann man prüfen, ob der eigene E-Mail-Server die Verbindung zum Ziel-Server verschlüsselt? Dies lässt sich mittels verschiedener Webseiten testen. Solche Tests setzen voraus, dass das Senden per SMTP möglich ist.

  1. https://ssl-tools.net/mails
    Dies ist ein besonders einfacher Service. Man klickt oben auf den Hyperlink "check@ssl-tools.net", worauf sich eine neue E-Mail öffnet. Diese sendet man ab. Wenige Sekunden später kann man auf der Webseite sehen, ob der Datenverkehr per TLS verschlüsselt wurde. Einfacher geht es nicht; siehe Abbildung:

     
  2. http://checktls.com/perl/TestSender.pl
    Sobald man den Test startet, kann man auch hier eine E-Mail an den Server versenden. Die Antwort bekommt man per E-Mail.
    Die Prüfung hat allerdings einen Haken: Es wird zwingend vorausgesetzt, dass sich der Absender mit dem SMTP-Befehl "EHLO" statt "HELO" meldet. Dies ist wohl etwas streng, denn mittlerweile gehört der "STARTTLS"-Befehl auch zum Standardrepertoire von Servern, die sich klassisch mit "HELO" melden.
    Fazit: Wenn dieser Dienst eine fehlende Verschlüsselung meldet, dann sollte man sich die Fehlerquelle genau anschauen. Sofern es an dem fehlenden "EHLO" liegt, so sollte man das Ergebnis vielleicht kritisch hinterfragen.

    War dieser Test erfolgreich, dann kommt eine E-Mail mit folgendem Inhalt zurück:
     

3.) TLS beim Empfangen

Wie kann man prüfen, ob der eigene E-Mail-Server eine TLS-verschlüsselte Datenverbindung aufbauen kann? Sehr gut funktioniert dies mittels der Webseiten

  1. https://www.checktls.com/perl/TestReceiver.pl
    Hier wird der gesamte SMTP-Datenverkehr aufgezeigt. Das ist interessant und lehrreich. Wenn alles gut geht, dann sieht das endgültige Testergebnis so aus:

    img3.gif 

    Bei diesem Test kann man den Button "more Details" anklicken, dann werden noch sehr viel mehr Details aufgeführt. Alle Zertifikats-Informationen werden komplett angezeigt, wodurch eine Fehlersuche noch besser möglich wird.
     
  2. https://luxsci.com/extranet/tlschecker.html
    Hier gibt man nur den Domainnamen an. Danach sieht man folgende Meldung, wenn alles gut ging:

     
  3. www.mxtoolbox.com
    Auch diese Webseite führt einen guten Test aus. Nachdem man die E-Mail-Domain eingegeben hat, kann man rechts daneben auf den "SMTP-Test" klicken. Das Ergebnis sieht (verkürzt) so aus:

     
  4. Kommandozeilen-Test
    Der Test eines Empfänger-E-Mail-Servers kann man auch selbst per Kommandozeile prüfen. In der DOS-Kommandozeile führt man die folgenden Befehle aus: (ausführlichst hier beschrieben)
    >> Telnet securedataservice.de 25
    << 220 securedataservice.de
    >> EHLO abc.de
    << 250-securedataservice.de
    << 250-STARTTLS

    >> STARTTLS
    << 220 begin ssl handshake
     
  5. E-Mail Header auswerten
    In dem folgenden Artikel https://luxsci.com/blog/how-you-can-tell-if-an-email-was-sent-using-tls-encryption.html wird beschrieben, dass man dies im E-Mail Header erkennen könnte. Dies kann folgendermaßen aussehen:
    img1.gif
    Ein Test zwischen Web.de und Gmx.de zeigt da aber nichts Erkennbares, insofern kann man sich vielleicht nicht 100%-ig auf diese Anzeige verlassen.

4.) Sonstige Kontrollmöglichkeiten

  • https://ssl-tools.net/mailservers
    Dieser Test setzt einen anderen Schwerpunkt: Hier wird zusätzlich geprüft, ob die Option "Perfect Forward Secrecy" (PFS) möglich ist und ob die Option "DANE" zur Verfügung steht. Diese beiden Optionen bieten eine insgesamt noch höhere Sicherheit.

5.) Weiterführende Links