Emailsicherheit und die Aufsichten

Einige meiner Leser werden natürlich denken, schon wieder Email. Stimmt. Ich werde in diesem Artikel auch so wenig wie möglich aus den vorhergehenden Artikeln wiederholen sondern aufzeigen, wie wenig sich seit Veröffentlichung der Orientierungshilfe geändert hat und woran ich das Scheitern sehe. An Email kann man das Sicherheitsbewusstsein der Nation oder Verwaltung und die Trägheit der Aufsicht (leider) sehr gut ablesen. Dass die Aufsicht über die Schonfrist von Mai 2016 bis Mai 2018 hinaus und drei Jahre nach Veröffentlichung der ersten Orientierungshilfe diese selbst nicht umsetzt, ist ein Verstoß gegen Artikel 32 DSGVO, dass sie bei anderen Verantwortlichen die Datenschutzgrundverordnung nicht durchsetzt, ist in meinen Augen Rechtsbeugung, denn Artikel 57 Abs. 1 lit. a erklärt mit die Anwendung dieser Verordnung überwachen und durchzusetzen das eindeutig zur Aufgabe der Aufsicht, und Artikel 58 liefert auch entsprechende Möglichkeiten dazu.

• Anfrage an die Datenschutzaufsichten
• Änderungsbedarf an der Orientierungshilfe?
• Anfragen und Beschwerden zu mangelhafter Verschlüsselung
• Downgradeangriffe gegen den Emailserver der Aufsicht?
• Kommunikation mit den Aufsichten
• Tests öffentlicher Einrichtungen

Anfrage an die Datenschutzaufsichten

In der Anfrage habe ich zunächst Testergebnisse der Emailkommunikation der Aufsichten selbst verwendet und gefragt, wann man die Orientierungshilfe selbst befolgen wird, und auch ob beabsichtigt ist, die Orientierungshilfe zu verändern. Ich habe auch aufgefordert, sich selbst zu testen, denn die abgehende Konfiguration kann ich nicht ohne Mitwirkung eines Senders prüfen.

Änderungsbedarf an der Orientierungshilfe?

Ich greife den Antworten vor... auch wenn die Aufsichten schreiben Orientierungshilfen werden regelmäßig überprüft und mit weiterhin Gültigkeit keinen Änderungsbedarf sehen, denke ich, dass die Orientierungshilfe nicht erfolgreich ist und würde mir einige Änderungen wünschen. Was sind die Probleme?

• Die Orientierungshilfe knüpft an die Risikoklassifizierung in Kurzpapier Nr. 18: Risiko für die Rechte und Freiheiten natürlicher Personen an. Die DSGVO unterstützt grundsätzlich einen risikobasierten Ansatz, aber wenn der Verantwortliche das Risiko unterschätzt oder verdrängt, kommt halt nichts brauchbares heraus. Und es ist meiner Meinung nach sinnvoller, über Lösungen zu diskutieren als über Risiken.
• Die Orientierungshilfe besagt nichts ausdrücklich zu (vermeintlich) niedrigem Risiko. Beim genauen Lesen fällt einem aber Abschnitt 2 Der gesetzlich gebotene Schutz personenbezogener Daten im Zuge der Übermittlung von E-Mail-Nachrichten erstreckt sich sowohl auf die personenbezogenen Inhalte alsauch die Umstände der Kommunikation, soweit sich aus letzteren Informationen übernatürliche Personen ableiten lassen und Abschnitt 3.1 Zum Schutz der Vertraulichkeit und Integrität der verarbeiteten personenbezogenen Daten müssen öffentliche E-Mail-Diensteanbieter die Anforderungen der TR 03108-1 des Bundesamts für Sicherheit in der Informationstechnik (BSI) einhalten auf. Richtig, neben dem Grundrecht auf Datenschutz gibt es auch noch das Grundrecht auf vertrauliche Kommunikation aka Fernmeldegeheimnis. Das scheinen die Autoren der Orientierungshilfe gewusst zu haben, aber in der Beratungspraxis scheint das keine Rolle zu spielen. Vertraulichkeit ohne Verschlüsselung? Geht nicht.
• Sowohl die obligatorische als auch die qualifizierte Transportverschlüsselung haben das grundsätzliche Problem, dass der Sender Verschlüsselung erzwingen soll, ohne zu wissen, ob der Empfänger das kann. Konfiguriert er das trotzdem, erhalten seine Anwender oder Prozesse – man denke an noreply@... – Nichtzustellbarkeitsnachrichten, mit denen die Anwender und Prozesse oft nichts anfangen können. Darüberhinaus definiert die qualifizierte Transportverschlüsselung nicht, welche Standards konkret verwendet werden dürfen, sollen, oder müssen, was die Kommunikation mit den Informationstechnikern und deren Suche nach geeigneten Lösungen erschwert.
• Der Hinweis auf die BSI TR 03108 ist nur konkret für öffentliche Emailanbieter in Abschnitt 3.1 und sehr vage sollten sich an der TR 03108 orientieren in Abschnitt 4.2.1. Dass die TR 03108 weitgehend übereinstimmt mit SMTP-DANE (RFC 7672) – kein Hinweis darauf.
• Bei hohem Risiko wird sowohl qualifizierte Transportverschlüsselung als auch PGP und S/MIME erwartet, ohne dass klar ist, ob das Alternativen für den Verantwortlichen, alternative Angebote an den Betroffenen sein sollen, oder grundsätzlich alles drei zum Einsatz kommen soll.
• PGP und S/MIME führen ein Nischendasein bei Aufsichten und Enthusiasten, Normalbürger kennen und verwenden es nicht. Verantwortliche wie die Deutsche Post DHL bestätigen das. Und von den wenigen Nutzern verwendet niemand die offiziellen Standards für Schlüsselmanagement, und sollten die sich irgendwann doch durchsetzen wird es als Konsequenz PGP- und S/MIME verschlüsselte Spam geben, die aufgrund der Ende-zu-Ende-Verschlüsselung leider nicht vom Spamfilter erkannt werden können. Und weil die Standards nicht verwendet werden, werden gerne mal öffentliche Schlüssel über eine ungeschützte Email ausgetauscht – das hat mit Sicherheit dann wenig zu tun.
• Auf andere Techniken wie verschlüsselte Zips oder PDFs geht die Orientierungshilfe nicht ein, insbesondere sagt sie auch nicht, dass für den Schlüssel – siehe auch PGP / S/MIME – ein anderer sicherer Kanal verwendet werden muss als unsichere, nicht qualifiziert transportverschlüsselte, Email.

Mir erscheint es wesentlich sinnvoller:

1. Alle Verantwortlichen müssen unabhängig von der Risikoklasse die Verwendung von SMTP-DANE nach RFC 7672 oder BSI TR 03108 in beiden Richtungen umsetzen. Immerhin sind allein durch United-Internet etwa die Hälfte der Bundesbürger damit verschlüsselt und authentifiziert erreichbar, und viele andere Anbieter, leider nicht alle, verwenden diesen Standard auch. Testergebnisse auf Emailsicherheit — der Test.
2. Verantwortliche sollten bei der Erfassung von Emailadresse bereits ab normalem Risiko beispielsweise in einem Kontaktformular prüfen, ob diese Emailadresse SMTP-DANE unterstützt und falls nicht den Betroffenen darauf hinweisen. Bei alten Datenbeständen kann man die auch durchprüfen und den Betroffenen eine Email schicken und darauf hinweisen.
3. Die Forderung nach PGP und S/MIME sollte gestrichen werden.
4. Ein Schlüsselaustausch für die Kommunikation per Email darf nicht per Email stattfinden (oder nur dann, wenn sichergestellt ist, dass beide Seiten SMTP-DANE einsetzen).

Absurd? Nein, in den Niederlanden steht dieser RFC auf der Pflichtliste (siehe DANE for SMTP how-to und dort Suche nach Comply or Explain). Die niederländische nationale Cybersecurity-Center (NCCA) schreibt The NCSC recommends enabling STARTTLS and DANE for all your organisation´s incoming and outgoing email traffic. Die Umsetzung von SMTP-DANE ist leicht, eine ernsthafte Risikoanalyse deutlich aufwändiger. Die Certified Senders Alliance empfiehlt DANE. Und Encrypt Everything ist der neue Trend. Sogar das BSI verlangt im Grundschutz NET.1.1.A7 Verschlüsselung als Basisanforderung unabhängig vom Risiko und liefert für Email die schon angesprochene technische Richtlinie TR 03108, nach der Emailanbieter zertifiziert werden können.

Auch die Prüfung in einem Formular ist kein Problem, ich habe das selbst seit Anfang 2022 im Einsatz. Und warum ich nichts von PGP und S/MIME halte, steht im Vergleich RFC 7672 vs. PGP / S/MIME. Wenn das Unabhängige Landeszentrum für Datenschutz schreibt, geschätzt zwischen 1 und 5 %, dann lässt das nur vermuten, dass datenschutzbewusste Bürger eher bereit sind, PGP zu nutzen als die anderen – und diese anderen sind die Mehrheit.

Wenn man sich den Vorschlag genauer ansieht, wird man feststellen, dass der Zwang zur Verschlüsselung beim Sender ersetzt wird durch die Verpflichtung zu SMTP-DANE und eine geeignete Information des Betroffen bei der Erfassung oder Weiternutzung der Emailadresse, damit das Problem der Fehler massiv reduziert wird und damit der Haupteinwand der Techniker adressiert wird.

Wenn man tatsächlich die Orientierungshilfe anfasst, dann kann man auch gleich noch SPF, DKIM, und DMARC empfehlen. Die Verwendung von MTA-STS hingegen halte ich für entbehrlich – weil MTA-STS ohne DNSSEC eine schlechtere Sicherheit als SMTP-DANE erreicht, und weil die sendeseitige Komplexität im Vergleich zu SMTP-DANE erheblich höher ausfällt, und damit die Umsetzung erheblich seltener stattfindet als die von SMTP-DANE. Und auch wenn man die Orientierungshilfe nicht anfassen will, kann man SMTP-DANE, SPF, DKIM, und DMARC als Schritt in die richtige Richtung einfordern.

Dass man drei Jahre nach Veröffentlichung trotz fehlender Umsetzung keinen Änderungsbedarf sieht – wollen die Aufsichten wegsehen?

Anfragen und Beschwerden zu mangelhafter Verschlüsselung

Dass schiefgehen wird, was schiefgehen kann, zeigen meine Erfahrungen und Beschwerden:

Tabellen überspringen.

Ich kann in keinem dieser Vorgänge erkennen, dass eine Aufsicht vor meiner Anfrage oder Beschwerde zum Thema Email oder der Orientierungshilfe beraten hat.

Downgradeangriffe gegen den Emailserver der Aufsicht?

Ich habe in meiner Anfrage zwar zur Nutzung meines Tests aufgefordert, aber mir war klar, dass den allenfalls eine Minderheit verwenden wird. Zu groß wohl das schlechte Gewissen, die eigene Orientierungshilfe nicht umzusetzen. Aber einer meiner Emailserver für die Domäne lindenberg.one versucht Downgradeangriffe gegen sendende Emailserver. Ausgenommen sind nur einige wenige Sender, die SMTP-DANE verwenden und sofort Fehlermeldungen senden, wenn STARTTLS nicht angeboten wird. Das liefert weniger Informationen als ein vollständiger Test, aber zumindest einen Hinweis ob der sendende Emailserver für obligatorische Transportverschlüsselung konfiguriert ist oder SMTP-DANE (RFC 7672) alias BSI TR 03108 oder MTA-STS (RFC 8461) unterstützt. Wirklich auseinanderhalten kann der Downgradeangriff das leider nicht, dafür braucht es – wie beim Test – zwei unterschiedlich konfigurierte Domänen.

Und da ich Emails – Antworten auf die Anfrage oben und andere – von Aufsichten bekommen habe, kann ich in der Tabelle darstellen, ob die Aufsicht dem Downgradeangriff erlegen ist (✗) oder nicht, also nicht unverschlüsselt gesendet hat (✓). Überraschend dabei Bremen, Hamburg, und Sachsen-Anhalt, denn die haben nicht unverschlüsselt gesendet obwohl sie empfangsseitig keine qualifizierte Transportverschlüsselung unterstützen. Die bayerische Landesanstalt für Datenschutzaufsicht ist sowohl beim Test als auch beim Downgradeangriff durchgefallen. Auch der BfDI hat den Test nicht gemacht, ist aber dem Downgradeangriff nicht erlegen, bei ihm vermute ich, dass er zwar keine obligatorische Transportverschlüsselung verwendet, dafür aber SMTP-DANE verwendet.

Die Empfangsseite findet sich in Aufsichten. Mit anderen Worten: eine einzige von 18 Aufsichten, der BfDI, setzt die Orientierungshilfe oder zumindest SMTP-DANE in beiden Richtungen um. Als Verantwortlicher – auch Aufsichten sind Verantwortliche – muss man dem Auftragsverarbeiter die technischen und organisatorischen Maßnahmen vorgeben oder einen geeigneten Auftragsverarbeiter auswählen, statt akzeptieren was irgendwer anbietet.

Kommunikation mit den Aufsichten

Der Bayerische Landesbeauftragte für den Datenschutz und Berlin haben überhaupt nicht geantwortet. Immerhin keine Ausreden, aber man ignoriert damit das jeweilige Pressegesetz. Thüringen fragt per Email nach meinem öffentlichen Schlüssel und entscheidet sich für den Postweg.

Tut mir leid, da ist wiedermal ganz viel bla, bla, bla, oder auch Ausreden. Ich zitiere Mal stellvertretend den BfDI, und fast wörtlich das gleiche findet sich in vielen anderen Antworten:

Wenn eine Orientierungshilfe nicht die Beratung weitgehend ersetzen kann und nicht umgesetzt wird, dann sollte man sie – siehe oben – verbessern. Von sofort ist keine Rede. Wir reden von inzwischen drei Jahren, die Umsetzung von SMTP-DANE hat bei meinem Emailserver nur zwei Tage gedauert. Dass bei der Beratung im Ergebnis nicht viel passiert ist, zeigen die Statistiken weiter unten – zwischen Januar 2022 und Juli 2023 hat sich an der Umsetzung der qualifizierten Transportverschlüsselung nicht signifikant verändert und sie ist im einstelligen Prozentbereich und damit eindeutig zu niedrig.

Dass Email nicht der einzige Kommunikationsweg ist, ist mir bewusst. Aber von der Briefpost abgesehen ist er einer der wichtigsten und häufigsten verwendeten, und viele Ersatzlösungen (Kontaktformulare einschließlich den von den Aufsichten angebotenen Beschwerdeformularen, Verwaltungsportale, Telekom Encrypting Email Gateway, Julia Mailoffice sind nicht besser und verwenden zur Registrierung, Benachrichtigung oder als Rückkanal auch wieder Email. Und wenn die Briefpost zum Einsatz kommen muss, dann ist das ja wohl eher ein Armutszeugnis für die Digitalisierung in Deutschland, ganz abgesehen davon, dass Drucken, Transport und Entsorgung des Altpapiers klimaschädlicher als eine Email ist, zumindest wenn diese nicht ausgedruckt wird (E-Mail vs. Brief: Wie ist das eigentlich mit der CO2-Bilanz? Klimabilanz: E-Mail vs. Brief).

Der BfDI schreibt in seinem 22. Tätigkeitsbericht zur Beratung bei Email etwas über ausgesperrte Benutzer und Sicherheitsfragen, nicht aber über Verschlüsselung. Möglicherweise habe ich mit meinen Anfragen und Beschwerden mehr bewirkt als die Aufsichten beraten. Mein Email-Sicherheitstest hat inzwischen mehr als 100 Domänen in beiden Richtungen geprüft, und einige Verwender des Tests haben ihren Server daraufhin besser konfiguriert. Und bereits zweimal habe ich für rund 20.000 Domänen öffentlicher Einrichtungen einen Test der Empfangsseite gestartet.

Klartext: die DSGVO ist fünf Jahre in Kraft, die Orientierungshilfe ist drei Jahre alt. Die Orientierungshilfe ist nicht angekommen. Wenn der Beratungsaufwand zu groß ist, dann gehört sie geändert, Vorschläge oben. Wenn die Aufsichten weder die Orientierungshilfe ändern noch durchsetzen, dann scheint es am Willen zu fehlen, und wenn die Aufsicht nicht den Willen hat, die DSGVO durchzusetzen, dann verstößt sie klar gegen Artikel 57 Abs. 1 lit. a.

Tests öffentlicher Einrichtungen

Datenquelle für Tests öffentlicher Einrichtungen

Um erneut das Ausmaß des Problems zu beleuchten habe ich wie im früheren Test die Emailadressen von Frag-Den-Staat verwendet. Rund 20.000 Domänen mit zusammen 40.000 Emailadressen, die im nächsten Schritt auf Basis der von Frag-Den-Staat erfassten "Jurisdiction" einem Bundesland oder dem Bund zugeordnet wurden. Das ist für die Auswertungen natürlich eine Fehlerquelle. Schon mir ist aufgefallen, dass einige Ausländerbehörden dem Bund statt dem Bundesland zugeordnet waren und habe das an Frag-Den-Staat gemeldet, so dass die Rohdaten besser wurden. Dennoch ist diese Zuordnung eine Fehlerquelle, weil die Aufsicht aus Datenschutzsicht nicht unbedingt identisch mit dieser Zuordnung sein muss. Auch sind nach dieser Zuordnung die Arbeitsagenturen und Job-Center Länderaufgabe, aber alle verwenden den gleichen Emailserver der Bundesanstalt für Arbeit. Ich habe daher die Bundesanstalt für Arbeit direkt angeschrieben und Arbeitsagenturen und Job-Center im übrigen herausgefiltert.

Bei den verbleibenden Domänen sind einige nicht mehr existent, haben einen Null MX Record nach RFC 7505 oder haben weder einen MX-Record noch einen A- oder AAAA-Record, und sind damit nicht empfangsbereit. Die wurden aus den Ergebnissen herausgefiltert.

Test und Datenaufbereitung

Die Aufbereitung von den Emailadressen bis zu den fertigten Tabellen wird durch das Diagramm dargestellt:

Die Testroutinen wurden gegenüber den früheren Tests komplett neugeschrieben, primär um genauere Resultate und eine bessere Darstellung für den Email-Sicherheits-Test zu bekommen. Die neue Version vermeidet auch die Unschärfe der damaligen Gruppierung nach Providern auf Basis der letzten zwei Elementen der Domäne. Auch wurden Verbindungsfehler nicht als Fehler gewertet, die (seltenen) DNS-Fehler werden dargestellt.

Testergebnisse und Statistik

Die Testergebnisse nach zuständiger Auskunft finden sich unter den Links der Spalte ganz links. Daraus ergeben sich die aggregierten Ergebnisse der Empfangssituation nach Aufsicht:

Während nahezu alle Behörden empfangsseitig STARTTLS anbieten, sieht es mit der Verwendung von qualifizierter Transportverschlüsselung und SMTP-DANE sehr viel schlechter aus. Der Prozentsatz qualifizierter Transportverschlüsselung ist sogar gesunken. Nahezu unbedeutend ist MTA-STS, zumal MTA-STS nur von wenigen Sendern verwendet wird. Und erneut muss ich hinzufügen, dass viele Verantwortliche nur die von außen sichtbare Empfangsseite verbessern, nicht aber die Sendeseite.