Dieser Artikel ist weder als rechtliche Bewertung einzustufen noch geht es um eine technische Abhandlung zur Funktionsweise und/oder Implementierung von Verschlüsselungsmechanismen. Es handelt sich im folgendem um eine vereinfachte Darstellung. Aussagen wie „…es besteht aber die Möglichkeit“ (theoretisch), sind nicht in jedem Fall zielführend.
Die Motivation für diesen Artikel entstand in Anlehnung an gerichtlichen Entscheidungen und den daraus publizierten Medienartikeln zum Mythos "E-Mail - eine transportgesicherte Datenübertragung per TLS ist nicht ausreichend" oder eine E-Mail ist wie eine "offene Postkarte".
Ein ähnlicher Mythos kursiert beim Thema "IP-Adresse sind ein personenbezogenes Datum", also alle IP-Adressen? Solche und ähnliche Mythen entwickeln sich, weil der konkrete Sachverhalt, welcher zu einem Zeitpunkt zu einer Entscheidung geführt hat, nicht mehr weiter interessant erscheint. Bei den meisten Medienartikeln wird dann nur noch globalisiert und nicht mehr auf den Einzelfall -wie es zur Entscheidung kam- differenziert berichtet.
Die Sicherheit von E-Mail-Kommunikation oder per Webbrowser ist ein zentrales Anliegen in der heutigen digitalen Welt. TLS (Transport Layer Security) ist ein Protokoll, das entwickelt wurde, um die Sicherheit von Daten, die über Netzwerke übertragen werden, zu gewährleisten. Also nicht nur E-Mail, sondern auch andere Datenübertragungen im Internet.
Das Mitlesen von Transport Layer Security (TLS) Datenverkehr ist in der Regel (mehr dazu unter Technisch) nicht möglich, da TLS eine Verschlüsselungstechnologie ist, die dazu dient, die Vertraulichkeit und Integrität der Daten zu schützen, die zwischen einem Client und einem Server (Punkt-zu-Punkt oder Ende-zu-Ende) übertragen werden. Wenn die Verbindung ordnungsgemäß konfiguriert ist -und davon geht der Anwender aus- sind die Daten, die über TLS gesendet werden, für Dritte unlesbar. An dieser Stelle ist zu erwähnen, dass es sich bei verschlüsselten Daten grundsätzlich auch um Daten handelt.
Es ist auch nicht zu verschweigen, dass es eine hundertprozentige Sicherheit nicht gibt. Beispiele für potentielle Angriffspunkte sollen deshalb am Ende des Artikels nicht unerwähnt bleiben.
1. Abkürzungen
Zunächst, sollen einige Grundbegriffe die im weiteren Verlauf verwendet werden, erläutert werden. (Fachleute können diesen Abschnitt ignorieren.)
TOMs
TOM ist eine in der Praxis gebräuchliche Abkürzung für „Technische und organisatorische Maßnahmen“. TOMs dienen u.a. dazu, die Sicherheit personenbezogener Daten zu gewährleisten und das Risiko von Datenpannen zu minimieren.
TLS
Transport Layer Security (TLS) ist ein kryptografisches Protokoll, das die Kommunikation über ein Computernetzwerk sichert. Es bietet Datenschutz und Datenintegrität zwischen zwei kommunizierenden Anwendungen. TLS wird häufig in Webbrowsern (https://) und E-Mail-Clients verwendet, um sicherzustellen, dass die übermittelten Daten nicht von Dritten abgefangen oder manipuliert werden können. Zum besseren Verständnis: TLS baut einen sicheren Übertragungsweg auf, bei dem die Daten während des Transports von einem Punkt zum nächsten Punkt gesichert (kryptographisch) übertragen werden.
SMTP/SMTP-Server
Ein SMTP-Server (Simple Mail Transfer Protocol) ist ein Server, der für den Versand von E-Mails verantwortlich ist. Er verwendet das SMTP-Protokoll, um E-Mails von einem E-Mail-Client (wie Outlook oder Thunderbird) an einen E-Mail-Server oder zwischen verschiedenen E-Mail-Servern zu übertragen. SMTP ist ein textbasiertes Protokoll, das auf TCP/IP basiert und definiert, wie E-Mails über das Internet übertragen werden.
SMTP-Server sind hauptsächlich für den Versand von E-Mails zuständig. Wenn Sie eine E-Mail senden, wird sie zunächst an den SMTP-Server Ihres E-Mail-Anbieters gesendet, der sie dann an den entsprechenden Empfänger (auch ein SMTP-Server) weiterleitet.
Hops
E-Mails werden in der Regel über das Simple Mail Transfer Protocol (SMTP) gesendet. Wenn eine E-Mail von einem Absender zu einem Empfänger gesendet wird, durchläuft sie möglicherweise mehrere Server (Hops), bevor sie ihr Ziel erreicht. Jeder dieser Hops kann potenziell ein Sicherheitsrisiko darstellen, insbesondere wenn die Verbindung nicht gesichert ist.
Die Anzahl der Hops, die eine E-Mail vom Sender zum Empfänger durchläuft, können stark variieren und hängt von mehreren Faktoren ab, darunter: E-Mail-Server, Anti-Spam Systeme, E-Mail-Routing, u. ä.
Im Durchschnitt kann eine E-Mail zwischen 1 und 10 Hops durchlaufen, aber in einigen Fällen kann es auch mehr sein. Um die genaue Anzahl der Hops zu ermitteln, kann man die E-Mail-Header analysieren, die Informationen über den Weg der E-Mail enthalten.
StartTLS
StartTLS ist eine Erweiterung des SMTP-Protokolls, die es ermöglicht, eine bestehende ungesicherte Verbindung in eine gesicherte Verbindung zu verwandeln. Wenn ein E-Mail-Client eine Verbindung zu einem SMTP-Server herstellt, kann er anfordern, dass die Verbindung mit TLS gesichert wird. Dies geschieht in der Regel, bevor die E-Mail-Daten übertragen werden.
E2EE
Während TLS die Verbindung zwischen den Servern sichert, schützt es nicht unbedingt die E-Mail selbst (also den Inhalt der Nachricht). Für eine vollständige Sicherheit kann Ende-zu-Ende-Verschlüsselung (E2EE) verwendet werden, bei der die E-Mail-Inhalte vor dem Senden verschlüsselt werden. Nur der Empfänger kann die E-Mail entschlüsseln, was zusätzlichen Schutz für den Inhalt bietet.
Der Weg - SMTP funktioniert per TCP
Die Datenpakete, die über SMTP per Transmission Control Protocol (TCP) vom Sender zum Empfänger gesendet werden, nehmen nicht immer denselben Weg. Hier sind einige Gründe, warum dies der Fall ist: Dynamisches Routing, TCP-Segmentierung, Lastverteilung, Redundanz und Fehlertoleranz, u. ä.
Insgesamt ist es also möglich, dass die Datenpakete, die eine E-Mail über SMTP vom Sender zum Empfänger transportieren (z.B. per TLS), unterschiedliche Wege durch das Netzwerk nehmen, abhängig von den oben genannten Faktoren.
Pakete zusammenbauen
Die Pakete, die über Transmission Control Protocol (TCP) gesendet werden, werden am Zielort, also beim Empfänger, wieder zusammengesetzt. Falls Segmente fehlen oder verloren gegangen sind, kann TCP diese erneut anfordern, um sicherzustellen, dass die gesamte Nachricht korrekt und vollständig ankommt. Erst nachdem alle Segmente empfangen und zusammengesetzt wurden, übergibt TCP die vollständige Nachricht an die Anwendungsschicht, in diesem Fall an den SMTP-Server oder den E-Mail-Client, der die E-Mail verarbeitet.
Dieser Prozess stellt sicher, dass die Datenintegrität gewahrt bleibt und dass die Nachricht in der richtigen Reihenfolge und ohne Verlust ankommt.
Ruhende Daten
Ruhende Daten (auch als "at rest data" bezeichnet) sind Daten, die in einem Speicher gespeichert sind und sich nicht in Bewegung befinden. Das bedeutet, dass sie nicht aktiv übertragen oder verarbeitet werden, sondern einfach in einem Speicherort wie einer Festplatte, einer Datenbank oder einem Cloud-Speicher liegen. Ruhende Daten sind z.B. Backups, Dateien die gerade nicht verwendet werden u. ä.
2. Organisatorisch
Eine Grundsatzfrage die sich in dem Zusammenhang stellt, ist: Müssen überhaupt alle E-Mails verschlüsselt werden?
Eine Ende-zu-Ende-Verschlüsselung (E2EE) ist nicht gesetzlich vorgeschrieben, aber ihre Verwendung kann in bestimmten Kontexten empfohlen oder gefordert werden, insbesondere in Bezug auf den Schutz sensibler Daten. In der Europäischen Union verpflichtet die DS-GVO (u.a. Datenschutzgesetze) Unternehmen und Einrichtungen, angemessene Sicherheitsmaßnahmen zum Schutz personenbezogener Daten zu ergreifen. Die geeigneten technischen und organisatorischen Maßnahmen (TOMs) sollten demnach ein Schutzniveau bieten, das dem jeweiligen Risiko angemessen ist.
Bei der Übermittlung personenbezogener Daten mit normalem Schutzbedarf kann in bestimmten Fällen auf eine Ende-zu-Ende-Verschlüsselung der Inhalte verzichtet werden. Die Aufsichtsbehörden fordern jedoch als Mindeststandard eine Transportverschlüsselung (TLS) für solche Datenübertragungen.
Wenn Daten mit hohem oder sehr hohem Schutzbedarf, wie beispielsweise Gesundheitsdaten oder Geheimnisse, per E-Mail versendet werden, ist eine Ende-zu-Ende-Verschlüsselung erforderlich. In dem Fall ist zu beachten, dass damit nicht die Metadaten die für den Transport der E-Mail erforderlich sind, geschützt werden. Deshalb sollte der Absender darauf achten, dass der Betreff der E-Mail auch keine sensiblen (oder zu schützende) Informationen enthält, da diese nicht mit verschlüsselt werden.
Es ist unstrittig, dass es sich bei Adressangaben von natürlichen Personen um personenbezogene Daten handelt. Auf die Frage, ob es sich in jedem Fall um besonders schützenswerte personenbezogene Daten handelt, soll hier nicht weiter eingegangen werden.
Obwohl E2EE nicht gesetzlich vorgeschrieben ist, wird sie in vielen Kontexten als beste Praxis angesehen, um die Vertraulichkeit und Sicherheit von Daten zu gewährleisten. Betriebe, Einrichtungen und Einzelpersonen sollten die spezifischen Anforderungen in ihrem Bereich sowie die geltenden rechtlichen Vorgaben berücksichtigen, um zu entscheiden, ob und in welchem Umfang E2EE implementiert werden sollte.
Die Antwort auf die Frage kann man so beantworten: Ja, für die Transportverschlüsselung, aber nicht immer für die End-to-End-Verschlüsselung. Also dem Risiko der zu übermittelten Daten angemessen. In der Praxis wird in der Regel TLS ggfs. mit weiteren Verfahren wie z.B. SPF, DKIM verwendet.
Für eine Privat-zu-Privat Kommunikation ergibt sich aus den geltenden Datenschutzgesetzen keine Anwendung.
3. Technisch
Auszug BSI: E-Mail-Verschlüsselung in der Praxis (Link siehe am Ende)
Für den sicheren Austausch von Daten zwischen einem E-Mail-Client und einem E-Mail-Server werden heute meistens verschlüsselte Kanäle benutzt. Dies wird z.B. durch das Verschlüsselungsprotokoll Transport Layer Security (TLS) ermöglicht, das auch bei HTTPS-Verbindungen zum Einsatz kommt. Anfangs- und Endpunkt des Datenflusses sind dabei meistens über mehrere Server oder Punkte miteinander verbunden. An diesen Punkten liegen die Daten unverschlüsselt vor, bevor sie für das nächste Teilstück der Strecke wieder durch einen verschlüsselten Kanal geschickt werden. Deshalb wird hier auch von Punkt-zu-Punkt-Verschlüsselung gesprochen.
Auszug aus Urteil Az. 12 U 9/24
(Rn.84): Internetkriminelle könnten einen "Man-in-the-Middle-Angriff" durchführen, der auf diese Punkte ausgerichtet ist. Bei diesem Angriff platziert sich ein Angreifer "in der Mitte" der Kommunikation zwischen zwei Kommunikationspartnerinnen oder -partnern und kann ohne deren Wissen Daten (z.B. E-Mails) abfangen, kopieren oder verändern.
(Rn.104): Die von der Klägerin aufgezeigten Unterschiede zu früheren (Abschlags-)Rechnungen betreffend die Farbe, Angaben zum Geschäftsführer, fehlenden QR-Code der Bankverbindung und fehlendes Siegel stellen geringfügige äußere Abweichungen dar, die weder der Beklagten noch dem Zeugen A. bei oberflächlicher Betrachtung auffallen mussten.
Bei der Verwendung von TLS (Transport Layer Security) während des Transports besteht theoretisch die Möglichkeit eines Man-in-the-Middle (MitM) Angriffs, jedoch sind die Risiken und die Wahrscheinlichkeit solcher Angriffe durch die Sicherheitsmechanismen von TLS erheblich reduziert. Ein Angreifer versucht, sich heimlich zwischen den Kommunikationspartnern zu positionieren, um Daten abzufangen, zu lesen oder zu manipulieren. Dies kann geschehen, wenn der Angreifer den Datenverkehr umleitet oder die Verbindung zwischen den beiden Parteien stört.
An welchem Punkt wären realistische „Abgreifpunkte“, an dem auch alle Datenpakete zur Verfügung stehen? Zur Erinnerung, die Datenpakete für eine E-Mail müssen protokollbedingt (TCP) nicht denselben Weg nehmen.
Abbildung aus KDSA Ost, 5. TB 2020 Abs. 7.2
Unterschiedliches Verständnis - Ende-zu-Ende Verschlüsselung oder TLS, z.B. bei E-Mail
Relativ unwahrscheinliche/schwierige Möglichkeiten:
- Die betroffene Internetleitung suchen, diese dann durchtrennen, um an Informationen zu gelangen,
- Endpunkte der Betreiber der Telekommunikationsleitungen abgreifen,
- Endpunkte in den Rechenzentren abgreifen, auch wenn hier die ruhenden Daten für kurze Zeit unverschlüsselt vorliegen, bis sie wieder per TLS auf den Weg geschickt werden.
Nach der Abbildung wären für einen MitM-Angriff am besten geeignet die Endpunkte des Absenders oder des Empfängers (M.A1, M.B1). Für den Fall, dass ein Angreifer Zugang zu diesen Punkten hätte, befände er sich mit großer Wahrscheinlichkeit im Territorium der lokalen Infrastruktur und könnte weitaus mehr Schaden anrichten.
In der Regel erfolgt eine E-Mail-Kommunikation auf einem direkten Weg. In einigen Fällen sind vor einer Zustellung an das Postfach Sicherheitssysteme als Eingangstor eingebunden. Diese befinden sich entweder in der Infrastruktur der E-Mail-Systembetreiber beim Empfänger oder Absender oder können als Dienst bei einem Provider angemietet werden.
In der folgenden Abbildung befinden sich die E-Mail-Systeme in einer lokalen Infrastruktur. E-Mails werden per TLS versendet und empfangen. Optional können weitere Sicherheitssysteme (G.X) mit involviert sein. Zusätzliche Endpunkte wären dann, ähnlich wie in der ersten Abbildung, beim Rechenzentrumsbetrieb. Diese Verbindungen können als sicher angesehen werden.
Nach dieser Abbildung wären für einen MitM-Angriff die Endpunkte im lokalen Netzwerk (A1, B1) am besten geeignet.
Anmerkungen zu einer gefälschten Anlage in einer E-Mail an Hand der Abbildungen
Für den Fall, dass ein Angreifer nicht gerade Zugriff auf die Endpunkte hat, an denen die vollständigen Datenpakete zusammengebaut sind, erweist sich ein Mitlauschen einer TLS gesicherten Datenübermittlung als unwahrscheinlich. Je nachdem welche zusätzlichen Verfahren für die E-Mail-Domain aktiviert sind (SPF, DKIM, DMARC, etc.) und Absender- wie als auch Empfänger-Systeme die entsprechenden Überprüfungen vornehmen, würde eine Manipulation der beweglichen Daten nicht zum Erfolg führen.
Ein Gericht musste über einen Fall, bei dem ein Hacker eine Endrechnung, die als E-Mail-Anhang, versandt worden ist, entscheiden. In der Rechnung wurde eine andere Bankverbindung angegeben. Die versandte Rechnung unterschied sich aber im Aussehen, von den zuvor von dem Unternehmen an den Rechnungsempfänger versandten Rechnungen.
Anzunehmen war, dass der Angreifer wahrscheinlich nicht das Originaldokument hatte. Denn wenn er das gehabt hätte, wäre lediglich eine Änderung der Bankverbindung notwendig gewesen. Damit wäre eine Manipulation noch weniger ersichtlich.
An Hand der Metadaten (Kopfdaten) einer E-Mail-Kommunikation ist mit wenigen Handgriffen der Weg, über den eine Nachricht vom Absender zum Empfänger gelangt, feststellbar.
4. Phishing-Attacke über Outlook Webzugriff (OWA)
Artikel der KDSA Ost, Phishing - (k)eine schöne Bescherung (Link siehe am Ende)
In der Regel tragen sich Kriminelle, die ein fremdes E-Mail-Konto übernehmen, zuerst als Kopie-Empfänger ein und durchsuchen dann das Postfach nach interessanten Informationen. Falls möglich wird die Datenbank inklusive der Kontakte und der Termine „abgezogen“. Mit diesen Informationen könnten gezielte Phishing-Attacken im Namen „vertrauter“ Absender durchgeführt werden.
E2EE: Hat ein Angreifer Zugriff auf das System eines Opfers, so ist nicht in jedem Fall eine Ende-zu-Ende Verschlüsselung ein wirksamer Schutz (wie und was verschlüsselt wurde) vor Kenntnisnahme des Inhalts einer E-Mail.
5. Kopfdaten als Wegbeschreibung
Jede Nachricht enthält Metadaten (Kopfdaten) die für einen Transport unerlässlich sind und deshalb auch nicht verschlüsselt werden. Beteiligte Systeme reichern die Daten mit weiteren Systemdaten an. Damit ergibt sich eine Leserichtung von „unten“ (zuerst) nach „oben“ (zuletzt). Es folgt ein Beispiel (gekürzt) mit mehreren Hops. Daran ist eine mehrmalige (Punkt-zu-Punkt) TLS-Verschlüsselung zu erkennen. U.a. ist ersichtlich, dass es sich im Grunde genommen nur um zwei Infrastrukturen handelt. Zum einen die des Absenders, der die Nachricht an die Umgebung von Outlook.com übergibt und zum anderen die des Empfängers. Damit kann in der Regel der Weg einer E-Mail-Kommunikation transparent nachverfolgt (analysiert) werden.
From: xxx; To: xxx; Subject: TEST mit E-MAIL und dem Transport von A zu B
- Received: from xxx.EURPRD10.PROD.OUTLOOK.COM (::1) by xxx.EURPRD10.PROD.OUTLOOK.COM with HTTPS;
- Received: from xxx.FRAP264.PROD.OUTLOOK.COM () by xxx.EURPRD10.PROD.OUTLOOK.COM () with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384)
- Received: from xxx.eurprd05.prod.outlook.com () by xxx.outlook.office365.com () with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384)
- Authentication-Results: spf=pass (sender IP is xxx) smtp.mailfrom=kdsa-ost.de; dkim=pass (signature was verified)
- Received: from xxxx by xxx.mail.protection.outlook.com () with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384)
- DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kdsa-ost.de ;
- Received: from xxx with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384)
- ...
6. Potentielle Risiken
Die nachfolgenden Informationen beziehen sich nicht ausschließlich auf TLS im E-Mail-Verkehr. TLS kommt weitreichend zum Einsatz, u.a. für Verbindungen mit Banken, bei Mobile-Apps, Telefonie über das Internet u.v.m.
Es gibt einige Szenarien, in denen es möglich sein könnte, TLS-Datenverkehr zu überwachen oder zu entschlüsseln. Regelmäßig wird in den Medien u.a. der „Man-in-the-Middle-Angriffe (MitM)“ genannt.
Ein MitM-Angriff ist fast immer möglich. Die Frage ist nur, an welcher Stelle, mit welchem Aufwand und kann ich die dort abgefangenen Daten auch nutzbar machen?
Ein Angreifer könnte beispielsweise versuchen, sich zwischen den Client und den Server zu schalten, um den Datenverkehr abzufangen. Dies erfordert jedoch, dass der Angreifer in der Lage ist, das Vertrauen des Clients in das Serverzertifikat zu untergraben. Allerdings muss dies an einer Stelle geschehen, an der auch alle Datenpakete abgefangen werden können. Denn es ist nicht auszuschließen, dass die einzelnen Datenpakete auf unterschiedlichen Wegen zu den Endpunkten gelangen.
Einige Angriffspunkte die allerdings nicht ausschließlich TLS betreffen:
- Sender- und Empfängergeräte: Die E-Mail kann auf dem Gerät des Absenders oder des Empfängers abgefangen werden, bevor sie verschlüsselt oder nachdem sie entschlüsselt wurde. Malware oder Keylogger auf diesen Geräten können die E-Mail-Inhalte erfassen.
- E-Mail-Clients: Wenn der E-Mail-Client des Benutzers nicht sicher ist oder Schwachstellen aufweist, können Angreifer möglicherweise auf die E-Mail-Inhalte zugreifen.
- Zertifikatsüberprüfung: Wenn der Angreifer in der Lage ist, ein gefälschtes Zertifikat zu präsentieren und der Client (z. B. ein Webbrowser) dieses Zertifikat nicht korrekt überprüft, kann der Angreifer die Verbindung abfangen und manipulieren. Dies kann geschehen, wenn der Client nicht auf die Gültigkeit des Zertifikats, die Zertifizierungsstelle (CA) oder den Domainnamen achtet.
- Unsichere Netzwerke: In unsicheren Netzwerken, wie öffentlichen WLANs, kann ein Angreifer versuchen, sich zwischen den Client und den Server zu schalten. Wenn der Client nicht sicherstellt, dass die Verbindung über TLS gesichert ist, könnte der Angreifer den Datenverkehr abfangen.
- Protokollanfälligkeiten: Wenn veraltete oder unsichere Versionen von TLS oder schwache Verschlüsselungsalgorithmen verwendet werden, können Angreifer Schwachstellen ausnutzen, um die Verbindung zu kompromittieren. Beispielsweise könnten Angreifer Protokollangriffe wie POODLE oder BEAST ausnutzen.
- DNS-Spoofing: Wenn ein Angreifer in der Lage ist, DNS-Anfragen zu manipulieren, kann er den Client auf einen gefälschten Server umleiten, der ein gültiges, aber gefälschtes Zertifikat präsentiert. Wenn der Client das Zertifikat nicht überprüft, kann der Angreifer den Datenverkehr abfangen.
- Client- und Server-Implementierungen: Schwächen in der Implementierung von TLS auf der Client- oder Serverseite können ebenfalls Angriffsflächen bieten. Beispielsweise könnten Fehler in der Handhabung von TLS-Sitzungen oder in der Validierung von Zertifikaten ausgenutzt werden.
- Downgrade-Angriffe: Angreifer können versuchen, eine Verbindung zu einem weniger sicheren Protokoll zu erzwingen, um die TLS-Verschlüsselung zu umgehen. Dies kann durch Man-in-the-Middle-Angriffe geschehen.
7. Fazit
Obwohl TLS eine wichtige Schutzschicht für die Kommunikation bietet, ist es nicht unfehlbar. Um sich vor MitM-Angriffen zu schützen, ist es wichtig, sicherzustellen, dass TLS korrekt implementiert ist, dass Zertifikate ordnungsgemäß überprüft werden und dass aktuelle, sichere Versionen von TLS verwendet werden.
Durch die Transport-Sicherheit (TLS) wird sichergestellt, dass Daten beim Datentransport zwischen zwei Punkten (z.B. E-Mail-Client und E-Mail-Server oder Webbrowser und Webserver) nicht mitgelesen werden können. Bei TLS (wo nur der Transportweg verschlüsselt/gesichert ist) liegen die ruhenden Daten beim Client und beim Empfängersystem nicht mehr durch TLS verschlüsselt vor. Ob die ruhenden Daten an den Endstellen unverschlüsselt vorliegen, ist abhängig vom Anbieter/Provider. Diese unterliegen u.a. hohen Sicherheitsanforderungen, so dass ein Zugriff auf ruhende Datenbestände als eher unwahrscheinlich angesehen werden kann.
Die Wege die eine E-Mail vom Absender bis zum Empfänger beschreitet, lassen sich an Hand der Kopfdaten analysieren. Darin enthalten sind u.a. die TLS-Versionen und DKIM Informationen.
Privatanwender nutzen vermehrt die Onlineportale der Dienstleister, um auf ihre E-Mails per Webbrowser zuzugreifen. Damit wäre ein Weg -vom E-Mail-Anbieter zum E-Mail-Client des Anwenders- eingespart.
Wer mit dem Webbrowser unterwegs ist und Websites mit „https“ aufruft (z.B. Bank, Shops, etc.) verwendet u.a. auch TLS (früher SSL). Wären in dem Fall die Kommunikationsstrecken auch als unsicher zu betrachten oder wäre das unter dem Begriff E2EE einzustufen?
Für den E-Mail-Verkehr können noch weitere Sicherheitsvorkehrungen getroffen werden, wie z.B. SPF, DKIM, DMARC. Domain Keys Identified Mail (DKIM) z.B. fügt E-Mails eine verschlüsselte Signatur hinzu, anhand derer die Server der Empfänger überprüfen können, ob die E-Mail wirklich von der Domäne stammt und nicht während der Übertragung manipuliert wurde.
Ein sinnvolles Ausspähen würde nur an den Netzwerkpunkten der Endstelle gute Ergebnisse bringen. Der Aufwand für einen Angriff auf eine Datenleitung z.B. in der Erde, die dann schnell mal angezapft wird, ist mit normalen Mitteln kaum zu bewerkstelligen. Für Anbieter gelten zusätzliche gesetzliche Vorgaben wie das Fernmeldegeheimnis und das Telekommunikations-Digitale-Dienste-Datenschutz-Gesetz (TDDDG).
Die Einrichtung einer Ende-zu-Ende-Verschlüsselung sowie der Betrieb über mehrere Jahre hin, kann eine größere Herausforderung für die meisten Benutzer darstellen. Zumal Benutzer unterschiedliche Geräte und Software für ihre E-Mail-Kommunikation verwenden. Oftmals ist dafür eine zusätzliche Software oder Plugins erforderlich. Hinzukommt, dass Empfänger zu dem vom Sender eingesetzten Verfahren, konform sein müssen.
Eine gute Wahl, um sicherer vor unbefugter Kenntnisnahme zu sein, wäre z.B. ein separater Schutz von E-Mail-Anlagen, die sensible und schützenswerte Inhalte enthalten (z.B. PDF, Word, ZIP-Datei mit Kennwortschutz). Der Schutz sollte für die Kommunikationspartner, unter Brücksichtigung von Aufbewahrungsfristen (Archivierung), praktikabel sein.
Quellen und Informationen:
KDSA Ost, 5. TB 2020 Abs. 7.2, Unterschiedliches Verständnis - Ende-zu-Ende Verschlüsselung oder TLS, z.B. bei E-Mail
KDSA Ost, Phishing - (k)eine schöne Bescherung
BSI: Verschlüsselung oder TLS, z.B. bei E-Mail
https://www.bsi.bund.de/dok/11486410
Beschluss vom 20.02.2025 (Az. 16 B 288/23), kein genereller Anspruch auf eine Ende-zu-Ende-Verschlüsselung
Urteil vom 18. Dezember 2024 (Az. 12 U 9/24)
Urteil LG Rostock vom 20.11.2024 (Az. 2 O 450/24)
Urteil des OLG Karlsruhe vom 27. Juli 2023 (Az. 19 U 83/22)
https://www.landesrecht-bw.de/bsbw/document/NJRE001546363
Fernmeldegeheimnis
https://www.bfdi.bund.de/DE/Buerger/Inhalte/Telefon-Internet/TelekommunikationAllg/Fernmeldegeheimnis.html
Hinweis: Bei diesem Artikel handelt es sich um einen Kommentar. Der Kommentar erhebt keinen Anspruch auf Sachlichkeit, sondern soll die Meinungsbildung anregen und ist als Meinungsbeitrag durch Artikel 5 des Grundgesetzes geschützt.