Email­sicher­heit bei öffent­lichen Ein­rich­tungen

Vor einigen Monaten habe ich schon meine Erkenntnisse zur Emailverschlüsselung veröffent­licht. Das BfDI überlegt anscheinend immer noch, ob man die eigenen Überlegungen veröffent­licht oder vielleicht lieber gleich die Orien­tie­rungshilfe überarbeitet. Das BSI hat anscheinend gar kein Interesse daran, seine widersprüchlichen Empfehlungen zu überdenken.

Um mal ein Gefühl dafür zu bekommen wie das "öffent­liche Deutschland" mit Emailverschlüsselung umgeht, habe ich einen Test gestartet. Der Test ist inspiriert durch den Heise Artikel Digitalisierung in Deutschland: Wahlleitung im E-Mail-Test, und funktioniert im Prinzip wie schon da beschrieben, nur dass ich nicht die Wahlleitungen getestet habe, sondern alle Emailadressen von mehr-oder-weniger öffent­lichen Ein­rich­tungen die bei FragDenStaat gelistet sind und deren Adressen ich von dort heruntergeladen habe.

Das sind rund 41.000 Emailadressen öffent­licher Ein­rich­tungen, ca. 21.000 Domänen, und ca. 3.800 Betreiber die Maildienste erbringen. Darunter einige Betreiber wie United Internet (u.a. Mailadressen web.de oder gmx.net) oder Google (googlemail.com, gmail.com), die man eher von privat-Anwendern als von öffent­lichen Ein­rich­tungen erwarten würde. Immerhin kann man von United Internet sagen, dass sie DNSSEC ernster nehmen als viele andere Betreiber. Wenn Mailboxinhaber (Verantwortlicher) und Betreiber verschieden sind, kann es sich um Auftrags­ver­arbei­tung handeln (aber siehe auch Auftrags­ver­arbei­tung bei Email), es kann aber auch sein, dass nur unterschiedliche Domänen für verschiedene Dienste verwendet werden.

Worauf kommt es an?

Damit eingehende Emails sicher zugestellt werden können, braucht es:
DNSSEC
Ohne DNSSEC kann ein Angreifer möglicherweise einem sendenden Emailserver falsche Informationen unterschieben - z.B. einen falschen MX- oder A-Record - und damit die Mail auf einen anderen Server umleiten.
TLS
Ohne Transport-Layer-Security (TLS) findet die Kommunikation unverschlüsselt und damit auch nicht authentifiziert statt - ein Angreifer kann dann mithören oder auch die Nachricht via IP-Spoofing umleiten oder die Übertragung verfälschen. Eine TLS-geschützte Verbindung mit aktuellen Chiffren ist vor Mithören und Manipulationen geschützt, allerdings ist nicht unbedingt klar, mit wem man eigentlich kommuniziert. Dafür braucht es auch noch Zertifikate.
Zertifikate
passende, gültige und vertrauenswürdige X.509 Zertifikate - damit auch klar ist, mit wem man kommuniziert. Passend: passend zum Hostnamen des Mailservers (wie im MX-Record), Gültig meint u.a. nicht abgelaufen und für den Einsatzzweck Serverauthentifizierung, und vertrauenswürdig meint, dass die Kette vom Serverzertifikat bis zu einem bekannten Root-Zertifikat oder zu einer DANE-Information überprüft werden kann. Letzteres setzt allerdings auch DNSSEC voraus, sonst könnte diese Information auch gefälscht sein.

Damit Email wirklich sicher ist, braucht es also DNSSEC, TLS, und geeignete Zertifikate. Das entspricht dann der qualifizierten Transport­ver­schlüs­selung der Orien­tie­rungshilfe zur Emailverschlüsselung der Daten­schutzkonferenz. Leider untersützen das nicht alle. DNSSEC ist bei nicht einmal 2% der .de Domains aktiv. Besser sieht es bei TLS aus - das können die meisten überprüften Mailserver. Allerdings verwenden viele leider keine geeigneten Zertifikate - und man kann sogar argumentieren, dass auch geeignete Zertifikate ohne DNSSEC keine Sicher­heit bringen. Die Orien­tie­rungshilfe schweigt sich aus, ob sie bei der obligatorischen Transport­ver­schlüs­selung nur TLS erwartet oder ob die Zertifikate auch noch geeignet sein sollen.

Dass Emails verschlüsselt werden müssen, ist Konsens unter den Kommentatoren (siehe auch Ist Ver­schlüs­selung Pflicht?). Leider scheint den Kommentatoren nicht ganz so klar zu sein, dass auch Authentifizierung erforderlich ist, damit nicht mit dem falschen Kommunikationspartner kommuniziert wird. Bei Webservern sind Zertifikate ganz normal und meist ausreichend, weil der Servername in der sichtbaren URL enthalten ist. Aber weil bei Email eine Indirektion über DNS verwendet wird, braucht es zum Schutz vor Manipulationen zusätzlich DNSSEC.

Nicht getestet habe ich MTA-STS, DANE, oder DomainKeys Identified Mail (DKIM). MTA-STS setzt DNSSEC und geeignete Zertifikate voraus, und schon daran mangelt es, wie der Test zeigt. DANE erlaubt es statt den - wie oben definiert - geeigneten Zertifikaten auch andere, z.B. auch selbst signierte Zertifikate, zu verwenden. Erst bei der Auswertung und Fehlersuche bin ich dann über bayern.de gestolpert, die tatsächlich auf DANE setzen und keine im obigen Sinne geeigneten Zertifikate verwenden. Auch bund.de und United Internet unterstützen DANE, aber mit geeigneten Zertifikaten - vielleicht weil viele Tests wie z.B. checktls.com DANE nicht auswerten und daher bei bayern.de einen Fehler melden. DKIM zu testen würde tatsächlich Sinn ergeben, aber leider kann man das nur beim Empfangen einer Email prüfen - und 21.000 Mails wollte ich jetzt auch nicht absenden und auf Antwort hoffen. Vielleicht in einer weiteren Aktion.

Und genau wie bei DKIM - was ein Emailserver beim Versenden von Emails prüft kann ich nicht von außen prüfen. Aber solange die Erwartungen oben nicht in der Fläche für eingehende Emails erfüllt werden, werden vielleicht nur Enthusiasten wie ich ihren Emailserver auf obligatorische oder gar qualifizierte Transport­ver­schlüs­selung konfigurieren (mein Postfix steht tatsächlich auf "verify" und DNSSEC wird ausgewertet - aber natürlich brauchen dann einige Domänen eine Ausnahme, damit die Emails versendet werden).

Was machen meine Testskripte?

Im ersten Lauf wird für jede Domain ermittelt ob sie MX-Records hat und dabei DNSSEC unterstützt. Für jeden MX-Record (unabhängig vom DNSSEC-Ergebnis) wird geprüft, ob der jeweilige Dienst TLS und Zertifikate unterstützt. Außerdem wird noch geprüft, ob der A-Record DNSSEC-signiert ist. Das DNSSEC-Testergebnis kann für MX-Record und A-Record auseinanderfallen, denn der A-Record wird vom Betreiber, der MX-Record von der Domäne bestimmt. Tatsächlich ist es bei 160 Domänen die DNSSEC verwenden vorgekommen, dass der Betreiber - insgesamt etwa 40 - DNSSEC nicht verwendet. Auch der umgekehrte Fall tritt auf: ca. 75 Betreiber verwenden DNSSEC, aber ca. 1.500 der bei ihnen vorbeikommenden Domänen nicht.

Für jede Mailadresse bzw. Domain werden dann in einem Auswertungslauf die Ergebnisse zusammengetragen: Mailadresse, Domain, Betreiber, DNSSEC, TLS, Zertifikate. Den Betreiber kann ich natürlich nicht eindeutig benennen, aber näherungsweise kann er identifiziert werden, indem man bei den Namen der Mailserver nur die letzten beiden Komponenten - einige Betreiber haben mehrere Topleveldomänen - betrachtet, die verbleibenden Namen sortiert und ggfs. mehrere ausweist. Für die Ergebnistabelle habe ich teilweise nachjustiert wenn Konflikte erkennbar waren. Eine Alternative wäre möglicherweise, die Betreiber über ihr Autonomes-System zu identifzieren.

So bekommt man z.B. für das Bundessortenamt mit der Anfrage...

# dig +dnssec -t MX bundessortenamt.de @1.1.1.1

; <<>> DiG 9.16.1-Ubuntu <<>> -t MX bundessortenamt.de @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12085
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;bundessortenamt.de.            IN      MX

;; ANSWER SECTION:
bundessortenamt.de.     172800  IN      MX      30 email.bundessortenamt.de.
bundessortenamt.de.     172800  IN      MX      10 mail.bundessortenamt.de.
bundessortenamt.de.     172800  IN      MX      20 mforward.dtag.de.

;; Query time: 32 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Sun Jan 16 11:01:32 UTC 2022
;; MSG SIZE  rcvd: 120
... drei Mailserver und die Betreiber bundessortenamt.de und dtag.de. Und durch das Fehlen jeglicher RRSIG-Records die Information, dass DNSSEC nicht verwendet wird.

Wenn man dann für alle drei Mailserver TLS prüft, dann bekommt man ein uneinheitliches Bild: mforward.dtag.de hat zwar ein gültiges Zertifikat, aber bietet STARTTLS gar nicht an. Bei email.bundessortenamt.de und mail.bundessortenamt.de meldet OpenSSL "certificate key too weak", "Hostname mismatch", und "unable to verify the first certificate". Also ganz verschiedene Gründe. Bei email.bundessortenamt.de und mail.bundessortenamt.de wäre eine verschlüsselte, aber nicht authentifizierte Kommunikation möglich, bei mforward.dtag.de nicht (die meisten Emailserver schicken die Nachricht unverschlüsselt, wenn STARTTLS nicht angeboten wird).

Dass mehrere Betreiber verwendet werden, kommt öfter vor, ca. 500 Domänen verwenden mehrere Betreiber, und teilweise unterschiedlich sicher. Darunter sind beispielsweise 168 Domänen die dtag.de, also die Deutsche Telekom verwenden. Nur dass dtag.de zwei Eingänge hat: tmforward.dtag.de mit TLS, mforward.dtag.de ohne TLS. Von den 168 Domänen verwenden 167 - raten Sie mal - genau! - den falschen, den ohne TLS. Ob man für TLS bei der Deutschen Telekom extra bezahlen muss, weiß ich natürlich nicht. Aber vermutlich würde eine bessere Zusammenarbeit zwischen Verantwortlichem (Domäne) und Auftragsverarbeiter (Betreiber) helfen, sicherer zu werden. Die Auswertung differenziert daher nach Betreibern.

Ich habe natürlich stichprobenartig überprüft, dass die Skripte keinen groben Unsinn ausgeben, aber bei 40.000 Datensätzen will ich nicht ausschließen, dass irgendwo auch ein Bug drin ist. Feedback daher immer gerne.

Probleme mit der Datenqualität

Ganz typisch, es gehen auch Dinge schief:
  • Schon in den Rohdaten sind fehlerhafte Emailadressen
  • Einige Domänen existieren nicht mehr
  • Einige Domänen verwenden keine MX-Records. Nach SMTP-Standard soll dann der A-Record verwendet werden. Da muss ich meine Skripte noch nachbessern. Allerdings tritt hier gleich das nächste Problem gehäuft auf...
  • einige Server antworten gar nicht erst. Das wird teilweise als Honeypot für Spammer gemacht, aber wenn es der einzige Mailserver ist, was dann?
  • ca. 900 Domänen verwenden eine bunte Mischung von Betreiberdomänen - s.o. - bis zu vier habe ich gesehen
Dadurch fallen dann einige Emailadressen aus der Analyse raus oder - bei mehreren Betreibern - gehen mehrfach ein.

Ergebnisse?

Damit die Tabelle nicht zu groß wird sind in der folgenden Tabelle nur Betreiber vertreten, die mehr als 100 Emailadressen betreuen. Das Bundessortenamt selbst ist daher nicht enthalten, die Deutsche Telekom (dtag.de) schon. Der Farbcode bedeutet:

grün
DNSSEC, TLS und gültige Zertifikate
weiß
TLS und gültige Zertifikate
gelb
TLS aber keine gültigen Zertifikate
rot
kein TLS - in meinen Augen ein klarer Verstoß gegen den Daten­schutz
grau
siehe Kommentar - meist Ziel knapp verfehlt
GesamtergebnisAnzahl MailadressenAnzahl DomänenVer­schlüs­selung (TLS)Geeignete ZertifikateQualifizierte Transport­ver­schlüsselung Kommentare
Insgesamt410442239421980185861320(Doppelzählungen möglich)
Probleme414380820660
BetreiberAnzahl MailadressenAnzahl DomänenVer­schlüs­selung (TLS)Geeignete ZertifikateQualifizierte Transport­ver­schlüsselungKommentare
nrw.de56923663663660
bwl.de36463578357835780
t-online.de22332082082080
hessen.de20571969196919690
kvnbw.de12369519519510
bayern.de11507997990799Bayern verwendet DANE. Für einen Emailclient der kein DNSSEC unterstützt eine mögliche Falle.
kundenserver.de10916776776770
outlook.com10677797757590Meine IP steht auf Microsofts Blacklist für das "private" outlook.com - m.W. immer TLS und gültige Zertifikate
landsh.de10001621621620
rzone.de9506866866860
bildung-lsa.de910908908908908
ondataport.de6311451451450
rlp.de5861651651650
pzd-svn.de5853723723720
arbeitsagentur.de5014440
gmx.net4294442Auf gmx kann man anscheinend Alias-Domänen definieren, die dann kein DNSSEC verwenden. Gmx selbst wäre grün.
s-web.de4074062472470s-web.de hat unterschiedlich gut konfigurierte Mailserver.
ispgateway.de3972892892890
web.de3841111
verwalt-berlin.de3552422422420
kasserver.com3533003003000
iserv.eu2532462462460
ekom21.de2372062062066
bund.de23287878760Schade: bund.de kann DNSSEC, DANE, und verwendet geeignete Zertifikate, und kann damit auch qualifizierte Transport­ver­schlüs­selung, aber nicht alle Behörden nutzen das.
schlund.de22819119100Zeigt auf kundenserver.de, nur passen dann die Zertifikate nicht.
dfn.de22612512512515
kgrz-ks.de2211961961966
ewetel.de2182020200
brandenburg.de208106106106101
niedersachsen.de2051071071070
kdo.de1781111091090mx02.kdo.de unterstützt kein STARTTLS.
dtag.de16745110tmforward.dtag.de mit TLS, mforward.dtag.de ohne TLS
agenturserver.de1521201201200
bremen.de1443300Selbstsignierte Zertifikate - bei der Polizei dann schon ärgerlich.
kraemer-it.de1402323230
rzf-nrw.de1391371371370
cm-system.de1373737270
ionos.de1349999990
mvnet.de1238080804
sachsen-anhalt.de12242000STARTTLS wird nicht unterstützt.
google.com1176969690
verwaltungsportal.de1128181810
antispameurope.com1098484790
citkomm.net1027575750
Wie sieht es mit der Daten­schutzaufsicht aus?
Domäne AufsichtVer­schlüs­selung (TLS)Geeignete ZertifikateQualifizierte Transport­ver­schlüsselung Kommentare
bfdi.bund.de111
lfdi.bwl.de110
lda.bayern.de101Siehe bayern.de oben
lda.berlin.de110
datenschutz-berlin.de100bei der neuen Domäne hat Berlin kein gültiges Zertifikat
lda.brandenburg.de111
datenschutz.bremen.de110Verwendet nicht bremen.de oben
datenschutz.hamburg.de110
datenschutz.hessen.de110
datenschutz-mv.de110
datenschutz.hessen.de110
datenschutz.rlp.de 110
datenschutz.saarland.de110
slt.sachsen.de110
lfd.sachsen-anhalt.de000
datenschutzzentrum.de110Manuell ergänzt
datenschutz.thueringen.de100
edpb.europa.eu110

Wie man insbesondere bei dtag.de und bund.de ganz gut sehen kann, müssen Domäneninhaber und Betreiber zusammenarbeiten um alles richtig zu konfigurieren.

Wer daran interessiert ist, seine eigene Domäne zu finden folgt diesen Schritten um zu starten:
  • Download dieser Ergebnisdatei im CSV-Format
  • Excel starten (jedenfalls hab ich das verwendet)
  • leeres Dokument anlegen
  • Im Menu Daten "Aus Text/CSV" auswählen
  • die heruntergeladene Datei öffnen, die Vorschau passt, also Laden
Jetzt sieht man die Ergebnisse. In der kann man direkt nach der Domäne oder Provider selektieren. Die Darstellung oben bekommt man durch:
  • alles auswählen
  • Einfügen/Pivot Tabelle und OK
  • Provider in die Zeilen, andere Felder (außer Sec*) in die Werte
  • auf eine Zelle unter "Summe Mailboxcount" der Tabelle klicken und rechte-Maustaste Sortieren/Nach Größe sortieren (absteigend)
In den Ergebnissen ist QT manchmal fälschlich 0, weil im Testskript nur auf ein geeignetes Zertifikat geprüft wird ohne DANE zu beachten. Einen Hinweis liefert dann der Filter QT=0, SecMX=1, SecA=1...

Fazit

Da ist eindeutig noch Potential nach oben. TLS muss selbstverständlich werden. Und auch DNSSEC und geeignete Zertifikate sind Stand-der-Technik. Wenn man dann für ausgehende EMails auch noch DKIM umsetzt und zumindest obligatorische Transport­ver­schlüs­selung konfiguriert, ist man ganz gut dabbei.


Veröffent­licht am 18.01.2022, zuletzt geändert am 08.04.2022.

©2022 Joachim Lindenberg. Diese Seite spiegelt meine persönliche Meinung wieder. Sie stellt keine Rechtsberatung dar. Fragen Sie doch einen Anwalt der sich damit auskennt.