Hatte letzte Woche in einem Meeting gesagt, dass unser E-Mail-Verkehr nicht verschlüsselt sei und wir jeden Tag im Intranet einiges an personenbezogenen Daten per E-Mail hin- und herschicken. Da meinte ein Kollege, dass alle E-Mails vom Provider mittels PKI verschlüsselt würden und ich davon nur nichts mitbekäme, weil sich darum eben der Provider kümmere. Ist das denn tatsächlich so? Der Internetprovider verschlüsselt die E-Mails? Auch die, die im Intranet verschickt werden? Viele Grüße
Torben S. schrieb: > Da meinte ein > Kollege, dass alle E-Mails vom Provider mittels PKI verschlüsselt würden > und ich davon nur nichts mitbekäme, weil sich darum eben der Provider > kümmere. > Ist das denn tatsächlich so? Nein.
:
Bearbeitet durch User
Der Provider verschlüsselt nichts ohne Vertrag. Bis auf die übliche "Transportverschlüsselung" (TLS), die aber nichts mit einer richtigen Verschlüsselung zu tun hat.
Zwischen Usern und Mailprovidern besteht heute eine obligatorische Transportverschlüsselung via TLS. Zwischen Providern und Firmen mit eigenem Mailhost ist diese Verschlüsselung jedoch optional und fehlt sehr oft. Zudem werden dabei oft selbst signierte Zertifikate verwendet, was niemanden abhält, der es ernst meint.
:
Bearbeitet durch User
TLS hat den Nachteil, dass es nicht Anbieterübergreifend funktioniert. Sobald die Email den Einflussbereich des Mailanbieters verlässt wirkt die Transportverschlüsselung m.W. nicht mehr.
A. K. schrieb: > Zwischen Usern und Mailprovidern besteht heute eine obligatorische > Transportverschlüsselung via TLS. Schön wär's, bei vielen ist das leider immer noch optional. A. K. schrieb: > Zudem werden dabei oft selbst signierte Zertifikate verwendet, was > niemanden abhält, der es ernst meint. Ja, de facto verifiziert kein MTA auch nur den CN, weil es sonst Bounces hageln würde.
René H. schrieb: > TLS hat den Nachteil, dass es nicht Anbieterübergreifend funktioniert. > Sobald die Email den Einflussbereich des Mailanbieters verlässt wirkt > die Transportverschlüsselung m.W. nicht mehr. Auch zwischen MTAs wird TLS eingesetzt. Aber eben generell nur optional und wegen häufiger Fehlkonfigurationen ohne Schutz gegen Man-in-the-middle-Angriffe.
René H. schrieb: > TLS hat den Nachteil, dass es nicht Anbieterübergreifend funktioniert. > Sobald die Email den Einflussbereich des Mailanbieters verlässt wirkt > die Transportverschlüsselung m.W. nicht mehr. Sie wirkt ohnehin nur von Mailstation zu Mailstation, nicht aber bei der Speicherung auf den Systemen. Da Verschlüsselung zwischendrin optional ist, lässt sich auch TLS zwischen zwei Hops mit überprüfbaren Zertifikaten meist mühelos aushebeln. Denn ein Mailhost mit offener Kommunikation kann es sich nicht leisten, auf überprüfbare Zertifikate zu bestehen, weshalb jemand zwischendrin ein eigenes unterschieben kann. Soll heissen: Die Transportverschlüsselung führt hauptsächlich dazu, dass Netzwerker beim Debuggen per Wireshark die Inhalte nicht mitkriegen.
Ich halte auch nichts von Emailverschlüsselung solange es keinen einheitlichen Standard gibt. Ich habe nämlich keine Lust, unzählige Verschlüsselungsprogramme installieren zu müssen nur damit ich auch jeden möglichen Verschlüsselungstyp entschlüsseln kann. Und DE-Mail ist ja längst tot, eine Totgebuhrt.
Ergo: Wer sicher per Mail kommunizieren will, kommt um Ende-zu-Ende Verschlüsselung nicht herum. Normaler Internet-Mailverkehr leistet dies nicht und sollte weiterhin als Postkartenversand verstanden werden. Wird zufällig mal TLS genutzt, ist das grob vergleichbar mit einer Postkarte mit Klartext auf Finnisch. Kann der Postler hierzulande i.d.R. nicht lesen, aber jeder, der es drauf anlegt. Es gibt Mailprovider, die verschlüsselte Speicherung und verschlüsselten Transport anbieten. Wie beispielsweise Protonmail mit PGP/GPG. Allerdings funktioniert das nicht übergreifend.
:
Bearbeitet durch User
Hmmm schrieb: > A. K. schrieb: >> Zudem werden dabei oft selbst signierte Zertifikate verwendet, was >> niemanden abhält, der es ernst meint. > > Ja, de facto verifiziert kein MTA auch nur den CN, weil es sonst Bounces > hageln würde. Auch dann, wenn man korrekt DNSSEC und DANE eingerichtet hat? Neben DANE gäbe es auch noch MTA-STS. Ich hab DANE, aber nicht MTA-STS. Ich mag MTA-STS ich aus ähnlichen gründen nicht, aus denen mir bei webseiten auch HSTS nicht gefällt, konkret, wegen der Persistenzaspekte dieser. Ein Angreifer könnte das unter gewissen Umständen zu DOS Zwecken ausnutzen (wobei, das ist problematischer, wenn man es nicht nutzt, *STS macht die Welt in der hinsicht unsicherer), und es erschwert das Austauschen von Zertifikaten (Ich hab schon einige Seiten erlebt, die sich so selbst für ne weile offline genommen haben, und nichts mehr dagegen tun konnten). Das ersetzt aber natürlich alles E2E-Verschlüsselung nicht.
Du kannst einen Mailhost durchaus so einrichten, dass er nur sichere Transportverschlüsselung zulässt. Bei geschlossener Benutzergruppe ist das auch praktikabel. Wer allerdings Mailhosts einrichtet, mit dem aus- wie eingehend jeder kommunizieren können soll, der kann sich das nicht leisten. Die Praxis zeigt, dass bereits die Einhaltung der üblichen alten unverschlüsselten Mailstandards nicht als gegeben vorausgesetzt werden kann. Mailsysteme müssen gegenüber Fehlkonfigurationen und Formatfehlern recht tolerant sein, sonst klemmts zu oft.
:
Bearbeitet durch User
Bei DNSSEC gibts im grunde 3 Zustände: 1) Kein DNSSEC vorhanden (in einem DNSSEC signierten bereich für die unsignierte Zohne kein DS key) 2) DNSSEC vorhanden und OK (Alle Keys vorhanden und signiert) 3) DNSSEC vorhanden aber nicht OK (MitM Angriff oder Fehlkonfiguration) Man kann also zwischen Angriff/Fehlkonfiguration, und schlicht kein DNSSEC unterscheiden. Also könnenten Mailserver beim Mail Senden folgendes tun: 1) Kein DNSSEC bei Zielserver, sende Mail egal ob verschlüsselt oder nicht 2) DNSSEC bei Zielserver aber kein DANE, sende Mail egal ob verschlüsselt oder nicht 3) DNSSEC bei Zielserver, aber Fehler bei Prüfen von DNSSEC+DANE, sende mail nicht 4) DNSSEC bei Zielserver, und DNSSEC+DANE ok, sende mail nur Verschlüsselt Ich bin mir aber gerade nicht sicher, ob das auch gemacht wird oder nicht, das ist zu lange her, das ich mich zuletzt damit beschäftigt habe. Aber prinzipiell wäre eine reibungslose Einführung von sicherem Mailtronsport mit DNSSEC+DANE problemlos möglich.
🐧 DPA 🐧 schrieb: > Auch dann, wenn man korrekt DNSSEC und DANE eingerichtet hat? Wenn der sendende MTA das nutzt, stehen die Chancen besser, aber gerade bei grossen Providern würde ich immer mit Settings rechnen, die wenig Supportaufwand erzeugen. Das sieht man z.B. auch in den gängigen SPF-Policies: Sie listen brav die Hosts auf, von denen sie Mails verschicken, aber ein abschliessendes "~all" statt eines konsequenten "-all" ruiniert es wieder.
Beitrag #6418520 wurde vom Autor gelöscht.
Torben S. schrieb: > im Intranet > Da meinte ein Kollege, > dass alle E-Mails vom Provider mittels PKI verschlüsselt würden > und ich davon nur nichts mitbekäme, weil sich darum eben der Provider > kümmere. Naja im INTRANET ist Eure IT-Abteilung der Mailprovider, das ist sehr wohl möglich, dass die Firmenleitung auf PKI bestanden hat (sinnvoll sogar) Sollte in der Vergangenheit mal ein Datenschützer durch Eure Bude gelaufen sein, oder ihr gar einen eigenen Datenschutzbeauftragten beschäftigen, ist das sogar wahrscheinlich der Fall. In Firmennetzwerken ist sowas zumeist Serverseitig gelöst, sodass Du in der Tat davon nichts mitbekommen würdest. Ist aber nicht auszuschliessen, dass das Clientseitig schon passiert, erkennt man meist wenn man sich den Quelltext der Emails mal ansieht; da findet man häufig S/MIME oder OpenPGP signaturen, das taugt als Anhaltspunkt meist :D (mir ist kein Fall bekannt wo das nicht auf PKI deutet jdf) Also schau mal in den Quelltext Deiner intranet-mails und wenn DU noch immer Zweifel hast, frag einfach bei den Schergen von der IT. MÜSSEN muss man nicht PKI verschlüssen, sollte man aber.. bessere Firmen tun das spätestens seit inkrafttreten der DSGVO auch. 'sid
Ist lange her, als ich mir mal openPGP eingerichtet hatte. Da war es so, dass man ein Schlüsselpaar erstellen musste. Ich erinnere mich, dass man dort dann mit den Kontakten öffentliche Schlüssel austauschen konnte. Ich denke, dass Sid recht hat mit seiner Vermutung. Leider kann ich mir den Ablauf nicht erklären. Wenn mir ein Kunde eine E-Mail schickt, braucht er doch meinen persönlichen öffentlichen Schlüssel. Wie kommt er an den ran?
Inzwischen gibt es auch google und Wikipedia. Hat sich aber anscheinend noch nicht überall rumgesprochen. https://de.wikipedia.org/wiki/Pretty_Good_Privacy Oliver
Torben S. schrieb: > Ich denke, dass Sid recht hat mit seiner Vermutung. Nein, "'sid" schreibt wie immer halbgaren Senf, den er irgendwo aufgeschnappt hat. Ich gehe nicht davon aus, dass bei euch eine Verschlüsselung läuft, die über TLS zum Provider hinausgeht. Aber ohne Informationen zu eurer Infrastruktur können wir mangels Glaskugel ohnehin nur raten. Torben S. schrieb: > Wenn mir ein Kunde eine E-Mail schickt, > braucht er doch meinen persönlichen öffentlichen Schlüssel. Wie kommt er > an den ran? Indem er ihn von Dir geschickt bekommt oder über Verfahren wie SMIMEA oder PGP-Keyserver selbst abholen kann.
Torben S. schrieb: > Ist lange her, als ich mir mal openPGP eingerichtet hatte. Da war es so, > dass man ein Schlüsselpaar erstellen musste. Ich erinnere mich, dass man > dort dann mit den Kontakten öffentliche Schlüssel austauschen konnte. > > Ich denke, dass Sid recht hat mit seiner Vermutung. Leider kann ich mir > den Ablauf nicht erklären. Wenn mir ein Kunde eine E-Mail schickt, > braucht er doch meinen persönlichen öffentlichen Schlüssel. Wie kommt er > an den ran? Die public Keys können auf öffentlichen Keyserver hochgeladen werden, dort kann er sich den holen, allerdings muss der Fingerprint noch auf andere Weise verglichen werden, damit er sich sicher sein kann, dass das genau dein Public Key ist. Die Public Keyserver haben allerdings den Nachteil, dass sie die E-Mailadressen gleich mit in die Datenbank übertragen. Wer also ne Vielzahl von Spammails verschicken will, der könnte die Mailadressen dann von dort sammeln. Die Idee ist somit gut, aber die Umsetzung ist schlecht. Würden nur noch mit PGP verschlüsselte oder signierte Mails akzeptiert und der Rest verworfen werden und wäre es juristisch in Ordnung, die nicht signierten und verschlüsselten einfach zu verwerfen, dann müssten die Spamversender zumindest ihre Spams auch verschlüsseln oder signieren.
Nano schrieb: > Die Idee ist somit gut, aber die Umsetzung ist schlecht. Und die vor einigen Jahren gängigste Open Source Implementierung eines solchen Keyservers ist grauenhaft.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.