Forum: PC Hard- und Software Provider verschlüsselt E-Mail-Verkehr


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Torben S. (Firma: privat) (torben_25)


Bewertung
0 lesenswert
nicht lesenswert
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

von Jack V. (jackv)


Bewertung
-3 lesenswert
nicht lesenswert
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
von René H. (mumpel)


Bewertung
0 lesenswert
nicht lesenswert
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.

von (prx) A. K. (prx)


Bewertung
2 lesenswert
nicht lesenswert
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
von René H. (mumpel)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Hmmm (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Hmmm (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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.

von René H. (mumpel)


Bewertung
0 lesenswert
nicht lesenswert
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.

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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
von 🐧 DPA 🐧 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von René H. (mumpel)


Bewertung
0 lesenswert
nicht lesenswert
Das ist vergleichbar mit einem einfachen Türschloss.

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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
von 🐧 DPA 🐧 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Hmmm (Gast)


Bewertung
0 lesenswert
nicht lesenswert
🐧 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.
von sid (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Torben S. (Firma: privat) (torben_25)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Oliver S. (oliverso)


Bewertung
0 lesenswert
nicht lesenswert
Inzwischen gibt es auch google und Wikipedia. Hat sich aber anscheinend 
noch nicht überall rumgesprochen.

https://de.wikipedia.org/wiki/Pretty_Good_Privacy

Oliver

von Hmmm (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.