Sicherheit ist eine unserer wichtigsten Prioritäten, zusammen mit dem Datenschutz. Wir arbeiten hart daran, unseren Nutzern die sicherste und vertraulichste Benutzererfahrung bei der Nutzung von Mailfence zu bieten. Viele Nutzer, wie z.B. Journalisten oder Dissidenten, nutzen unseren Service für sensible Kommunikation. Sie sind oft Ziel von fortschrittlichen, hartnäckigen Bedrohungen. In den letzten Jahren haben wir mehrere neue Funktionen veröffentlicht, um die Sicherheit aller Mailfence-Nutzer zu verbessern.
Von DANE bis MTA-STS, WKD und VKS konzentrieren wir uns auf Maßnahmen zur Verbesserung der Sicherheit, um Ihre Daten zu schützen.
Mailfence - Erhalten Sie Ihre kostenlose, sichere E-Mail.
4.1 basierend auf 177 Benutzerbewertungen
Mailfence - Erhalten Sie Ihre kostenlose, sichere E-Mail.
4.1 basierend auf 177 Benutzerbewertungen
DANE und MTA-STS
Weshalb Sie es brauchen
DNS-based Authentication of Named Entities (DANE) und Mail Transport Agent Strict Transport Security (MTA-STS) sind zwei unterschiedliche Protokolle, die sich in erster Linie mit demselben Problem befassen, das gemeinhin als Downgrade-Attacke bekannt ist. Einfach ausgedrückt, kann ein Angreifer die Verschlüsselungsschicht während des Transports von E-Mails entfernen. Daher ist es wichtig, einen Mechanismus zu haben, der sicherstellt, dass die Transportverschlüsselung intakt bleibt, wenn E-Mails von einem Konto zu einem anderen verschickt werden.
In den Anfängen des Internets sendeten und empfingen die E-Mail-Server E-Mails im Klartext – ohne Verschlüsselung auf der Transportschicht. Dies bedeutete, dass jeder, der das Netzwerk überwachte, die Nachricht lesen oder verändern konnte. Nach der Einführung von TLS wurde der E-Mail-Standard so angepasst, dass er die Transportverschlüsselung einschließt, wenn sowohl der sendende als auch der empfangende Server sie unterstützen. Ein Angreifer kann jedoch immer noch den sendenden Server dazu bringen, E-Mails im Klartext weiterzuleiten, indem er fälschlicherweise angibt, dass der empfangende Server die Verschlüsselung auf der Transportschicht nicht unterstützt.
Wie es funktioniert
MTA-STS ist ein Protokoll, das die E-Mail-Zustellung mittels Transportverschlüsselung (nicht zu verwechseln mit der Ende-zu-Ende-Verschlüsselung) sicherstellt, wenn der empfangende Server dies unterstützt. Der sendende Mailserver sucht und speichert die MTA-STS-Richtlinie des empfangenden Mailservers. Je nach MTA-STS-Richtlinie des empfangenden Servers verweigert er dann jeden Versuch, die Transportverschlüsselungsschicht zu entfernen. Der sendende Server setzt auf eine lange Cache-Zeit, um kurzfristige Angriffe zu verhindern. Der Nachteil ist jedoch, dass jeder Mailserver seinen eigenen Cache pflegen muss. Außerdem kann ein Domain-Besitzer eine MTA-STS-Richtlinie festlegen, aber nicht durchsetzen.
DANE verwendet DNS-Einträge, um andere Mailserver über die Unterstützung der TLS-Verschlüsselung zu informieren. Außerdem teilt es dem empfangenden Server mit, dass er ein bestimmtes Zertifikat zu erwarten hat, wenn er sich mit dem sendenden Server verbindet – zum Schutz vor Angreifern, die im Besitz eines ansonsten gültigen TLS-Zertifikats des sendenden Servers sind. Allerdings ist es auf die Sicherheit des DNS-Systems angewiesen, was bedeutet, dass DNS Security Extensions (DNSSEC) erforderlich sind, was zu einer begrenzten Akzeptanz führt (dies ändert sich gerade).
Die Unterstützung von DNSSEC (als Voraussetzung für die Unterstützung von DANE) bringt auch zusätzliche Sicherheitsvorteile mit sich. Einige Beispiele sind der Schutz vor DNS-Cache-Poisoning-Angriffen und vor benutzerdefinierten Domains, die die MX-Einträge von Mailfence verwenden – insbesondere, wenn die benutzerdefinierte Domain DNSSEC implementiert.
Sowohl MTA-STS als auch DANE haben ihre Vor- und Nachteile. Jeder von ihnen kann vor Angriffen auf die Verschlüsselung der Postzustellung schützen. Daher haben wir beide für mailfence.com implementiert.
Erkennen und Austausch von OpenPGP-Schlüsseln (WKD und VKS)
Mailfence bietet OpenPGP-Verschlüsselung und -Signatur für E-Mails. Wir waren von Anfang an interoperabel mit anderen OpenPGP-kompatiblen Diensten und bieten unseren Nutzern die volle Kontrolle über OpenPGP-Schlüssel. Das Erkennen und der Austausch von Schlüsseln war jedoch lange Zeit eine Herausforderung im OpenPGP-Ökosystem, da es schwierig ist zu wissen, ob man den Schlüsseln, die man von einem Public-Key-Server erhält, vertrauen kann.
Web Key Directory (WKD)
Mailfence unterstützt jetzt einen neuen Ansatz mit der Bezeichnung Web Key Directory (WKD), der das Web nutzt, um einer Domain zu ermöglichen, ihre eigenen Schlüssel über HTTPS bereitzustellen. Das bedeutet, wenn Sie ein OpenPGP-Schlüsselpaar generieren oder in Ihren Mailfence-Account-Schlüsselspeicher importieren, wird der entsprechende öffentliche Schlüssel (einschließlich E-Mail-Adresse und Name) auf unserem Web Key Directory-Server öffentlich verfügbar sein, wenn:
- Die zugehörige E-Mail-Adresse auf der Domain mailfence.com basiert.
- Die E-Mail Adresse des Benutzers mit der Schlüssel-Benutzer-ID assoziiert wird. Ein Schlüsselsymbol neben der Absenderadresse im Nachrichten-Editor zeigt dies an.
- Der Schlüssel mit der primären oder Alias-Adresse des Mailfence-Kontos verbunden ist.
Der öffentliche Schlüssel wird nur für und mit dem abgefragten Benutzer-ID-Paket bereitgestellt, um andere zugehörige Benutzer-ID-Pakete nicht preiszugeben (aus Datenschutz- und Anti-Spam-Gründen). Das Web Key Service (WKS) Protokoll unterstützen wir nicht.
Benutzer können auch öffentliche OpenPGP-Schlüssel von externen Domains (oder Diensten), die WKD unterstützen, in den Schlüsselspeicher ihres Mailfence-Kontos herunterladen. Besitzer eigener Domains müssen dies für ihre eigene Domain einrichten oder können WKD als Dienst nutzen.
Validating Key Server (VKS)
In der Vergangenheit haben wir den Synchronizing Key Server (SKS) Pool verwendet. Nach Einführung der DSGVO im Jahr 2018 haben wir aufgrund bekannter Datenschutzbedenken mit dem SKS-Pool (der schließlich am 21.6.2021 geschlossen wurde) nach Alternativen gesucht. Wir haben eine Reihe von öffentlichen Schlüsselservern in Betracht gezogen und uns schließlich für keys.openpgp.org entschieden. Sie können hier mehr darüber lesen.
Sie erlauben die Weitergabe von Identitätsinformationen (Benutzer-ID: Anzeigename und E-Mail-Adresse) nur mit Zustimmung und erlauben auch deren Löschen. Weitere Einzelheiten finden Sie in den Datenschutzbestimmungen.
Sie können öffentliche Schlüssel über die E-Mail-Adresse finden. Bitte beachten Sie, dass Schlüssel ohne Benutzer-ID (Anzeigename und/oder E-Mail-Adresse) derzeit von unserer Seite aus nicht verarbeitet werden können. Wir planen, dies in Zukunft zu ändern.
Reihenfolge der Schlüsselsuche
Unser Ziel war es, einen Schlüsselerkennungsmechanismus zu verwenden, der dies ermöglicht:
- Positive Bestätigung des Schlüsseleigentums / Widerstand gegen Vandalismus
- Widerstand gegen Zensur
- Dezentralisierung
Da wir kein Medium gefunden haben, das alle drei oben genannten Punkte unterstützt, haben wir uns für die Unterstützung mehrerer Mechanismen entschieden. Wenn ein Benutzer nach einem öffentlichen Schlüssel sucht, verwendet die Mailfence-Plattform die folgende Reihenfolge für die Schlüsselsuche:
- Web-Schlüsselverzeichnis (WKD): Der Domain-Besitzer fungiert als „Vertrauensanker“ für die positive Bestätigung des Schlüsseleigentums (über das TOFU-Modell). Wenn ein öffentlicher Schlüssel gefunden wird, wird die Schlüsselsuche beendet.
- Validierender Schlüsselserver (VKS): Der Besitz von E-Mail-Adressen wird über eine Double-Opt-In-Validierung durchgeführt. Die Tatsache, dass sie nicht von einem Eigentümer einer Domain mit öffentlichem Schlüssel kontrolliert/verwaltet wird, bietet ein gewisses Maß an Zensurresistenz.
Die Überprüfung der Signatur und die Aktualisierung des Status des öffentlichen Schlüssels erfolgt immer mit Hilfe von VKS (es ist kein Suchauftrag erforderlich).
Wir haben noch keinen geeigneten Mechanismus gefunden, der den gewünschten Grad an Dezentralisierung bietet (einer der Grundwerte von OpenPGP) und werden die laufenden Bemühungen in dieser Hinsicht weiterhin im Auge behalten.
Sonstiges
- Wir haben mit der Umsetzung der DMARC-Richtlinie für Absender begonnen. Sie können hier mehr darüber lesen.
- Wir haben mit der Verwendung des DNS CAA-Eintrags begonnen. Dies hilft zu verhindern, dass Zertifizierungsstellen ein unzulässiges Mailfence-Zertifikat ausstellen.
- Um TLS-Konnektivitätsprobleme während der E-Mail-Zustellung im Auge zu behalten, überwachen wir die über den TLSRPT-Standard übermittelten Berichte.
- Um unsere Benutzer vor Identitätsdiebstahlsangriffen und unseren Service vor Missbrauch zu schützen, haben wir beschlossen, das Löschen von Mailfence-Domainnamen-basierten Alias-Adressen zu verbieten. Diese Änderung gilt ab dem 1. Januar 2022. Lesen Sie dazu hier mehr.
So wie wir es immer getan haben, werden wir auch weiterhin unsere Sicherheit verbessern, um unseren Nutzern die beste Benutzererfahrung zu bieten. Wir werden nie aufhören, daran zu arbeiten, Mailfence noch vertraulicher und sicherer zu machen. Sie können uns helfen, indem Sie zu unseren Bemühungen beitragen.
Erfahren Sie mehr über uns auf unserer Presse-Seite.
Oder folgen Sie uns auf Twitter/Reddit und bleiben Sie stets auf dem Laufenden.
