comcrypto

Vielleicht nochmal kurz zum Umgang mit den Zwischensystemen / Zwischen-Hops: Grundsätzlich ja, richtig gemachte Transportverschlüsselung (die "qualifizierte") stellt sicher, dass innerhalb eines SMTP-Hops (also der Übertragung von einem Mailsystem zum nächsten) keine Routing- und sonstige Netzwerkknoten mitlesen können. Aber natürlich liegt die Mail auf jedem Mailsystem (bei jedem Zwischen-Hop), das Endpunkt eines transportverschlüsselten Hops ist, im Klartext lesbar vor. Aus Datenschutz-Sicht kann man aber jedes dieser Zwischensysteme entweder der Absender- oder der Empfänger-Hoheit zuordnen. Das letzte System des Absenders ist genau das, welches die Übertragung an das MX-System der Empfänger-Domain vornimmt (mx.Zielserver.com im Beispiel von @Pitti259), welches naturgemäß das erste System des Empfängers ist. Für Unternehmen heißt das: Wenn ausgelagerte Mail-Systeme über Dienstleister (z.B. Strato, 1&1 und Co.) betrieben werden, liegt das, was dort mit der Mail passiert, trotzdem in der Verantwortung des Unternehmens. Dafür gibt es in der DSGVO die Auftragsverarbeitungsverträge. So einen sollte man mit jedem Dienstleister, der Daten verarbeitet (worunter Mails weiterzuleiten nunmal fällt) abschließen. Darin wird z.B. festgehalten, wie der Dienstleister die Daten verarbeitet und wie er sicherstellt, dass vor allem die personenbezogenen Daten nicht in falsche Hände gelangen. Es hat also aus Datenschutz-Sicht sowohl die Absender-Organisation ihre "Kette von Mail-Systemen" vertraglich zu kontrollieren (und damit technisch/organisatorisch), wie auch die Empfänger-Organisation die ihre. Der einzige Hop, der sich vertraglich in der Breite eben nicht kontrollieren lässt, ist der Übergang vom letzten Absender- zum ersten Empfängersystem, deswegen wird dieser von der DSK so stark thematisiert. Insgesamt bietet dieses ganze Vorgehen natürlich keine absolute technische Kontrolle (wie sie mit E2E-Verschlüsselung eher möglich wäre), aber eine aus Gesetzgebersicht genügende Sicherheit für die verarbeiteten personenbezogenen Daten. Dazu noch was Interessantes: Es ist richtig, dass viele große Hoster auf ihrer Posteingangsseite, also als Empfänger, mittlerweile restriktiv gegenüber einer zu alten TLS-Version beim Absender sind. Lustiger- oder erschreckenderweise gilt das andersrum nicht. Wenn z.B. Mails von O365 ausgehend versendet werden (aber auch von jedem anderen Hoster), wird die Mail auch dann an das MX-System des Empfängers zugestellt, wenn dieses nur TLS 1.0 anbietet. Wer das selber testen möchte - Wir haben dafür einen Testserver im Netz, der absichtlich alle möglichen Mängel bei der Verschlüsselung aufweist, z.B.: nur TLS 1.0, kein TLS 1.1-1.3 RSA nur mit 1024bit nur solche Ciphers, die vom BSI explizit _nicht_ empfohlen werden. Ergebnis: Jeder Mailserver schickt trotzdem dahin.

@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.

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