Emailsicherheit bei öffentlichen Einrichtungen

Vor einigen Monaten habe ich schon meine Erkenntnisse zur Emailverschlüsselung veröffentlicht. Das BfDI überlegt anscheinend immer noch, ob man die eigenen Überlegungen veröffentlicht oder vielleicht lieber gleich die Orientierungshilfe ü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 "öffentliche 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 öffentlichen Einrichtungen die bei FragDenStaat gelistet sind und deren Adressen ich von dort heruntergeladen habe.

Das sind rund 41.000 Emailadressen öffentlicher Einrichtungen, 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 öffentlichen Einrichtungen 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 Auftragsverarbeitung handeln (aber siehe auch Auftragsverarbeitung 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 Transportverschlüsselung der Orientierungshilfe zur Emailverschlüsselung der Datenschutzkonferenz. 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 Sicherheit bringen. Die Orientierungshilfe schweigt sich aus, ob sie bei der obligatorischen Transportverschlüsselung 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 Verschlüsselung 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 Transportverschlüsselung 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 Datenschutz

grau

siehe Kommentar – meist Ziel knapp verfehlt

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

• 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 Transportverschlüsselung konfiguriert, ist man ganz gut dabbei.