Datenschutzprobleme bei Mailhosting-Anbietern

Als der Informatiker Jon Postel 1982 den Grundstein für das E-Mail-Protokoll SMTP (Simple Mail Transfer Protocol) legte, ging es um die Kommunikation in Forschungsnetzwerken. Verschlüsselung oder eine anderweitige Absicherung der E-Mail-Kommunikation standen noch nicht im Fokus. Das wurde mit der Zeit zum Problem, und so baute man immer mehr Schutzmaßnahmen um SMTP he­rum. Zu einer sicheren Mail-­Infrastruktur gehören heute unter anderem der mit TLS (Transport Layer Security) verschlüsselte Mailtransport per SMTP unter Mailservern sowie DNS-Einträge für die Verfahren SPF (Sender Policy ­Framework; legt fest, welche Server für eine Domain verschicken dürfen), DKIM (eine serverseitige Signatur aller Mails) und DANE (siehe Kasten auf Seite 136). Eine ausführliche Einführung in die Mail-Protokolle und etablierte Sicherheitsmaßnahmen finden Sie in [1].

Sicheres Mailen ist beileibe kein theoretisches Problem: Mit der europäischen Datenschutz-Grundverordnung (DSGVO) gilt seit drei Jahren ein Gesetz, das Vorgaben zur Sicherheit digitaler Kommunikation macht, sobald personenbezogene Daten verarbeitet werden. Unternehmen, Selbstständige und Vereine sind grundsätzlich für die Sicherheit ihrer ein- und ausgehenden E-Mails verantwortlich. Es ist ihre Aufgabe, Risiken zu minimieren, die sich aus der Verarbeitung personenbezogener Daten in E-Mails ergeben. Weil nur wenige Organisationen ihre Mail-­Infrastruktur komplett auf eigenen Servern im eigenen Rechenzentrum betreiben wollen, überlassen sie diese Aufgabe häufig Dritten – und schließen mit diesen einen Vertrag über Auftragsverarbeitung ab. Gerade kleinere Organisationen buchen die Dienstleistung gern als Paket bei einem Web- und Mailhoster.

Doch ein Auftragsverarbeitungs­vertrag entbindet die Kunden nicht von jeglicher Verantwortung: Wer sich für einen Mailhosting-Anbieter für Verein oder Unternehmen entscheidet, muss prüfen, ob dieser hinreichende Garantien für die E-Mail-Sicherheit bieten kann. Letztlich müssen Sie also selbst dafür sorgen, dass die E-Mail-Kommunikation abge­sichert ist und können sich nicht darauf berufen, dass die Absicherung allein im Aufgabenbereich des Anbieters liegt. Doch wie sieht eine richtige, sprich: rechtssichere Absicherung von E-Mail aus?

Wegweiser

Im Gesetzeswortlaut der DSGVO findet man keine konkreten Technologien zum Schutz ein- und ausgehender E-Mails. Im vergangenen Jahr hat daher die Datenschutzkonferenz (DSK), die Zusammenkunft der deutschen Datenschutzbeauftragten der Länder und des Bundes, ihre ­Anforderungen an die Sicherheit beim Transport von E-Mails in einer Orientierungshilfe zu Papier gebracht und sich dabei am sogenannten „Stand der Technik“ (siehe Art. 32 DSGVO) orientiert. ­Verschiedene Arbeitskreise sollen sicherstellen, dass ein verabredeter Konsens rechtlich und technisch auch umgesetzt werden kann.

In der Orientierungshilfe „Maßnahmen zum Schutz personenbezogener Daten bei der Übermittlung per E-Mail (Download über ct.de/ych4) stehen mehrere konkrete Anforderungen an Verantwortliche. Im Fokus sind Maßnahmen zum Schutz des Transportweges einer E-Mail von einem Mailserver zum anderen, insbesondere der Schutz der Vertraulichkeit und Integrität. Ausdrücklich nicht betrachtet werden Risiken bei bereits empfangenen E-Mails – also etwa die Lagerung in Postfächern der Empfänger und Weiterleitungen.

Die in der Orientierungshilfe geforderten Maßnahmen sind nicht rechtlich verbindlich. Sie spiegeln jedoch die Sichtweise fast aller Behörden wider und dienen als guter Wegweiser – immerhin sind es genau jene Behörden, die Verstöße ­beurteilen und gegebenenfalls sanktio­nieren. Lediglich Bayern hat der Orien­tierungshilfe nicht zugestimmt.

Das Risiko macht den Unterschied

Für den Versand von E-Mails benennt die Orientierungshilfe im Wesentlichen zwei Schutzkategorien: E-Mail-Inhalte mit „normalem“ und solche mit „hohem“ Risiko. Die Orientierungshilfe verweist für eine Einstufung des Risikos auf das Kurzpapier Nr. 18 der DSK (siehe ct.de/ych4). Verantwortliche können sich daher grob daran orientieren, wie sensibel die übertragenen Inhalte in der E-Mail sind. Die DSGVO erläutert beispielsweise in den Artikeln 9 und 10, welche personenbezogenen Daten besonders schützenswert sind. Dazu gehören Gesundheitsdaten oder Daten zum Sexualleben, aber auch genetische und biometrische Informationen einer Person. Verantwortliche, die solche Daten per E-Mail versenden oder entgegennehmen, sollten davon ausgehen, dass sie die Anforderungen für E-Mails mit hohem Risiko erfüllen müssen. Wer aber nur Rechnungen mit der Anschrift einer Person versendet, dürfte sich meist am normalen Risiko orientieren können – doch auch da gibt es Fälle im Grenzbereich.

Aus der Orientierungshilfe der DSK geht keine Sonderbehandlung bestimmter Berufsgruppen hervor. Man könnte annehmen, dass E-Mails von Berufsgeheimnisträgern wie Ärzten, Rechtsanwälten oder Steuerberatern allein wegen ihrer Inhalte automatisch dem hohen Risiko zugeordnet werden müssen. In einem Urteil vom Dezember 2020 hat das Verwaltungsgericht Mainz entschieden, dass dem nicht so ist (AZ 1 K 778/19). Geklagt hatte ein Rechtsanwalt nach einer entsprechenden Verwarnung der Datenschutzaufsicht aus Rheinland-Pfalz. Auch für Berufsgeheimnis­träger gilt also, dass es auf den konkreten Inhalt der E-Mail ankommt. Dennoch sind Berufsgeheimnisträger gut beraten, ihre Infrastruktur so gut es geht an die Maßnahmen für das hohe Risiko anzupassen, auch wenn die Inhalte nicht besonders sensibel sind. Das schafft auch mehr Vertrauen bei den Kommunikationspartnern.

Zutatenliste bei normalem Risiko

Wer einen Mailserver betreibt, muss beim Empfang von E-Mails mit normalem Risiko mindestens den Aufbau einer verschlüsselten Verbindung via TLS ermöglichen. Das ist mit STARTTLS möglich und wird als „opportunistische Verschlüsselung“ bezeichnet. STARTTLS kommt immer dann zum Einsatz, wenn auf einer Leitung sowohl verschlüsselt als auch unverschlüsselt übertragen werden soll. Das ist bei der Kommunikation von Mailservern untereinander auf Port 25 der Fall [1]. Dabei muss der eingehende Mailserver TLS 1.2 oder 1.3 nutzen, die das Bundesamt für Sicherheit in der Informationstechnik (BSI) in der technischen Richtlinie TR-02102-2 als besonders sicher eingestuft hat. Die älteren Versionen TLS 1.0 oder 1.1 sind abgekündigt, was jüngst auch die IETF (Internet Engineering Task Force), bestätigte: Ende März bezeichnete diese die alten Versionen als „deprecated“ (deutsch: veraltet). SSL ist ohnehin seit Jahren nicht mehr Stand der Technik.

Außerdem empfiehlt die Orientierungshilfe das Prüfen von DKIM-Signaturen eingehender E-Mails. Damit wird die Authentizität und Integrität der empfangenen Nachrichten sichergestellt. Ein ­sendender Server mit aktivem DKIM signiert alle Nachrichten mit einem privaten Schlüssel, der zugehörige öffentliche Schlüssel liegt im DNS.

Sollte die Prüfung fehlschlagen, kann das ein Indiz dafür sein, dass die E-Mail gefälscht ist (Mail-Spoofing). In diesem Fall regen die Autoren der Orientierungshilfe dazu an, die E-Mail als Spam zu markieren oder abzuweisen. Ist für die Absenderdomain über einen DMARC-Eintrag im DNS eine E-Mail-Adresse für Benachrichtigungen hinterlegt, sollte der Domaininhaber eine Nachricht bekommen, dass es für seine Domain einen Spoofing-­Versuch gab. So kann er der Ursache für die (möglicherweise gefälschte) Mail auf den Grund gehen. DMARC (Domain-­based Message Authentication, Reporting and Conformance) erweitert die Funktion von SPF und DKIM – im DNS steht ein Rezept, wie mit gescheiterten Prüfungen umzugehen ist.

Für den Versand von Mails mit normalem Risiko fordert die Orientierungshilfe schlicht die Einhaltung der technischen Richtlinie TR-03108-1 des BSI. Das heißt: Verantwortliche sollten möglichst viele derjenigen Punkte der Richtlinie umsetzen, die bei hohem Risiko gefordert sind; eine Verpflichtung hierzu gibt es aber nicht. Konkreteres geht aus der Orientierungshilfe leider nicht hervor. Außerdem müssen Verantwortliche eine „obligatorische Transportverschlüsselung“ sicherstellen, also ihre sendenden Server selbst so einrichten, dass sie zwingend eine verschlüsselte Verbindung zum Empfängerserver aufbauen. Gelingt das nicht, weil der empfangende Server TLS nicht beherrscht, wird die Mail gar nicht verschickt.

Diese Anforderung erinnert an die 2013 gegründete Initiative „E-Mail made in Germany“. Einige deutsche E-Mail-Provider wie GMX, Web.de und die Telekom verpflichteten sich damals, Mails untereinander nur noch transportverschlüsselt auszutauschen. Bei anderen Mailserver-­Betreibern ist die obligatorische Transportverschlüsselung aber bisher kaum verbreitet, weil es immer noch einzelne Mailserver gibt, die keine Verschlüsselung unterstützen. Eine Übertragung der Mails an solche Server wäre sonst nicht möglich. Wer der Orientierungshilfe hier blind folgt, sperrt sich womöglich aus der Kommunikation mit wichtigen Partnern aus.

Anforderungen bei hohem Risiko

Die Aufsichtsbehörden fordern strengere Maßnahmen bei sensiblen Inhalten mit hohem Risiko für die Rechte und Freiheiten natürlicher Personen: Der Empfang von E-Mails muss durch eine „qualifizierte Transportverschlüsselung“ geschützt sein. Zum einen dürfen auf den Mailservern auch hier nur sichere Protokolle wie TLS 1.2 oder 1.3 verwendet werden, die dem Stand der Technik entsprechen. Zum anderen muss sogenannte Perfect Forward Secrecy (PFS) garantiert sein. Dadurch kann eine aufgezeichnete verschlüsselte Kommunikation im Nachhinein nicht entschlüsselt werden, selbst dann nicht, wenn der geheime Schlüssel (der sogenannte Langzeitschlüssel) später versehentlich bekannt wird. Außerdem müssen die Verantwortlichen die für die Mail-­Kommunikation verwendeten DNS-Einträge mittels DNSSEC signieren. So kann man eine Manipulation der DNS-Einträge erkennen [2].

Mit dem Verfahren DANE müssen die Verantwortlichen dafür sorgen, dass die Zertifikatsdaten ihrer Mailserver über das DNS abrufbar sind und auch diesen Record per DNSSEC signieren, um zu verhindern, dass Zertifikate unerkannt ausgetauscht werden. Ein Sender kann damit prüfen, dass er sich auch wirklich mit dem richtigen Mailserver verbindet. Wie DANE in Kombination mit DNSSEC genau funktioniert, erfahren Sie im Kasten „DANE: Kontrolle ist besser“ auf Seite 136.

Als weitere Sicherheitsebene wird ­Ende-zu-Ende-Verschlüsselung (etwa mit PGP oder mit S/MIME) gefordert. Wer sensible Daten empfängt, soll selbst seine öffentlichen Schlüssel bereitstellen und damit verschlüsselte Nachrichten annehmen können. Das scheitert in der Praxis oft an organisatorischen Problemen. Auch mit Standards wie Autocrypt konnten die Verfahren keine massenhafte Verbreitung erzielen, Schwachstelle sind die Anwender.

Die Anforderungen zum Versand von Inhalten mit hohem Risiko sind ähnlich denen auf Empfängerseite: Auch hier müssen Verantwortliche auf Ende-zu-Ende-­Verschlüsselung setzen. Das passiert aber nicht zentral auf Ebene der Serveradministration, sondern ist eine organisatorische Aufgabe – hier müssen die Nutzer aktiv mitspielen. Gleichzeitig ist erneut eine „qualifizierte Transportverschlüsselung“ notwendig: Der ausgehende Mailserver soll also gründlich prüfen, ob er die Nachricht wirklich an den richtigen Server mit dem richtigen Zertifikat zustellt. Das setzt natürlich voraus, dass der Empfänger DANE und DNSSEC implementiert hat.

Admins, die die ganze Infrastruktur in der eigenen Hand haben, können diese Empfehlungen Schritt für Schritt durchgehen, die Konfiguration der eigenen Software anpassen, Einträge für DKIM und DANE im DNS eintragen und mit DNSSEC absichern.

Ist-Analyse

Anders sieht es aus, wenn man auf einen Hosting-Dienstleister setzt. Im Shared-Hosting teilen sich mehrere Kunden einen Server. Meistens reizt ein einzelner Kunde nicht alle Ressourcen des Servers aus; durch das Zusammenlegen mehrerer Kunden spart jeder einzelne Kosten im Vergleich zur Miete eines eigenen Servers. Bei diesem klassischen Webhosting haben die Kunden keine Möglichkeit, Verfahren wie DANE oder eine DKIM-Prüfung selbst umzusetzen – das kann nur der Hosting-Anbieter als Serverbetreiber. Es kommt auf den Willen des Hosting-Anbieters an, ob und wann neue Technologien eingesetzt werden.

Um Ihnen eine Orientierung zu liefern, wie es um die Umsetzung der geforderten Maßnahmen aus der Orientierungshilfe steht, haben wir uns große Hoster in Deutschland genauer angesehen. Die Einrichtung der Verfahren ließe sich prinzipiell automatisieren und für die Hostingkunden bereitstellen. Doch unsere Auswertung zeigt: Die meisten Webhosting-Anbieter hinken mit der Umsetzung hinterher.

Anbietervergleich

Um herauszufinden, welche Hosting-Anbieter die geforderten Maßnahmen umsetzen, haben wir 18 bekannte Anbieter im deutschen Raum unter die Lupe genommen. Dazu suchten wir in Bewertungsportalen nach Beurteilungen der ausgewählten Hoster und schauten gezielt nach Kommentaren, in denen die Kunden ihre eigene Domain erwähnten. Anschließend prüften wir anhand der IP-Adresse, dass die Domain zum gesuchten Anbieter gehört. Das ist über eine Suche bei RIPE, der Vergabestelle für IP-Adressen in Europa, möglich. So hatten wir schnell eine Liste von Domains, mit denen wir die eingehenden Mailserver der Hoster testen konnten – diese Prüfung funktioniert nämlich problemlos aus der Außenperspektive.

Mithilfe von Analysewerkzeugen ­untersuchten wir, ob die Anforderungen für das normale und hohe Risiko erfüllt werden. Diese Werkzeuge stellen, wie ein versendender Mailserver, eine SMTP-­Verbindung her und simulieren unter anderem TLS-Verbindungsaufbauversuche mit verschiedenen TLS-Versionen.

Ob DKIM-Signaturen bei eingehenden Mails geprüft werden, probierten wir teilweise mit Test-Accounts aus, bei einigen Anbieter fragten wir per Mail nach dieser Information. Die Ergebnisse unseres Tests haben wir in der Tabelle unten zusammengefasst. Wenn Sie die Untersuchungen für weitere Anbieter selbst nachvollziehen wollen, finden Sie eine Beschreibung unserer Werkzeuge im ­Kasten „Selbst testen“ auf Seite 134.

Die gute Nachricht: Alle Hosting-Anbieter ermöglichen die opportunistische TLS-Verschlüsselung mittels STARTTLS. Wenn ein fremder Mailserver eine Mail abliefern will, handeln sie also eine verschlüsselte Übertragung aus. Alle getesteten Anbieter unterstützten mindestens TLS 1.2, manche sogar TLS 1.3 (7 von 18). DKIM (10 von 18) und Perfect Forward Secrecy (18 von 18) haben die Anbieter mehrheitlich umgesetzt. Mehr als die Hälfte der Anbieter entspricht in diesen Punkten damit dem Stand der Technik.

Die weniger gute Nachricht: Bei nahezu allen Anbietern konnte man die Mailserver noch auf TLS 1.0 und 1.1 runterhandeln, bei Mittwald sogar auf das längst veraltete SSL 3. Nur bei Profihost ist zum Einliefern von Mails mindestens TLS 1.2 erforderlich, und auch die obligatorische Transportverschlüsselung ist nur bei ­diesem Anbieter standardmäßig aktiviert, sodass keine unverschlüsselte Nachricht versendet wird. Bei Hetzner und UD Media ist die Funktion mit einem eigenen Server gegen Aufpreis möglich.

Die übrigen Anbieter wollen sich und ihren Kunden vermutlich Ärger ersparen und gestatten es, auch mit Mailservern zu kommunizieren, die keine Verschlüsselung unterstützen. Laut Googles Transparenzbericht musste bei Gmail beispielsweise im ersten Quartal dieses Jahres immer noch fast jede zehnte E-Mail (12 %) über eine ­unverschlüsselte Verbindung gesendet werden. Die Forderung nach ­obligatorischer Transportverschlüsselung ist also noch immer nicht durchgehend umsetzbar.

Düster sieht es auch bei DANE und DNSSEC aus: Lediglich dotplex und UD Media unterstützen die Verfahren und damit die sogenannte qualifizierte Transportverschlüsselung. Bei allen anderen Anbietern werden diese Verfahren nicht unterstützt; sie lassen sich auch nicht im Kundencenter aktivieren oder zubuchen.

Unsere Untersuchung macht deutlich: Bis auf die obligatorische Transportverschlüsselung und die Unterstützung für veraltete TLS- und SSL-Versionen haben die Hosting-Anbieter die Maßnahmen für das normale Risiko in der Mehrheit umgesetzt. In den Reihen der getesteten Anbieter gibt es aktuell aber nur wenige, welche die geforderten Sicherheitsgarantien für das hohe Risiko anbieten. Mit etwas Konfigurationsarbeit könnten die Anbieter die Empfehlungen der DSK automatisiert umsetzen. Das Schlüsselmanagement für DANE und DNSSEC könnte im Hintergrund von selbst ablaufen. Die Anbieter würden damit signalisieren, dass sie die E-Mail-Sicherheit im Sinne ihrer Kunden wirklich ernst nehmen. Im Zweifelsfall bleibt es Pflicht der Verantwort­lichen, für die Umsetzung der geforderten Maßnahmen zu sorgen oder einen geeigneten Anbieter zu finden.

Einschätzung

Die in der Orientierungshilfe geforderten Maßnahmen sind ein guter Wegweiser. Dennoch muss man manche Maßnahmen differenziert betrachten: TLS (1.2 und 1.3), DKIM und DANE sichern die Kommunikation auch dann auf der Transportebene ab, wenn der E-Mail-Anwender kein Kryptologe ist. Allerdings wird DKIM nur beim Empfang von E-Mails mit normalem Risiko in der Orientierungshilfe gefordert. Aus unserer Sicht ergibt der Einsatz von DKIM sowohl beim Empfang als auch beim ­Versand von Mails in jedem Fall Sinn. Für gängige Mailserver stehen Module zur Verfügung, und ein DKIM-Record im DNS ist schnell platziert. Auch die Einrichtung von DNSSEC für die eigene Domain ist eine gute Idee.

Als Kunde von Hosting-Dienstleistern hat man leider keine direkte Kontrolle über alle Konfigurationsdetails. Wer möglichst viele Empfehlungen aus dem Papier der DSK umsetzen will, muss bei der Wahl des Dienstleisters genau hinschauen und gegebenenfalls mit den vorgestellten Tools selbst testen – oder den Aufwand in Kauf nehmen und seinen eigenen Mailserver in Betrieb nehmen. (jam@ct.de)

Testwerkzeuge und Dokumente: ct.de/ych4