Digitalisierung in Deutschland: Wahlleitung im E-Mail-Test

Inhaltsverzeichnis

Die Bundestagswahl steht vor der Tür und Digitalisierung ist ein wichtiges Thema. Die Basis dafür sind digitale Kommunikationsmöglichkeiten und E-Mail ist da nach wie vor zentral. Doch unser Test der für die Bundestagswahl eingesetzten E-Mail-Server zeigt, dass fast ein Viertel davon nicht einmal grundlegende Anforderungen an die Sicherheit erfüllt. Manche können gar nicht verschlüsseln und erzwingen damit eine ungesicherte Übertragung. Und ziemlich viele können sich nicht richtig ausweisen.

Damit E-Mail verlässlich funktioniert, gibt es ein paar grundsätzliche Dinge, die man beachten sollte. Nichts Abgefahrenes, sondern vielmehr Basismaßnahmen zur Absicherung der digitalen Kommunikation auf dem Niveau eines Sicherheitsgurts im Auto. Dazu gehört die mit Transport Layer Security (TLS) gesicherte Einlieferung einer E-Mail beim dafür zuständigen Mail-Server, damit sie unterwegs niemand mitlesen oder fälschen kann.

Für einen Test, wie solide Deutschland da aufgestellt ist, bietet die Bundestagswahl eine gute Gelegenheit. Der Bundeswahlleiter hat die E-Mail-Adressen aller Wahlleiter dokumentiert. Es ist unmittelbar einsichtig, dass die beschriebenen Anforderungen bei der Kommunikation in Wahl-Angelegenheiten unverzichtbar sind.

78 Behörden-Server mit Problemen

Ob die für E-Mails an die Wahlleiter zuständigen Server das gewährleisten, kann man von außen überprüfen. Wir haben also getestet, ob die Server den grundlegenden Anforderungen gerecht werden, die man an ein solches System stellen sollte. Das Ergebnis war verheerend: Fast ein Viertel der mit dem Transport der behördlichen E-Mail betrauten Server wies signifikante Sicherheitsprobleme auf.

Wir testeten insgesamt 291 offizielle Mail-Domains und fanden bei 66 davon mindestens ein signifikantes Problem. Dahinter stehen insgesamt 340 E-Mail-Server, von denen 78 negativ auffielen. Die Diskrepanzen bei den Zahlen kommen daher, dass einerseits oft mehrere Server für eine Mail-Domain zuständig sind, aber andererseits manche Server mehrere Domains betreuen. Die gefundenen Fehler reichten von ungültigen Zertifikaten bis hin zum kompletten Fehlen der essenziellen TLS-Unterstützung.

Von außen getestet

Kurz zum Ablauf des Tests: Wir extrahierten aus der offiziellen Bekanntmachung des Wahlleiters insgesamt 517 E-Mail-Adressen von Personen, die für die ordnungsgemäße Durchführung der Bundestagswahl verantwortlich sind. Das sind die "Wahlleiter/-innen und ihre Stellvertreter/-innen für die Wahl zum 20. Deutschen Bundestag" wie es dort heißt. Aus denen entnahmen wir mit einem Skript die jeweilige Mail-Domain und ermittelten die jeweils zuständigen Mail-Server. Wer möchte, kann das etwa mit dem Kommandozeilen-Tool dig selbst nachstellen:

$ dig bundeswahlleiter.de MX
...
 bundeswahlleiter.de.    3600    IN    MX    0 mx2.bund.de.
 bundeswahlleiter.de.    3600    IN    MX    0 mx1.bund.de.

So erhält man die beiden für die elektronische Korrespondenz des Bundeswahlleiters zuständigen mx?.bund.de. So ermittelten wir 340 Mail-Server, die wir alle einzeln abgeklappert haben. Sprich: Wir bauten via openssl eine SMTP-Verbindung zu diesen auf und wiesen das Tool an, mit dem Befehl starttls eine verschlüsselte Verbindung zu initiieren.

Schon das scheiterte bei ganzen 5 Mail-Domains. So etwa bei Regensburg und Saarbrücken, deren Backup-Server (mail-prot.regensburg.de, saar1.svsbr.de) den TLS-Aufbau nicht unterstützten (500 5.5.1 Invalid command). Oder Düsseldorf und Darmstadt, deren Mail-Server alle das Kommando starttls glatt verweigerten. Da ist dann nur noch eine völlig ungeschützte Übertragung im Klartext möglich.

Doch es gibt auch Erfreuliches zu vermelden: Der Schwarzwald-Baar-Kreis, dessen noch im Frühjahr publizierte Adressen @schwarzwald-baar-kreis.de keine gesicherte Übertragung zuließen, wechselte auf @lrasbk.de und damit auf eine Mail-Domain, die angemessen gesichert ist. Und keiner der Server versuchte, uns auf veraltete Versionen herunter zu handeln; dort wo TLS funktionierte, konnte man auch mindestens TLS 1.2 verwenden. Und rund 70 beherrschten sogar bereits das aktuelle TLSv1.3.

Kaputte Zertifikate

Die häufigste Fehlerquelle waren die eingesetzten Zertifikate. Mit denen weist der Server nach, dass er auch tatsächlich derjenige ist, mit dem man reden möchte und nicht irgendein zwischengeschalteter Lauscher. Dazu muss natürlich der Name stimmen. Hier schlampten 28 Server-Admins.

Normalerweise bestätigt dann eine vertrauenswürdige Zertifizierungsstelle die Echtheit des Zertifikats, sodass der Überbringer einer Mail das überprüfen kann. Diesen wichtigen Schritt sparten sich einige der Admins und installierten lediglich ein selbstsigniertes Zertifikat ohne externen Echtheitsnachweis. Besonders auffällig demonstrierte ein Server für Mannheim (mannheim.de) dieses Phänomen, der sich mit einem selbstsignierten Cisco-Zertifikat ausweist:

CN=Cisco ESA Certificate,O=Cisco Systems,L=San Jose,ST=California,C=US

Da kann man nur noch hoffen, dass die Mails wahlbuero@mannheim.de trotzdem ohne Umwege ankommen. Ähnliches gilt für die Domain cottbus.de, deren E-Mail-Server sich als "Barracuda/emailAddress=sales@barracuda.com" ausweist und den Landkreis Passau (Sophos SSL CA_C4207AY3TGBTDE3). Sicher geht anders. Übrigens sündigten hier nicht nur regionale Wahlbezirke. Auch der für den Landeswahlleiter des Bundeslandes Thüringen zuständige Server wies nur ein selbstsigniertes Zertifikat vor, das noch dazu bis Ende 2030 gültig sein soll, was ebenfalls gegen Best Practices verstößt. Den Vogel schoss hier der Kreis Steinfurt ab, der seinem Zertifikat sogar bis 2058 vertraut.

Nur wenig besser macht es die Landeshauptstadt München, deren Zertifikat auf muenchen.de zwar von T-Systems beglaubigt wurde, aber nur mit einem CA-Zertifikat, das viele Mail-Server nicht kennen. Insgesamt konnten wir ganze 80 Server-Zertifikate nicht verifizieren.

Acht Server lieferten Zertifikate aus, die nicht mehr gültig sind. Das sind dann häufig schlecht gewartete aber aktive Backup-Server, wie backup.tmt.de für Bayreuth, wo das Zertifikat schon 2016 abgelaufen ist. Da kommen schon ernste Bedenken, was da sonst noch alles im Argen liegen könnte. Es gab aber auch Fälle wie den Landkreis Leer, wo bislang offenbar niemandem aufgefallen ist, dass die Zertifikate für beide Mail-Server schon seit Dezember 2020 nicht mehr gültig sind.

Behörden-Mail mit NSA-Zugang?

Bei unseren Tests fiel uns auf, dass einige Behörden ihre Mail-Server in die Cloud ausgelagert haben. Dabei nutzen etwa landkreis-goslar.de mit der Oracle-Cloud und lkprignitz.de bei TrendMicro/AWS zwar Dienste amerikanischer Firmen. Aber beim Verfolgen der Mail-Verbindungen landeten wir zumindest noch auf Servern in deutschen Rechenzentren.

Ob sich das wirklich mit DSGVO und digitaler Souveränität vereinbaren lässt, ist zumindest fragwürdig. Noch problematischer wird es aber, wenn etwa Mails an wahlen@anhalt-bitterfeld.de über Server von Barracuda Networks in Großbritannien laufen, das ja nicht einmal mehr zur EU gehört.

Einordnung und Bewertung

Keines der gefundenen Probleme stellt ein kritisches Sicherheitsproblem dar, wie es etwa die Sicherheitslücken in Exchange sind. Die ermöglichen den direkten Einbruch in die betroffenen Systeme und geben dem Angreifer unter anderem auch direkte Kontrolle über alle ein- und ausgehenden E-Mails. Bei den hier aufgezeigten Dingen handelt es sich eher um Verstöße gegen die Best Practices der Security, die Bausteine eines verantwortungsbewussten Umgangs mit IT darstellen.

Dass etwa fehlende TLS-Verschlüsselung ein ernstes Problem bedeutet, ist unbestritten. Die Behörden, die Mail-Server ohne TLS-Unterstützung einsetzen, verstoßen grob gegen Sicherheits- und Datenschutzvorgaben. Ihr E-Mail-Verkehr kann auf dem Übertragungsweg komplett mitgelesen werden, sofern nicht explizit Ende-zu-Ende-Verschlüsselung via PGP oder S/MIME eingesetzt wird.

Nicht ganz so klar ist die Sache bei selbstsignierten Zertifikaten. Im Web hat sich nach langen Diskussionen durchgesetzt, dass HTTPS mit überprüfbaren Zertifikaten unverzichtbar ist. In der Diskussion mit Mail-Administratoren stößt man jedoch oft auf die Position, dass selbstsignierte Zertifikate bei Mail-Servern schon in Ordnung seien. Schließlich sei der Mechanismus des Verbindungsaufbaus via starttls ohnehin anfällig für MITM-Angriffe, sodass sich kein neues Problem ergebe.

Das ist zwar technisch korrekt, aber nur ein typischer Whataboutismus, der in einer Diskussion um Armut in Deutschland auf Hunger in Afrika verweist. Überprüfbare Zertifikate sind für sichere Kommunikation unabdingbar; selbstsignierte Zertifikate zementieren einen unsicheren Status quo. Die privatwirtschaftliche Initiative "E-Mail made in Germany" wirbt etwa damit, dass ihre Server untereinander ausschließlich über TLS gesichert kommunizieren und damit eben nicht mehr trivial abhörbar sind. Damit ist eine Mail von Heinz bei T-Online an Emma bei GMX besser abgesichert, als die zwischen den Verantwortlichen für die Bundestagswahl. Das ist nicht akzeptabel.

Wenn das bei kommerziellen Mail-Anbietern möglich ist, sollte es doch etwa für die Kommunikation von Behörden untereinander ebenfalls anzustreben sein. Dazu ist es aber notwendig, zu akzeptieren, dass selbstsignierte Zertifikate sehr wohl ein Problem darstellen, weil sie nicht nur zum unsicheren Status quo beitragen, sondern auch eine Verbesserung der aktuellen Situation verhindern.

Ein Verzicht auf ordentlich überprüfbare Zertifikate ist auch deshalb fatal, weil das eine wirklich sichere Konfiguration aller anderen Server verhindert. Um ihre Mail abzuliefern, müssen mit der Auslieferung betraute Server nämlich nicht überprüfbare Zertifikate akzeptieren. Mit den einfach nutzbaren, kostenlosen Zertifikaten etwa von Let's Encrypt gibt es auch kein Argument für den Verzicht auf korrekt signierte Zertifikate.

Einen interessanten Weg beschreiten übrigens einige Kommunen, die bereits DANE einsetzen. So nehmen insbesondere einige bayrische Behörden ihre Mail über mail.bayern.de entgegen. Dieser Server weist sich zwar mit einem Zertifikat aus, das nicht von einer der herkömmlichen Zertifizierungsstellen unterschrieben ist, sondern mit "Bayerische DANE-CA".

Deren Zertifikat wiederum ist korrekt via DANE im Domain Name System hinterlegt. DANE für SMTP ist eine vielversprechende Technik zur Verbesserung der E-Mailsicherheit. Und obwohl openssl bei den bayrischen DANE-Zertifikaten Warnungen ausgibt, haben wir diese nicht als problematisch in unsere Bilanz aufgenommen. Die anderen DANE-Nutzer setzen übrigens Zertifikate ein, die sich auch auf dem herkömmlichen Weg über bekannte Herausgeberzertifikate prüfen lassen.

Fazit

Das Ergebnis unserer Tests ist schockierend. Fast ein Viertel der für die Kommunikation mit den Wahlleitern angegebenen offiziellen E-Mail-Server genügt nicht den Basisanforderungen an die Sicherheit. Man darf dieses Ergebnis aber auch nicht überdramatisieren. Keines der hier aufgeführten Sicherheitsprobleme bedeutet, dass unsere Wahlen unsicher wären oder damit eine unmittelbare Wahlfälschung möglich wäre. Schließlich ist zu hoffen, dass wirklich sensible Dinge wie Auszählungsergebnisse wirksam Ende-zu-Ende-verschlüsselt und digital signiert werden.

Aber dass ausgerechnet der bereits digitalisierte Teil der Bundestagswahl, nämlich die elektronische Kommunikation mit den Verantwortlichen, auf eine derartig marode Infrastruktur aufsetzt, ist symptomatisch für die Digitalisierung der deutschen Verwaltung. Es ist ein Armutszeugnis, das auch keineswegs nur die Bundestagswahl betrifft. Denn schließlich werden Mail-Adressen wie @duesseldorf.de oder @mannheim.de auch für viele andere Behördenaufgaben genutzt. Der Test liefert also einen recht guten Überblick zum Zustand der Digitalisierung im deutschen Behördenwesen.

Eine Anekdote zum Schluss: Dieser Artikel entstand überhaupt nur, weil einer der Autoren mit einer Behörde in Kontakt treten wollte und sein strikt konfigurierter Mail-Server den Verbindungsaufbau mit dem unsicheren Behörden-Mail-Server verweigerte. Nachdem der von ihm informierte Datenschutzbeauftragte auf diesen Missstand monatelang nicht reagierte, nahm er Kontakt mit heise Security auf. Diese Behörde hat aber zwischenzeitlich ihre E-Mail-Server auf Vordermann gebracht und taucht nicht mehr in den negativen Testergebnissen auf.

Nachtrag: Die durchgeführten Tests dokumentieren die von uns auf Github bereitgestellten Skripte genauer. Dort findet sich auch eine SQLite-Datenbank mit den detaillierten Ergebnissen unserer Tests von Anfang Juli. Die im Text aufgeführten Beispiele haben wir am 25. August erneut verifiziert. Wer möchte, kann Mail-Servern auch selbst mit einem Scan-Dienst wie CheckTLS oder SSL-Tools auf den Zahn fühlen.

(ju)