Emailsicherheit – der Test

Jetzt schreibe ich seit Monaten immer mal wieder über Emailsicherheit und Verschlüsselung – aber wie soll ich als Otto Normalverbraucher herausfinden, was mein Anbieter macht?

Natürlich gibt es für alles schon irgendeinen Test im Internet, aber alle irgendwie umständlich, unverständlich, oder nicht vollständig. Auch meiner ist nicht vollständig, aber dafür etwas für einfache Anwender... wenn Sie mir eine Email zum Sicherheitstest an de@et.lindenberg.one und de@ut.lindenberg.one schicken (die Mail soll wirklich an beide Adressen gehen), dann testet einer meiner Server Ihren Emailserver sowohl auf sein Verhalten bei dieser ausgehenden Email als auch wie er sich für eingehende Mails verhält. Beide Richtungen sind wichtig. Es kann durchaus sein, dass man mit Ihrem Emailserver zwar verschlüsselt kommunizieren kann, dass er selbst das bei ausgehenden Emails aber gar nicht versucht. Auch wird DKIM geprüft (aber noch nicht validiert) und die Liste der Tests kann noch erweitert werden – wenn Interesse besteht.

Der Test dauert manchmal nur wenige Minuten, kann aber auch einige Stunden oder sogar Tage dauern, also wundern Sie sich bitte nicht, wenn die Antwort nicht sofort kommt. Der Test muss Ihren Emailserver dazu überreden, mehrere Verbindungen aufzubauen und das auch noch zu verschieden Instanzen (für Profis: MX-Records). Wie schnell das geht, hängt davon ab, in welchen Zeitabständen Ihr Server das versucht, und ob er dann immer nur eine Adresse oder mehrere verwendet. Emailserver mit Postfix machen das teils sehr zügig, outlook.com lässt sich deutlich länger Zeit. Typischerweise bekommen Sie nach ca. 4 Stunden eine Warnung dass die Zustellung länger dauert – das ist normal. Nur wenn Sie eine Benachrichtigung erhalten, dass die Zustellung endgültig gescheitert ist – dann melden Sie sich bitte bei mir unter support@lindenberg.one.

Und natürlich gibt es eine Ausnahme: Wenn Sie eine Email der Art remote MX does not support STARTTLS (web.de) oder TLS is required, but was not offered by host (mailbox.org) erhalten, dann hat Ihr Emailserver beim Versuch, unverschlüsselte Kommunikation zu verwenden, die Email gleich als unzustellbar markiert. Das ist erstmal ein gutes Zeichen und ein Hinweis, dass möglicherweise RFC 7672 verwendet wird, denn für eine der beiden Domänen des Tests existiert im DNS die Information, dass DANE unterstützt und daher keine unverschlüsselte Verbindungen akzeptieren sollte. Web.de und Mailbox.org bestehen darauf, vielleicht auch weitere Domänen die DANE verwenden. Tatsächlich ist dieses Verhalten aber nicht perfekt, denn der Endanwender kann da gar nichts machen, und der RFC 7672 SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) empfiehlt bei ähnlichen Fehlern Wiederholung statt Abbruch. In diesem Fall laufen die anderen Tests in dem Sie die Testmail erneut senden bis keine derartige Antwort mehr eingeht.

In hoffentlich ganz selten Fällen erhalten Sie eine Benachrichtigung, dass die Zustellung gescheitert ist, weil sie für Spam gehalten wurde.

Was prüft der Test?

Für Ihre abgehende Mail versucht er Ihren Mailserver dazu zu überreden, die Nachricht unverschlüsselt zu versenden. Gelingt das nicht – Topp! Leider ist das nicht Standard, oder allenfalls wenn der Server RFC 7672 SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) verwendet und dann halt nur für Domänen die entsprechende DANE TLSA Records publizieren. Wenn Ihr Mailserver SNI verwendet (zwingend bei RFC 7672), dann bietet mein Server unterschiedliche Zertifikate an, um zu ermitteln, ob und wie tatsächlich auf gültige Zertifikate geprüft wird, oder ob das nicht der Fall ist. Dieser Teil kann dann wirklich dauern. Nicht direkt prüfen kann ich, ob Ihr Emailserver DNSSEC verwendet, aber der RFC 7672 verlangt DNSSEC um die TLSA Records auszuwerten, also steckt das Ergebnis da mit drin, oder Ihr Emailserver ist nicht standardkonform – da alle denkbaren Abweichungen zu prüfen ist illusorisch.

Dann wird für das Testergebnis auch wieder – wie bei meinen vorhergehenden Artikeln – geprüft, ob Ihre Domäne bzw. Ihr Betreiber DNSSEC verwendet, ob entsprechende Records vorhanden und signiert sind, ob Ihr Server STARTTLS unterstützt und gültige Zertifikate verwendet. Bei der letzten Prüfung habe ich nachgebessert: DANE Zertifikate werden jetzt als vertrauenswürdig eingestuft und wenn alles richtig konfiguriert ist, wird festgestellt, dass Ihr Server die qualifizierte Transportverschlüsselung der Orientierungshilfe zur Emailverschlüsselung für den Posteingang unterstützt, jedoch ohne sie zu erzwingen.

Und weil das auch für nicht Laien verwirrend ist: Die Grundkomponenten sind wie schon beschrieben DNSSEC, STARTTLS, und Zertifikate. Zertifikate mit oder ohne DANE (RFC 6698, 7671). Unter DANE wird aber leider auch manchmal der schon erwähnte RFC 7672 SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) verstanden. Dieser RFC definiert, dass ein sendender Server STARTTLS (und auch SNI) verwenden muss und die Zertifikate validieren muss, wenn er TLSA Records im DNS(SEC) findet. Die Empfängerdomäne verpflichtet sich gewissermaßen durch die Veröffentlichung von TLSA-Records, DNSSEC, STARTTLS, und mit den veröffentlichten TLSA-Records validierbare Zertifikate zu unterstützen. Existieren diese TLSA Records, dann darf er die Mail nicht anders zustellen, geht etwas schief, dann sollte er es später erneut versuchen – in diesem Punkt gibt es aber auch abweichende Ansichten.

Sichere Email wäre also ganz einfach, wenn alle Anbieter RFC 7672 SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) samt Voraussetzungen unterstützen würden – sowohl beim Empfang als auch beim Senden. In Deutschland ist das leider selten, in den Niederlanden steht dieser RFC auf der Pflichtliste (siehe DANE for SMTP how-to und dort Suche nach Comply or Explain). Die Aufsicht könnte das durchaus auch in Deutschland einfordern – am besten mit einer neuen Orientierungshilfe, in der PGP und S/MIME optional werden, aber RFC 7672 Pflicht. Ggfs. auch mit der zusätzlichen Pflicht auf Oberflächen (z.B. bei der Registrierung) auf die fehlende Unterstützung von RFC 7672 hinzuweisen. Sie meinen das geht nicht? Doch, habe ich in eine meiner Oberflächen schon eingebaut, und auch mail.de hat das. Auch die Prüfung einer Liste von Emailadressen ist kein Problem, das hab ich jetzt auch schon zweimal gezeigt.

Wie prüft der Test?

Dieser Teil ist sehr technisch, aber einige meiner Leser waren so neugierig, dass es jetzt hier dokumentiert ist. Natürlich auch um zu darzustellen, dass man Sicherheitsfunktionen automatisch testen kann. Wer nicht so technisch unterwegs ist darf diesen Teil gerne überspringen – Was ist mit dem BSI IT-Sicherheitskennzeichen oder TR03108-1?

Zunächst muss man die Serverkonfigurationen verstehen. Weil alles auf der gleichen IP-Adresse läuft, sind verschiedene Server nur anhand von SNI oder der Empfängeradresse unterscheidbar. Die Server verwenden dann unterschiedliche Zertifikate mit unterschiedlichen TLSA Records, und je nach Verschlüsselungspolicy (Beispiel Mailcow, siehe RFC 7672 mit Mailcow / Postfix, nur dass Postfix kein MTA-STS kann) müssen dann unterschiedliche Server tatsächlich Emails empfangen.

Die Prioritäten von mx03-mx06 werden alle paar Minuten neu gewürfelt, so dass irgendwann mal jeder Server drankommt, selbst dann wenn immer nur ein Server angesprochen wird. Als empfangen quittiert wird die Mail an et.lindenberg.one erst dann, wenn entweder nur Server 2, alle Server 3-6, oder hinreichend oft zumindest Server 4-6 mindestens einen Zustellversuch gesehen haben, was sich im Status Mail in der Verbindungshistorie ausdrückt. Der Status stellt dabei verschiedene Phasen im Verbindungsaufbau dar, und geht von None, SniSeen, TlsStarted, Mail, bis Acked. Wenn eine Server mit Policies verify, dane/dane-only, oder mta-sts auf ein Zertifikat trifft das er als ungültig ansehen muss, dann trennt er die Verbindung ohne eine Mail zu senden.

Mit diesem Vorwissen lässt sich die Antwortmail entschlüsseln:

Verbindungshistorie:29.06.2022 09:08:45 – 09:08:50 (Server 1, nicht verschlüsselt, None): 29.06.2022 09:08:45 – 09:08:50 (Server 1, nicht verschlüsselt, None): 29.06.2022 09:08:50 – 09:08:50 (Server 1, nicht verschlüsselt, None): 29.06.2022 09:08:50 – 09:08:50 (Server 1, nicht verschlüsselt, None): 29.06.2022 09:08:50 – 09:08:50 (Server 1, nicht verschlüsselt, None): 29.06.2022 09:08:51 – 09:08:51 (Server 1, nicht verschlüsselt, None): ...

Bei den ersten vier Versuchen und innerhalb der ersten drei Minuten bietet der Testserver kein STARTTLS an — simulierte Downgrade-Angriffe. Ein Server der RFC 7672 implementiert darf aber nur an ut.lindenberg.one unverschlüsselt schicken, et.lindenberg.one hat TLSA-Records, da darf er es nicht. Damit an ut.lindenberg.one nicht unverschlüsselt geschickt wird muss man auf Senderseite eine entsprechende Policy definieren — das geht bei manchen Anbietern direkt in der Benutzeroberfläche, bei anderen muss der Administrator aktiv werden. Ist keine Policy definiert, dann taucht in den ersten fünf Minuten bereits eine Zeile mit (Server 7, nicht verschlüsselt, Mail) auf.

Nach ca. 3 Minuten wird STARTTLS aktiviert:

29.06.2022 09:12:03 – 09:12:06 (Server 7, verschlüsselt, Mail):     From: <s***t@lindenberg.one> To: <de@ut.lindenberg.one> Signatures:Dkim29.06.2022 09:12:04 – 09:12:07 (Server 6, verschlüsselt, Mail):     From: <s***t@lindenberg.one> To: <de@et.lindenberg.one> Signatures:Dkim29.06.2022 09:12:07 – 09:12:11 (Server 4, verschlüsselt, Mail):     From: <s***t@lindenberg.one> To: <de@et.lindenberg.one> Signatures:Dkim29.06.2022 09:21:57 – 09:21:57 (Server 3, verschlüsselt, TlsStarted): 29.06.2022 09:21:56 – 09:22:00 (Server 7, verschlüsselt, Acked):     From: <s***t@lindenberg.one> To: <de@ut.lindenberg.one> Signatures:Dkim29.06.2022 09:21:58 – 09:22:01 (Server 4, verschlüsselt, Mail):     From: <s***t@lindenberg.one> To: <de@et.lindenberg.one> Signatures:Dkim29.06.2022 09:22:01 – 09:22:03 (Server 5, verschlüsselt, TlsStarted): 29.06.2022 09:22:03 – 09:22:07 (Server 6, verschlüsselt, Acked):     From: <s***t@lindenberg.one> To: <de@et.lindenberg.one> Signatures:Dkim

Signatures:Dkim oder Arc deutet dann darauf hin, dass Mails signiert sind und wie. Erfolgreich zugestellt wird hier an Server 4 und 6, aber es wurden auch Verbindungsaufbauten zu Server 3 und 5 erfasst. Ob und welche Server eine Mail erhalten wird dann gewissermaßen mit der Tabelle oben verglichen und geht dann in die Antwortmail. Bestätigt wird dann die Mail bei Server 7 und in diesem Ablauf Server 6 – dann wenn alle zu erwartenden Server mindestens einmal einen Verbindungsaufbau registriert haben.

Danach folgt die Analyse des Ergebnisses und der Test für die Empfangsseite:

Analyse Senden von EmailEs erhielen die Mailserver Post, die das nach RFC 7672 tun sollten. Ihr Mailserver verwendet vermutlich RFC 7672 (Postfix: dane) (sehr gut).Ihr Mailserver hat keine Mail (FROM/RCPT/DATA) ohne Verschlüsselung (STARTTLS) übertragen. Das ist oft spezielle Konfiguration durch den Administrator (sehr gut).

Bei neueren Tests wird RFC 7672 getrennt von der qualifizierten Transportverschlüsselung ausgewiesen, weil es tatsächlich Emailserver gibt, die für MX- und A-Records DNSSEC verwenden, aber keine TLSA-Records haben.

Was ist mit dem BSI IT-Sicherheitskennzeichen oder TR03108-1?

Leider ist das BSI IT-Sicherheitskennzeichen keine Garantie für sichere Email. Das denke nicht nur ich, sondern auch das BSI selbst Das IT-Sicherheitskennzeichen kann nicht ... garantieren, dass ein IT-Produkt absolut sicher ist.. Viel unklarer: die zugrundeliegende technische Richtlinie (TR) TR03108-1 verlangt mit EMLREQ_5: DANE (outgoing), dass STARTTLS bei Existenz von TLSA Records erzwungen wird, aber sie fordert weder Konformität zu RFC 7672, noch prüft die TR03108-2 wesentliche Anforderungen von RFC 7672 oder genau die erwähnte Anforderung EMLREQ_5 ab, es wird also insbesondere nicht geprüft, wie sich der Emailserver z.B. bei Downgrade-Angriffen (s. RFC 7672 Sektion 1.3.1.) verhält. Mein Test prüft das nach, simuliert gewissermaßen einen Downgrade-Angriff, und prüft auch was passiert, wenn Zertifikate verwendet werden, die nicht zu den TLSA-Records passen. Auch mein Test ist kein vollständiger Test auf RFC-7672-Konformität. Die Tests habe ich ausgewählt, weil sie mit vertretbarem Aufwand und Zeitbedarf erkennbar machen, ob RFC 7672 verwendet wird oder nicht.

Dass die Anbieter mail.de – IT-Sicherheitskennzeichen bereits erteilt – und mailbox.org – im Prozess – in meinem Test gut abschneiden, liegt eher daran, dass diese Anbieter wissen worauf es ankommt, nicht dass das BSI das in eine technische Richtlinie geschrieben hat. Sie unterscheiden sich aber genau da, wo im RFC 7672 eine Anforderung fehlt, nämlich darin was genau passieren soll, wenn STARTTLS nicht angeboten wird. Der Autor des RFCs und ich stimmen darin überein, dass eine Wiederholung besser wäre als der Abbruch und Fehlermeldung an den Benutzer – der versteht das Problem nicht (hat mein Test bestätigt) und kann auch nichts anderes unternehmen, als die Mail wiederholen oder auf einen anderen Kanal ausweichen.

Deutlich schlechter sieht das bei den Verwaltungsportalen aus. Die sind nach meinem Verständnis der Orientierungshilfe zur Emailverschlüsselung verpflichtet, Verschlüsselung zu erzwingen (Abschnitt 4.2.1), fallen aber beim simulierten Downgrade-Angriff durch. Alle haben Emails unverschlüsselt gesendet obwohl gültige TLSA-Records existieren, und dann weder RFC 7672 noch TR03108-1 eine unverschlüsselte Übertragung erlaubt.

Informationen nach Domänen/Anbieter

Hier beabsichtige ich Informationen nach Anbietern ggfs. zu ergänzen, insbesondere wenn der Test nicht aussagekräftig sein sollte. Alle bisher getesteten Anbieter konnten STARTTLS und hatten gültige Zertifikate, wären also nach dem Farbcode der anderen Tests weiß bzw. die mit RFC 7672 grün – denn mit RFC 7672 auf beiden Seiten erfüllt man die Voraussetzungen für die qualifizierte Transportverschlüsselung. Wie immer kann das Ergebnis für eine eigene Domäne beim Anbieter schlechter sein, weil RFC 7672 erwartet, dass alle DNS-Einträge per DNSSEC gesichert sind.

Aufgefallen ist mir bei den Tests, dass einige Anbieter nur den experimentellen Standard ARC aber kein DKIM verwenden. Nach meinem Verständnis ist DKIM für den ursprünglichen Sender gedacht, ARC für den Empfänger der eine Mail wie bei Mailinglisten weiterleiten will. Aber das handhaben einige schon anders. Und manche verwenden beides.

Domäne/Anbieter	Verschlüsselung	geeignete Zertifikate	RFC 7672	Verschlüsselung erzwungen	DKIM	ARC	Kommentare
aol.com/yahoo.com	Ja	Ja	Nein	Nein	Ja	Nein
dismail.de	Ja	Ja	Nur eingehend	Nein	Ja	Ja	dismail.de unterstützt RFC 7672 nur für eingehende Emails. Beim Versand wird weder Verschlüsselung erzwungen noch werden die TLSA-Records beachtet. Versand war in den vorhergehenden Tests nicht enthalten.
dkinbox.com (posthub.me)	Ja	Nein	Nein	Nein	Nein	Nein
e.email/ecloud.global	Ja	Ja	Nur abgehend	Ja (2)	Ja	Ja	Schade, für eingehend RFC 7672 fehlen die TLSA Records. Qualifi­zierte Transportverschlüsselung also nur durch Konfigu­ration auf Seite des Senders.
gmx.de/gmx.net	Ja	Ja	Ja (1,4)	Nein	Ja	(3)
google.com/gmail.com	Ja	Ja	Nein	Nein	Ja	Nein	google.com/gmail.com unterstützt MTA-STS, aber scheitert an Abschnitt 5.1 Nr. 2 von RFC 8461
icloud.com	Ja	Ja	Nein	Nein	Ja	Nein
kasserver.com	Ja	Ja	Nein	Nein	Ja	(3)
kundenserver.de (Ionos)	Ja	Ja	Nein	Nein	Nein	Nein
lindenberg.one	Ja	Ja	Ja	Optional	Ja	Nein	Die Standardeinstellung ist, dass nur verschlüsselt kommuniziert wird. Details in RFC 7672 mit Mailcow / Postfix.
mail.de	Ja	Ja	Ja	Nein	Ja	Nein	Schön ist, dass man in der Weboberfläche am grünen Schloss mit Haken sofort erkennen könnte, ob die Zieladresse auch RFC 7672 unterstützt, aber leider wird auch die weniger sichere Variante nur STARTTLS grün angezeigt (siehe farbige Darstellung von Empfänger-Adressen in E-Mail verfassen).
mailbox.org	Ja	Ja	Ja (1)	Optional	Ja	Ja	Auch ohne RFC 7672 beim Empfänger kann secure.mailbox.org Verschlüsselung erzwingen (siehe SSL-TLS-Verschluesselung bei mailbox.org). Allerdings wird dann beim Senden kein RFC 7672 verwendet. Mit den Profi-Einstellungen bekommt man die Wahl zwischen encrypt, verify und dane-only – dazu siehe RFC 7672 mit Mailcow / Postfix. Testergebnisse von secure.mailbox.org können daher unterschiedlich ausfallen, insbesondere wenn mehrere Tests gleichzeitig laufen.
secure.mailbox.org	Ja	Ja	Nur eingehend (1)	Ja	Ja	Ja
manitu.net	Ja	Nein	Nein	Nein	Nein	Nein
outlook.com	Ja	Ja	Ja	Nein	Teilweise	Ja	outlook.com unterstützt SMPT-DANE und MTA-STS. Eingehend unterstützt outlook.com bisher weder SMTP-DANE noch MTA-STS (es scheint Pläne im Bezahlbereich zu geben – How can Exchange Online customers use SMTP DANE Outbound?). DKIM habe ich bei manchen Domänen (outlook.com, live.com) beobachtet, bei manchen nicht (outlook.de).
posteo.de/posteo.ch	Ja	Ja	Nur eingehend (1)	Optional	Ja	Nein	Auch ohne RFC 7672 beim Empfänger kann posteo.de Verschlüsselung erzwingen (siehe TLS-Versand- und Empfangsgarantien), dann wird aber kein RFC 7672 verwendet.
proton.me/protonmail.ch	Ja	Ja	Nur eingehend	Nein	Ja	Nein	verwendet ausgehend verify ohne Verschlüsselung zu erzwingen.
skiff.com	Ja	Ja	Nur eingehend	Nein	Ja	Nein	In einem meiner Tests wurde eine Mail weder zugestellt noch gabe es eine Unzustelllbarkeitsnachricht – das verletzt Abschnitt 6.2 von RFC 5321 Simple Mail Transfer Protocol. Abgehend wird weder RFC 7672 noch RFC 8461 verwendet, noch werden Zertifikate geprüft.
t-online.de	Ja	Ja	Nein	Nein	Nein	Nein	t-online unterstützt kein SPF, kein DKIM, kein DMARC.
tuta.com/tutanota.com	Ja	Ja	Ja	Nein	Ja	Nein
vodafonemail.de	Ja	Ja	Nein	Nein	Ja	Nein
web.de	Ja	Ja	Ja (1,4)	Nein	Ja	Nein
Anmerkungen
			(1)				Sofortige Fehlermeldung wenn STARTTLS nicht angeboten wird. Sicher ist, dass keiner der Testanwender diese Fehlermeldung verstanden hat.
				(2)			Unklar ob dafür Konfiguration nötig war.
						(3)	Noch kein Test seit ARC erfasst wird.
			(4)				Fehler bei Zertifikaten die nicht standardmäßig vertrauenswürdig sind aber vertrauenswürdig nach DANE sind.
Verwaltungsportale (kein Portal hat STARTTLS erzwungen oder SNI verwendet, daher RFC 7672 allenfalls eingehend, wobei unklar ist, ob die Verwaltungsportale überhaupt Emails empfangen)
service-bw.bwl.de (bwl.de)	Ja	Ja	Nein	Nein	Nein	Nein	Baden-Württemberg
freistaat.bayern, id.brandenburg.de (akdb.de)	Ja	Ja	Nein	Nein	Nein	Nein	Bayern, Brandenburg
itdz-berlin.de (verwalt-berlin.de)	Ja	Ja	Nein	Nein	Nein	Nein	Berlin
dataport.de	Ja	Ja	Nein	Nein	Nein	Nein	Bremen, Hamburg, Niedersachsen, Sachsen-Anhalt, und Schleswig-Holstein
bmi.bund.de (bfinv.de)	Ja	Ja	allenfalls eingehend	Nein	Nein	Nein	Bund
ekom21.de	Ja	Ja	allenfalls eingehend	Nein	Nein	Nein	Hessen
mvnet.de	Ja	Ja	allenfalls eingehend	Nein	Nein	Nein	Mecklenburg-Vorpommern
servicekonto.nrw (krzn.de)	Ja	Ja	Nein	Nein	Ja	Nein	Nordrhein-Westfalen
sid.sachsen.de (pzd-svn.de)	Ja	Ja	Nein	Nein	Nein	Nein	Sachsen
ldi.rlp.de	Ja	Ja	Nein	Nein	Nein	Nein	Rheinland-Pfalz
thueringen.de	Ja	Ja	Nein	Nein	Nein	Nein	Thüringen

Anfragen?