Jump to content

DNSSEC Zertifikat prüfen


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Hallo allerseits,

 

als technisch halbgebildeter Datenschützer muss ich mich mit einer Frage an euch wenden. Die Übertragung von E-Mails mit personenbezogenen Daten ist nur dann erlaubt, wenn neben der Transportverschlüsselung auch der Empfänger seine Adresse per DNSSEC zertifiziert hat. Kann ich als sendender Mail-Server denn prüfen, ob hier ein entsprechndes DNSSEC Zertifikat beim Empfänger vorhanden ist?

 

Danke schon mal

 Pitti

Link zu diesem Kommentar

Moin,

 

vor 19 Minuten schrieb Pitti259:

Die Übertragung von E-Mails mit personenbezogenen Daten ist nur dann erlaubt, wenn neben der Transportverschlüsselung auch der Empfänger seine Adresse per DNSSEC zertifiziert hat.

ist das so? Wer sagt das denn?

 

Möglicherweise liegt hier ein Missverständnis vor. DNSSEC beglaubigt nicht die Echtheit eines Mail-Empfängers. Es stellt sicher, dass die per DNS übermittelten Informationen zu einem Host (typischerweise zu einem Server) korrekt sind. Ob dein Mailserver das prüft, müsstest du in der Konfiguration des Mailservers nachsehen.

 

Was ist denn die eigentliche Anforderung, die du lösen musst?

 

Gruß, Nils

 

Link zu diesem Kommentar

Vorgabe der DSK: "Die Bezeichnung der zum Empfang autorisierten Mailserver und ihre IP-Adressen wurden auf Empfängerseite per DNSSEC signiert. Die Signaturen der DNS-Einträge werden auf Senderseite überprüft."

 

Kann der Mail-Server dies prüfen?

 

Wen das DSK-Papier interessiert: https://www.datenschutzkonferenz-online.de/media/oh/20200526_orientierungshilfe_e_mail_verschluesselung.pdf

 

Ciao

 Pitti

Link zu diesem Kommentar

Exchange kann das meines Wissens nicht.

Es gibt einen Blogartikel von MS, daß sie das in Office Online einführen wollen, aber auch erst in der Zukunft. Ob und wann dann das OnPrem kommt ist eine andere Frage.

 

Warum nutzt man nicht Ende zu Ende Verschlüsselung? Dann kann die Mail nur der Empfänger lesen, nicht einmal das empfangende System.

 

 

https://www.zdnet.com/article/microsoft-to-add-dane-and-dnssec-support-to-exchange-online-servers/

https://techcommunity.microsoft.com/t5/exchange-team-blog/support-of-dane-and-dnssec-in-office-365-exchange-online/ba-p/1275494

 

bearbeitet von tesso
Links hinzugefügt
Link zu diesem Kommentar
vor 15 Minuten schrieb tesso:

 

Warum nutzt man nicht Ende zu Ende Verschlüsselung? Dann kann die Mail nur der Empfänger lesen, nicht einmal das empfangende System.

 

Damit rennst Du im Prinzip bei mir offene Türen ein. Aber an dieser Stelle habe ich das Problem, dass mein Mandant seinen Kunden (einige tausend Privatpersonen) E-Mails senden muss. 99% davon sind nur einfache personenbezogene Daten, eine Verpflichtung für die Ende zu Ende Verschlüsselung besteht nur für die besonderen Kategorien nach Art. 9 DSGVO. Jetzt versuch doch mal Lieschen Müller davon zu überzeugen sich ein S/Mime Zertifikat zuzulegen oder sich einen pgp Schlüssel zu erzeugen.

 

Ja ich weiß, Austauschplattform. Macht mein Mandant bereits, jeder Kunde hat sein Kundenkonto und erhält nur eine E-Mail mit der Info über neue Messages. Ähnliches haben wir für die Geschäftsanbahnung probiert, eine Austauschplattform und nur den Link auf die jeweiligen Daten per Mail versandt. Die Auftragsabschlüsse brachen radikal ein. Keiner wollte das so haben. Auch verschlüsselte ZIPs mit Passwort über Handy wurden von den potentiellen Kunden nicht akzeptiert. Sch... aber auch, was willste da noch machen?

Link zu diesem Kommentar

Hi,  

vor 54 Minuten schrieb Pitti259:

Vorgabe der DSK: "Die Bezeichnung der zum Empfang autorisierten Mailserver und ihre IP-Adressen wurden auf Empfängerseite per DNSSEC signiert. Die Signaturen der DNS-Einträge werden auf Senderseite überprüft."

wenn du das zu Ende zitierst, gibt es da noch einen weiteren Satz (https://www.datenschutzkonferenz-online.de/media/oh/20200526_orientierungshilfe_e_mail_verschluesselung.pdf):

Zitat

Die Bezeichnung der zum Empfang autorisierten Mailserver und ihre IP-Adressen wurden auf Empfängerseite per DNSSEC signiert. Die Signaturen der DNS-Einträge werden auf Senderseite überprüft. Alternativ kann die Bezeichnung der zum Empfang autorisierten Mailserver auch durch Kommunikation mit dem Empfänger verifiziert werden.

Ich gehe allerdings auch davon aus, dass Lieschen Müller ebenfalls keine Ahnung hat welche Mailserver des Providers welche IP Adressen haben. Ebenfalls findet sich im Dokument zu "DNSSEC" noch:

Zitat

4.2.2 Versand von E-Mail-Nachrichten bei hohem Risiko
Verantwortliche, die E-Mail-Nachrichten versenden, bei denen ein Bruch der Vertraulichkeit von personenbezogenen Daten im Inhalt der Nachricht ein hohes Risiko für die Rechte und Freiheiten von natürlichen Personen darstellt, müssen regelmäßig eine Ende-zu-Ende-Verschlüsselung und eine qualifizierte Transportverschlüsselung vornehmen. Inwieweit entweder auf die Ende-zu-Ende-Verschlüsselung oder die Erfüllung einzelner Anforderungen an diese (s. Kap. Ende-zu-Ende-Verschlüsselung) oder an die qualifizierte Transportverschlüsselung (z. B. DANE oder DNSSEC) verzichtet werden kann, hängt von den bestehenden Risiken, der konkreten Ausgestaltung des Übertragungsweges und ggf. getroffenen kompensierenden Maßnahmen ab. 

Trifft das denn überhaupt zu? Wurde überhaupt von "irgendjemandem" festgelegt was ein "... hohes Risiko für die Rechte und Freiheiten ..." darstellt? Ebenfalls lässt das zuletzt zitierte ja auch noch Luft nach unten.

 

Wäre ich jetzt Lieschen Müller, hätte ich gar kein Interesse eine solche Angelegenheit per Mail zu bekommen. Vermutlich würde ich diese Information nicht mal am Telefon entgegennehmen wollen. ;)

 

Eine (traurige) Alternative: De-Mail. Zumal man seine Mandanten aus Privatpersonen ebenfalls schlecht zu De-Mail zwingen kann.

 

Gruß

Jan

Link zu diesem Kommentar

Moin,

 

also, zunächst einmal ist das Papier ausdrücklich eine "Orientierunngshilfe" und keine Vorgabe. Ganz vorne steht ausdrücklich, dass man die konkreten Umstände in Betracht ziehen muss. Daraus folgt, dass es gerade nicht auf ganz konkrete Umsetzungen (wie etwa DNSSEC) ankommt. Oder einfacher: Anders als vermutet bzw. hier in dem Thread dargestellt, gibt es eben keine Verpflichtung, DNSSEC einzusetzen.

 

In dem Kapitel, in dem es um DNSSEC geht, sind Voraussetzungen genannt, unter denen die Transportverschlüsselung ausreicht - die Formulierung ist aber (ziemlich sicher absichtlich) so, dass sie eben auch andere Lösungen zulässt. 

 

Damit will ich das nicht weg- oder kleinreden. Sollte sich aber im konkreten Fall zeigen, dass DNSSEC nicht geht, dann sind eben auch andere Maßnahmen möglich. Es ist kein Schwarz/Weiß (ist es bei der DSGVO auch nur selten). - Ob mögliche Alternativen praktikabler sind, steht auf einem anderen Blatt.

 

Gruß, Nils

 

Link zu diesem Kommentar
  • 2 Wochen später...

Hallo,


ich knüpfe mal an eure Diskussion an.
Das spannende an dem DSK-Dokument ist doch, dass erstmals Bedingungen formuliert sind, unter denen auch eine Transportverschlüsselung zur datenschutzkonformen E-Mail-Übertragung eingesetzt werden kann. Die DSK hat das "qualifizierte Transportverschlüsselung" genannt, und die bringt den Vorteil mit, dass "Lieschen Müller" sich nicht drum kümmern müsste. Und seien wir ehrlich, für die meisten normalen Nutzer wäre das sehr gut.
Wenn man sich die Bedingungen der DSK für eine "qualifizierte" Transportverschlüsselung anschaut, sind es eigentlich 3 Dinge, die vom Absender zu erfüllen sind:
1) Sicherstellen, dass die Ergebnisse der DNS-Abfragen nicht gefälscht werden können (Vorschlag der DSK: DNSSEC oder miteinander sprechen)
2) Nach dem Verbindungsaufbau sicherstellen, dass man mit dem richtigen Zielsystem spricht/verschlüsselt, um Man-in-the-Middle auszuschließen (Vorschlag DSK: Prüfung der TLS-Zertifikatskette)
3) Sicherstellen, dass die Verschlüsselung an sich auf dem aktuellen Stand der Technik ist (Vorschlag der DSK: Einschränkung auf spezielle vom BSI vorgegebene Algorithmen)

Alle diese Vorgaben haben im Detail ihre Tücken. DNSSEC aber besonders, weil in der Breite nur deutlich unter 1% der Unternehmen/Organisationen ihre DNS-Einträge signiert haben.
Als Softwarehersteller haben wir uns gedacht, es muss doch eine andere Alternative zu DNSSEC geben als miteinander zu sprechen. Die haben wir auch gefunden und umgesetzt. Bestätigung durch unabhängige Datenschutz-Experten läuft gerade.

 

Am Ende können wir mit unserem Gateway für den Absender alle Punkte automatisieren, die für qualifizierte Transportverschlüsselung wichtig sind und diese Übertragung in der Breite auch für eine hohe Risikoklassifizierung anbieten.
 

Viele Grüße
Georg

Link zu diesem Kommentar

@Dukel
Es ist natürlich absolut richtig, dass Transportverschlüsselung und Ende-zu-Ende-Verschlüsselung zwei verschiedene Paar Schuhe sind.

Wenn eine einzelne Mail so abgesichert werden soll, dass nur der Empfänger als Person, und technisch niemand sonst, Einblick erlangen kann, kommt man um eine Ende-zu-Ende-Verschlüsselung nicht drum herum. Das ist die "klassische" Informationsschutz-Sichtweise.

Von der reinen Datenschutz-Seite her betrachtet ist dies aber gar nicht immer notwendig. Denn die grundsätzliche gesetzliche Pflicht, Daten in den eigenen IT-Systemen vor Zugriffen Dritter zu schützen, haben sowohl Absender als auch Empfänger. Deshalb stellt sich die Datenschutzkonferenz bewusst "nur" die Frage, welche Technologien man für die sichere Übertragung zwischen Absender-IT und Empfänger-IT verwenden kann.

Und das ergibt im Vergleich mit der Realwelt durchaus Sinn: Für viele Briefe brauche ich keine persönliche Zustellung, sondern ein "Einschreiben" an die Empfängerorganisation reicht völlig aus. Und genau dieses Niveau ermöglicht die qualifizierte Transportverschlüsselung: Sicherstellen, dass der Brief in den richtigen Briefkasten eingeworfen wurde (Ausschluss Man-in-the-Middle) und bis dahin blickdicht verpackt war (Ausschluss keine/schlechte Verschlüsselung).

 

Also ist die neue "qualifizierte Transportverschlüsselung" sicherlich kein Allheilmittel, aber durchaus die Möglichkeit  einer großen Aufwandsersparnis in der Breite.

bearbeitet von comcrypto
Link zu diesem Kommentar
vor 21 Minuten schrieb comcrypto:

Sicherstellen, dass der Brief in den richtigen Briefkasten eingeworfen wurde (Ausschluss Man-in-the-Middle) und bis dahin blickdicht verpackt war (Ausschluss keine/schlechte Verschlüsselung).

Genau darauf zielt @Dukels Einwand doch ab. Du bist dir doch niemals sicher, ob du tatsächlich in den richtigen/finalen Briefkasten eingeworfen hast. Es können ja noch einige Briefkästen auf dem Weg zum Ziel kommen.

Link zu diesem Kommentar

Moin,

 

das ist korrekt, entkräftet aber nicht das Argument von @comcrypto. Aus Sicht der Datenschutzkonferenz ist ab dem Zeitpunkt, wo die Daten zuverlässig an die Zielorganisation übergeben wurden, diese für den Schutz zuständig. Ob die dann noch weitere Ketten aufbaut, ist dann genauso ihre Sache wie der Schutz dieser Kette. Für den reinen Transport reicht es dann aber aus, dass die sendende Organisation für den sicheren Transport gesorgt hat.

 

Wenn das nicht ausreicht, dann ist der Grund nicht "pur" die DSGVO, und dann braucht es eben andere Methoden, möglicherweise eine Ende-zu-Ende-Verschlüsselung.

 

Gruß, Nils

 

Link zu diesem Kommentar

Jetzt nochmals für die kleinen Dummies wie mich.

 

Meine Annahme: Wenn ich eine Transportverschlüsselung mit mx.Zielserver.com initiiere, wandert meine E-Mail zwar über n andere Server, ist aber bis zum Zielserver verschlüsselt und kann auf den Zwischenstationen nicht gelesen werden.

 

Richtig oder Falsch?

 

Wenn ich testperson richtig interpretiere, würde immer nur zwischen den einzlnen Vermittlungsservern eine TLS aufgebaut. Auf den Zwischenstationen wäre also meine Mail lesbar. :shock2:

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...