email Verschlüsselung

[fitheach]

Hallo,

eine Grundsatzfrage an die Erfahreneren mit mehr Überblick.

Ich habe mittlerweile herausgefunden, dass es mehrere Verfahren bei dem Emailversand gibt.

Transportverschlüsselung
So ziemlich gängig ist TLS, welches die Email auf dem Transport verschlüsselt. Ich verstehe das so, dass man sich nicht mehr ohne weiteres zwischen Client und smtp-Server bzw. MTA und client hängen kann, um die Email zu schnüffeln.

Der smtp des Senders sollte mit dem MTA des Empfängers auch verschlüsselt kommunizieren.

Demnach kann beim Transport keiner lauschen. Wie sieht das mit einem offenen Relay-smtp aus? Könnte ich böswillig damit emails einfangen? Oder kann man den sendenden smtp dazu anhalten, immer direkt an den Bestimmungsort zu senden?

Ende-zu-Ende-Verschlüsselung
Hier ver- und endschlüsselt der jeweilige Client die Email.
Vorteil: die Emails liegen nicht im Klartext vor. Weder auf dem Clientrechner, noch auf dem Postausgangsserver bzw. Empfängerserver. Signierung der Email ist auch möglich.
Nachteil: Diese Verschlüsselung erschwert den Workflow. Weiterbearbeiten, bzw. Weitergabe und Archivierung ist ohne Weiteres nicht möglich. Auch schafft nicht jeder die "Technik" richtig einzusetzen.

Mailgateway
Hier übernimmt ein Server die Emailverschlüsselung. Zuerst fand ich das genial. Aber welchen Mehrwert bietet ein solcher Gateway zu TLS? Die Emails liegen auf dem Server auch unverschlüsselt vor. Ok, signieren kann jemand die email nur, wenn er Zugriff auf den Server hat. Mehr aber auch nicht.

Vielleicht kann man es noch als Vorteil sehen, dass die Emails auf dem Empfangsserver verschlüsselt sind, sollte der Empfänger seinem Setup nicht trauen. Aber das reißt mich jetzt nicht so vom Hocker.

Frage an euch: Hab ich das richtig verstanden? Habe ich etwas (wichtiges) übersehen?

VG und vielen Dank!

[tobo]

Der smtp des Senders sollte mit dem MTA des Empfängers auch verschlüsselt kommunizieren.

Transportverschlüsselung bedeutet, dass du mit deinem Mail-Anbieter verschüsselt kommunizierst. Wie dein Mail-Anbieter mit dem Mail-Anbieter des Empfängers kommuniziert und der Empfänger mit seinem Mail-Anbieter, hat nichts mit deinen Einstellungen zu tun. Noch vor ein paar Jahren war die Kommunikation der Mail-Anbieter untereinander durchweg unverschlüsselt. Ob das heute noch so ist, keine Ahnung.

Nachteil: Diese Verschlüsselung erschwert den Workflow.

Das ist zwar richtig, aber man muss ja entscheiden, was man eigentlich will. Die Haustür beim Weggehen zuzuziehen und abzuschließen erschwert auch den Workflow!?

[fitheach]

Wie dein Mail-Anbieter mit dem Mail-Anbieter des Empfängers kommuniziert und der Empfänger mit seinem Mail-Anbieter, hat nichts mit deinen Einstellungen zu tun. Noch vor ein paar Jahren war die Kommunikation der Mail-Anbieter untereinander durchweg unverschlüsselt. Ob das heute noch so ist, keine Ahnung.

Das ist ein Argument.

Die Haustür beim Weggehen zuzuziehen und abzuschließen erschwert auch den Workflow!?

Ich hatte Schwierigkeiten mit der Volltextsuche, Verteilen in unterschiedlichen Emailordnern (wenn die Email bei Adresse x ankommt, aber die Kommunikation zur Adresse y gehört). Darüber hinaus muss ich 60% der Emails bis 14 Jahre archivieren und zwar so, dass unter bestimmten Umständen Finanzamt bzw. Staatsanwaltschaft darauf zugreifen können. Beide können zwar nicht von mir verlangen, dass ich extra die Emails in lesbarer Form speichere, aber sollte das aus irgendeinem Grund sich trotzdem nicht mehr entschlüsseln lassen, habe ich den schwarzen Peter (und ggfs. keiner etwas davon).

[fitheach]

Ok, so wie es aussieht, nutzen mittlerweile ca. 90% aller Mailserver TLS.

Ich kann die Verbindung zwischen Client und meinem Mailserver absichern. Ich kann auch sicherstellen, dass mein Mailserver nur verschlüsselt verschickt.

Grds. ist es auch nicht meine Aufgabe, sicherzustellen, dass der Empfängermailserver verschlüsselt. Das ist in etwa genauso, wie ich mich nicht um die Qualität des Empfängerbriefkasten bei einem normalen Brief kümmern muss.

Was aber problematisch ist, sind evtl. Sprünge dazwischen. Bisher habe ich noch nicht verstanden, ob ich meinem Mailserver vorschreiben kann, sich NUR mit dem Mailserver des Empfängers zu verbinden.

Generell wäre ein gateway wie z.B. ciphermail schon sehr komfortable. Aber das ist ein ziemliches Dickschiff. Kennt jemand vielleicht einen leichtgewichtigeren gateway? Oder evtl. eine leichtgewichtigeren Lösungsansatz?

Vielen Dank im voraus...

[bluestar]

Ok, so wie es aussieht, nutzen mittlerweile ca. 90% aller Mailserver TLS.

Leider "nur 90%", aber besser als vor ein paar Jahren

Was aber problematisch ist, sind evtl. Sprünge dazwischen. Bisher habe ich noch nicht verstanden, ob ich meinem Mailserver vorschreiben kann, sich NUR mit dem Mailserver des Empfängers zu verbinden.

Dein Mailserver ermittelt ja anhand des MX-Eintrags der Domain, an welchen Server die Mails eingeliefert werden sollen ... Alles weitere hinter dem MX liegt im Empfängerermessen, du kannst auch nicht herausfinden, ob die Mail auf dem MX bleibt (lokale Speicherung) oder ob die Mail in irgendeiner Form egal ob verschlüsselt oder unverschlüsselt weitergereicht wird.

Generell wäre ein gateway wie z.B. ciphermail schon sehr komfortable. Aber das ist ein ziemliches Dickschiff. Kennt jemand vielleicht einen leichtgewichtigeren gateway? Oder evtl. eine leichtgewichtigeren Lösungsansatz?

Was ich dir zur Erhöhung der Sicherheit empfehlen kann ist eine konfigurationstechnische und vertragliche Absprache mit deinen Kommunikationspartnern, dass du ausschließlich Mails bei Domain "example.com" über TLS annimmst bzw. ausschließlich Mails über TLS an den MX der Domain "example.com" einliefert. Falls du Exim benutzt kann ich die Beispiel ACLS für Empfang und Router für ausgehende Mails schicken.

[wanne]

Wie sieht das mit einem offenen Relay-smtp aus? Könnte ich böswillig damit emails einfangen? Oder kann man den sendenden smtp dazu anhalten, immer direkt an den Bestimmungsort zu senden?

Der MTA nimmt per default immer den direkten weg. Umgeleitet wird nur, wenn man ihm das (beispielsweise zur spamfilterung) explizit aufträgt. In sofern eher harmlos.
Das Problem ist eher das:

Sprünge dazwischen.

Die strecke von MTA nach MDA ist seltenst wirklich abgesichert. Zwar unterstützen ein großer Anteil der MDA TLS, aber eben nicht alle. Deswegen machen alle einen Fallback auf unverschlüsselt. Du musst also nur dafür sorgen, dass der erste Versuch nicht durchkommt. Und das ist so ziemlich der einfachste Angriff.Z.B. durch ein ICMP-RST Paket mit gespoofter src IP. Sprich deine Mails sind zwar häufig verschlüsselt aber immer dann wenn jemand versucht mitzuhören wird er den Fallback auf plaintext erzwingen.

Die einzige Lösung wäre folgendes:

Ich kann auch sicherstellen, dass mein Mailserver nur verschlüsselt verschickt.

Dann kommen aber halt 10-20% der Ausgehenden und 30-40% der eingehenden E-Mails gar nicht an. Es gibt gerade unter den großen Mailanbietern für kommerziell noch viele, die kein TLS können. DANE löst das Problem indem man abfragen kann, wer TLS wie kann. Leider im Moment mit wenig erfolg.

Nachteil: Diese Verschlüsselung erschwert den Workflow. Weiterbearbeiten, bzw. Weitergabe und Archivierung ist ohne Weiteres nicht möglich.

Das halte ich für Quatsch wenn man einen halbwegs vernünftigen Mailclienten (nicht Thunderbird ) hat, merkt man da nichts von außen. Bei kmail änder sich außer dem grünen balken für verschlüsselt drauf. Ähnliches gilt für Outlook und S/MIME

Aber welchen Mehrwert bietet ein solcher Gateway zu TLS

Großartig nicht wirklich. Zei sachen fallen mir trotzdem ein:
a) Meil Verschlüsslung ist um Größenordnungen einfacher wie TLS. Es ist also zu hoffen, dass die weniger Lücken haben.
b) Zumindest unter deutschen E-Mail Anbeitern gibt es eine liste von Servern, die das können. Zumindest für Mails mit Empfängern auf denen sind dann deutlich sicherer wie TLS mit Fallback auf plaintext. Vor allem merken die sich auch wenn ein mal eine E-Mail-Adresse sowas kann, dann machen sie das für immer.

[fitheach]

@wanne

Danke für die technische Erläuterung.

Nachteil: Diese Verschlüsselung erschwert den Workflow. Weiterbearbeiten, bzw. Weitergabe und Archivierung ist ohne Weiteres nicht möglich.

Das halte ich für Quatsch wenn man einen halbwegs vernünftigen Mailclienten (nicht Thunderbird ) hat, merkt man da nichts von außen. Bei kmail änder sich außer dem grünen balken für verschlüsselt drauf. Ähnliches gilt für Outlook und S/MIME

Aber welchen Mehrwert bietet ein solcher Gateway zu TLS

Großartig nicht wirklich. Zei sachen fallen mir trotzdem ein:

Naja, solange ich im Client bleibe, ist fast alles ok. Aber es hört z.B. schon da auf, wenn ich emails vom einen in ein anderes Postfach verschiebe, weil der Sender an eine nichtzutreffende Emailadresse gesendet hat (z.B an Info@ obwohl es bei support@ bearbeitet wird) Emailweiterleitung (Urlaubsvertretung) wird auch schwierig. Klar, ich könnte für alle Beteiligten einen PGP-Schlüssel erzeugen. Schicht ist aber dann, wenn ein Emailclient eingesetzt wird, der PGP nicht kann, man aber aufgrund dessen Funktionalität nicht einfach wechseln kann.

Ich überlege, ob ich jetzt nicht mal mit Kanonen auf Spatzen und so:

* eigener Server zuhause
* ankommende Emails werden wie sie sind verschlüsselt weggespeichert -> GoBD-konform (und nur das muss ich dann auch "hier" rausgeben)
* PGP mailgateway -> Ende zu Endeverschlüsselung möglich
* Festplattenverschlüsselung

Ich frage mich nur, was mich der Spass kostet. Aber ich werde feedback geben.

[fitheach]

Dein Mailserver ermittelt ja anhand des MX-Eintrags der Domain, an welchen Server die Mails eingeliefert werden sollen ... Alles weitere hinter dem MX liegt im Empfängerermessen, du kannst auch nicht herausfinden, ob die Mail auf dem MX bleibt (lokale Speicherung) oder ob die Mail in irgendeiner Form egal ob verschlüsselt oder unverschlüsselt weitergereicht wird.

Das ist dann aber auch das Problem des Empfängers. Wenn ich einen Brief verschicke, bin ich auch nicht verantwortlich, wenn der Empfänger diesen dann aus dem Briefkasten nimmt und im Hausflur liegen lässt.

Was ich dir zur Erhöhung der Sicherheit empfehlen kann ist eine konfigurationstechnische und vertragliche Absprache mit deinen Kommunikationspartnern, dass du ausschließlich Mails bei Domain "example.com" über TLS annimmst bzw. ausschließlich Mails über TLS an den MX der Domain "example.com" einliefert. Falls du Exim benutzt kann ich die Beispiel ACLS für Empfang und Router für ausgehende Mails schicken.

Ich weiß nicht, ob das jetzt funktioniert. Die meisten werden schon technisch den Sachverhalt nicht erfassen.

[bluestar]

Was ich dir zur Erhöhung der Sicherheit empfehlen kann ist eine konfigurationstechnische und vertragliche Absprache mit deinen Kommunikationspartnern, dass du ausschließlich Mails bei Domain "example.com" über TLS annimmst bzw. ausschließlich Mails über TLS an den MX der Domain "example.com" einliefert. Falls du Exim benutzt kann ich die Beispiel ACLS für Empfang und Router für ausgehende Mails schicken.

Ich weiß nicht, ob das jetzt funktioniert. Die meisten werden schon technisch den Sachverhalt nicht erfassen.

Ich kann dir sagen, das ich einige Verträge über ForceTLS Verbindungen mit diversen Partnern(Banken, Partner-Unternehmen, fähige befreundete Mail-Admins) schließen konnte und das sogar relativ problemlos. Sicher ist es für das Gro nicht die Option, ich sehe es auch mehr oder minder als "Spezialfall für gesicherte verschlüsselte Kommunikation", wo eine End-zu-End-Verschlüsselung auf Seitens der Nutzer nicht einführbar ist.

[Korodny]

Ok, so wie es aussieht, nutzen mittlerweile ca. 90% aller Mailserver TLS.

Mein Anbieter Posteo bietet eine Konfigurationsoption, mit der ich den (Posteo-) Mailserver zwingen kann Mails nur abzuliefern wenn der empfangende Server eine sichere Verbindung akzeptiert.

Ich habe diese Option aktiviert - innerhalb von Deutschland fällt mir jetzt nur KabelBW ein, wo das noch Probleme macht. Ich kann mich gerade an keine Fehlermeldung für einen anderen deutschen Mailserver erinnern. Außerhalb Deutschlands ist es ein bisschen schlechter, aber nicht dramatisch.

Hab ich das richtig verstanden? Habe ich etwas (wichtiges) übersehen?

In deiner Aufzählung klingt das ein bisschen nach entweder-oder. Ende-zu-Ende-Verschlüsselung sollte aber möglichst immer mit einer Transportverschlüsselung kombiniert werden, da die Mail-Header sonst unverschlüsselt übertragen werden.

Nachteil: Diese Verschlüsselung erschwert den Workflow. Weiterbearbeiten, bzw. Weitergabe und Archivierung ist ohne Weiteres nicht möglich.

Das halte ich für Quatsch wenn man einen halbwegs vernünftigen Mailclienten (nicht Thunderbird ) hat, merkt man da nichts von außen.

Naja, sie erschwert den Workflow deswegen ganz erheblich, weil praktisch kein Empfänger damit umgehen kann. Außerhalb von stark technisch interessierten Kreisen ist mir in den letzten 10 Jahren genau eine Person untergekommen, die damit was anfangen konnte.

[bluestar]

In deiner Aufzählung klingt das ein bisschen nach entweder-oder. Ende-zu-Ende-Verschlüsselung sollte aber möglichst immer mit einer Transportverschlüsselung kombiniert werden, da die Mail-Header sonst unverschlüsselt übertragen werden.

Für mich ist ForcedTLS ein guter Schritt in Richtung vollständiger Ende-zu-Ende-Verschlüsselung, perfekt ist es keineswegs... Allerdings ist eine erzwungene Transportverschlüsselung schon besser als unverschlüsselt bzw. optionales TLS.

[fitheach]

Naja, sie erschwert den Workflow deswegen ganz erheblich, weil praktisch kein Empfänger damit umgehen kann.

Nein, ich meine damit wirklich die Weiterverarbeitung der Daten. Wenn ich für mich ein emailpostfach bespiele ok. Aber wenn ich emails für verschiedene Personen oder Programme zur Verfügung stellen muss, ist ein verschlüsseltes Dokument sperrig.