Frage:
Why is end-to-end encryption still not default in mails?
Chris Pillen
2016-06-16 19:02:05 UTC
view on stackexchange narkive permalink

Ich bin kein Kryptograf. Vielleicht sehe ich deshalb die Probleme bei der Integration von PGP in SMTP nicht.

In meinem Kopf: Lea fordert den Server von Lukes Domain jedi.com auf, ihr den öffentlichen Schlüssel von [email protected] mitzuteilen (Die Anfrage enthält möglicherweise eine Verschlüsselungsmethode). Sie erhält den Schlüssel PUBLIC zurück. Dann verschlüsselt sie die Nachricht und Luke kann sie leicht entschlüsseln.

Es ist nicht so schwer, warum ist sie nicht seit Jahren Standard?

Benutze einfach die Kraft, Luke.
In meinem Kopf bittet Lea den Server von Lukes Domain jedi.com, ihr den öffentlichen Schlüssel von [email protected], [email protected], ..., [[email protected]] (http://i.imgur.com/KrET41y) mitzuteilen.png).Sie verschlüsselt Spam und Malware, die bis zum Endbenutzer gelangen.Obwohl E-Mails immer noch routingfähig sein müssen, sehen schändliche Traffic-Sniffer immer noch, wer die E-Mails gesendet und empfangen hat - und die Server, die sie durchlaufen haben, können sie weiterhin protokollieren.Dann erhält Lea einen Anruf von der Personalabteilung, weil sie ihrer ausgehenden E-Mail keinen automatischen Haftungsausschluss hinzufügen konnte.Luke, der seine neue mobile App ohne PGP verwendet, kann sie sowieso nicht lesen.
@TessellatingHeckler HR ist (wieder) eindeutig inkompetent;Jeder vernünftige Haftungsausschluss ist 7-Bit-sauber und kann in "Kommentar" eingetragen werden.OTOH _Sicherheit_ oder _Konformität_ in Bereichen wie Finanzen oder Medizin oder Recht oder Medien oder Fertigung - oder Regierung!- kann verlangen, dass sie ADK verwendet, was ein Upgrade auf eine kostenpflichtige Version erfordert, nur dass ihre Datenbank nicht korrekt konvertiert wird. :-)
@dave_thompson_085 "_HR .... sane ...._" Da ist dein Problem :-)
@TessellatingHeckler Nitpick: Wenn End-to-End-Verschlüsselung die Standardeinstellung wäre, würde Lukes mobile App dies unterstützen.Dieser Teil Ihres Arguments ist also zirkulär: Es ist nicht die Standardeinstellung, weil es nicht die Standardeinstellung ist.(Der Rest Ihrer Argumentation sieht für mich gut aus.)
Sollte das nicht * Leia * sein und nicht * Lea *?
Fünf antworten:
#1
+53
Lie Ryan
2016-06-16 20:03:56 UTC
view on stackexchange narkive permalink

Es ist nicht so schwer, warum ist es nicht seit Jahren Standard?

Weil dies das Problem, das PGP zu lösen versucht, nicht gelöst hätte.

PGP ist eine End-to-End-Verschlüsselung. Wenn der SMTP-Server die Verschlüsselung auf irgendeine Weise untergraben kann, schlägt das Schema fehl.

Im Fall des von Ihnen vorgeschlagenen Schemas Angenommen, Alice ([email protected]) möchte eine private Nachricht an Bob ([email protected]) senden. Mit dem von Ihnen vorgeschlagenen Schema ruft der E-Mail-Client von Alice oder der SMTP-Server von Alice den öffentlichen Schlüssel von Bob ab, indem eine TLS-Verbindung zu dave.com hergestellt wird. Dies ist in Ordnung, solange dave.com ehrlich ist und tatsächlich Bobs öffentlichen Schlüssel zurückgibt. Dave.com könnte jedoch vom Betreiber von dave.com so konfiguriert worden sein, dass ein von Eve erstellter gefälschter öffentlicher Schlüssel zurückgegeben wird, oder Eve könnte sich in dave.com hacken und diesen einrichten. Jetzt würde Alices Mail-Client / Mail-Server gerne Eves Zertifikat akzeptieren, da er glaubt, der öffentliche Schlüssel sei Bobs. In diesem Modell kann der Betreiber von dave.com alle E-Mails von Bob abfangen.

Solange dave.com ehrlich ist, schützt dies dennoch vor Spoofing durch Dritte. Warum machen wir das nicht trotzdem, wenn dies zumindest vor dem Schnüffeln durch Dritte schützt? Hauptsächlich, weil SMTPS auch das gleiche Schutzniveau bietet und gleichzeitig viel einfacher ist. Wenn MITM durch den Mailserver-Betreiber nicht Ihr Anliegen ist, können Sie Ihre E-Mails bereits sehr gut sichern, indem Sie sicherstellen, dass Sie beide SMTPS verwenden.

Beachten Sie, dass es bei der Schwierigkeit der End-to-End-Verschlüsselung nicht darum geht, öffentliche Schlüssel abzurufen . Die meisten E-Mail-Clients, die PGP unterstützen, unterstützen auch das automatische Abrufen öffentlicher Schlüssel von LDAP oder HPKP. Die Schwierigkeit der End-to-End-Verschlüsselung besteht darin, die öffentlichen Schlüssel zu überprüfen.

Es ist keine Methode zur Überprüfung öffentlicher Schlüssel bekannt, die für die Benutzer vollständig transparent und vollständig sicher ist. Das Web of Trust- oder Certificate Authority-Modell kommt am nächsten, aber das Web of Trust weist viele Einschränkungen auf, und das Certificate Authority-Modell ist für die Überprüfung auf einen Dritten angewiesen.

Könnte der öffentliche Schlüssel nicht einfach irgendwie zertifiziert werden?
@ChrisPillen las den letzten Absatz noch einmal.tl; dr: Niemand hat eine sichere Methode gefunden, mit der das tatsächlich funktioniert.
"PGP" verwendet nicht "PKI" (sondern "Web of Trust"), oder?Meinten Sie stattdessen "S / MIME" (https://en.wikipedia.org/wiki/S/MIME)?
@IvanKolmychek: In geschlossenen Umgebungen kann PGP auf eine Art und Weise verwendet werden, die einer Zertifizierungsstelle ähnelt, indem alle öffentlichen Schlüssel, mit denen Sie kommunizieren, von einer vertrauenswürdigen Person zertifiziert werden.So wird PGP normalerweise nicht verwendet, aber technisch gesehen gibt es keinen so großen Unterschied zwischen WoT und CA.
Ja, das kann es, aber in der PKI drückt niemand sein Vertrauen zu etwas wie CA aus, indem er seine PK signiert.In einem Unternehmen kann es beispielsweise viel schwieriger sein, die "CA" in WOT zu fälschen, da möglicherweise einige wichtige Mitglieder für die Unterzeichnung erforderlich sind.Aber das sind Details.
Es gibt eine offensichtliche sichere Methode.Die Benutzer müssen ihre E-Mail-Adresse veröffentlichen, damit andere sie trotzdem senden können.Lassen Sie einfach auch den Schlüssel los.Aber wenn Sie online eine E-Mail-Adresse finden, können Sie natürlich nicht wissen, ob er sich bereits ein Leben lang in einem Gefängnis befindet, und Eve, der Betreiber, erledigt alles für ihn am Computer.
`> Lassen Sie einfach auch den Schlüssel los .` Wer garantiert, dass der veröffentlichte Schlüssel nach der Veröffentlichung nicht von Eve geändert wurde?Sie könnte es überhaupt veröffentlichen und Bob kann sich der Tatsache nicht bewusst sein, dass ein Schlüssel irgendwo als "sein" Schlüssel veröffentlicht wird.Aus diesem Grund haben die Leute Schlüsselunterzeichnungspartys, bei denen die Leute normalerweise ihre öffentlichen Schlüssel austauschen, meistens sogar auf Papier geschrieben / gedruckt (siehe https://security.stackexchange.com/questions/126533/why-shouldnt-i-bring-a-Computer-to-a-Key-Signing-Party)
#2
+33
Steffen Ullrich
2016-06-16 19:55:58 UTC
view on stackexchange narkive permalink

Integration von PGP in SMTP.

PGP ist ein Containerformat für Daten (wie E-Mails, jedoch nicht auf E-Mails beschränkt), das den Daten Verschlüsselung und / oder Signatur hinzufügt. SMTP ist ein Transportprotokoll.

Sie integrieren keine Containerformate in Transportprotokolle. Dies entspricht der Aussage, dass Sie Office (Container für Text, Bilder ...) in SMTP (Transport) integrieren sollten, um ein Office-Dokument an jemanden zu senden.

PGP wird auch außerhalb von SMTP verwendet. weil es nur ein Container ist. SMTP wird auch zum Transportieren von Dingen verwendet, die sich von PGP-Containern unterscheiden, da es sich nur um ein Transportprotokoll handelt.

Wenn Sie stattdessen nach der Integration von End-to-End-Verschlüsselung wie PGP oder S / MIME in SMTP fragen, wird dies der Fall sein funktioniert auch nicht, da SMTP Hop-by-Hop-Bereitstellung und nicht End-to-End ist. Abgesehen davon deckt SMTP nicht einmal den letzten Hop ab, d. H. Die Zustellung vom letzten Mailserver an den Client. Dies geschieht mit Protokollen wie POP oder IMAP.

Lea fordert den Server von Lukes Domain jedi.com auf, ihr den öffentlichen Schlüssel von [email protected] mitzuteilen ...

Dafür haben Sie Schlüsselserver oder andere Arten von zentralen Verzeichnissen. Aber woher weiß Lea, dass dies tatsächlich Lukes Schlüssel ist und nicht der Schlüssel von jemandem, der behauptet, Lukas zu sein? Daher benötigen Sie eine gewisse Vertrauensausbreitung, beispielsweise in Form eines Vertrauensnetzes (PGP) oder einer zentraleren Struktur (S / MIME) oder indem Sie alles in einem bestimmten zentralen Verzeichnis vertrauen.

Also Die Aufgabe besteht nicht darin, PGP in SMTP zu integrieren, sondern PGP in den E-Mail-Clients besser zu unterstützen, damit diese automatisch die PGP-Schlüssel der Empfänger abrufen. Natürlich muss zuerst ein überprüfbarer PGP-Schlüssel für den Empfänger irgendwo auf einem Schlüsselserver oder einem anderen Verzeichnis vorhanden sein. Die andere Aufgabe besteht darin, das Erstellen, Veröffentlichen und Verwalten von Schlüsseln (Erneuern, Widerrufen ...) zu vereinfachen. Dies sind alles Dinge außerhalb der Postzustellung (SMTP) selbst.

+1 zur Erklärung des Unterschieds zwischen Containern und Protokollen.
#3
+4
Bryan Field
2016-06-16 19:21:43 UTC
view on stackexchange narkive permalink

Die Verschlüsselung ist bereits während der E-Mail-Übertragung vorhanden ( STARTTLS in SMTP), aber nicht hoch genug, um sich vor MITM zu schützen.

Ich glaube, PGP ist eher ein Endbenutzer Erfahrung zwischen E-Mail-Clients, die hilfreich ist, wenn Sie den beteiligten Servern nicht voll vertrauen.

(PGP ist manchmal für MITM anfällig für den weniger vorsichtigen Benutzer, wie bei SSH. Wenn Sie nach der richtigen Schlüsselsignatur suchen, ist das Problem behoben.

Bei Cloud-basierten E-Mail-Diensten wie Google Mail müssten diese jedoch für eine gute Benutzererfahrung ohnehin für den Server verfügbar sein Daher würde PGP nur in die Quere kommen.

Hoffentlich erhalten wir eines Tages eine MITM-sichere Verschlüsselung in SMTP, aber dies ist dort weniger problematisch, da sich Mailserver in kontrollierten Netzwerken befinden.

SSH und PGP sind beim ersten Handshake nicht unbedingt anfällig, solange Sie die Schlüsselsignaturen überprüfen, bevor Sie sie verwenden.
Google Mail wird dies nicht tun, da das Lesen Ihrer E-Mails das Geschäftsmodell ist.
#4
+4
phyrfox
2016-06-16 23:42:10 UTC
view on stackexchange narkive permalink

Das Schreiben eines Standards ist einfach. Ich habe vor ungefähr zehn Jahren über genau dieses Problem nachgedacht. Es kommt auf den Faktor Mensch / Kosten an. Wie können Sie eine Milliarde technologisch Analphabeten davon überzeugen, ihre Software ohne wahrgenommenen Nutzen zu aktualisieren, und die Tausenden von Entwicklern auf einigen Plattformen davon überzeugen, dieses Protokoll zu implementieren, und Millionen von Organisationen, auf ein neues Protokoll umzusteigen, selbst wenn Sie verschenken . Wir haben unsere IPv4-Adressen in einigen Teilen der Welt bereits 2011 erschöpft, und dennoch verwendet das Internet IPv6 weltweit nicht. Wir können die Leute nicht einmal davon überzeugen, auf IPv6 umzusteigen, obwohl wir das Wachstum des Internets buchstäblich unterdrücken. Selbst wenn Sie heute einen Standard herauspeitschen und zur Formalisierung und Verteilung an die IETF senden könnten, wäre es 2030, bevor er weit genug verbreitet wäre, um die unzähligen "klassischen" Mailserver herunterzufahren, die heute ausgeführt werden.

Ganz zu schweigen davon, wer weiß, wie viele benutzerdefinierte Funktionen triviale SMTP-Nachrichten / Warnungen generieren, wer weiß, wie viele Apps von PCs zu Mainframes.
#5
  0
RC NL
2016-06-17 19:35:50 UTC
view on stackexchange narkive permalink

Nun, wie Sie oben lesen können, können Sie SMTPS und STARTTLS verwenden, um die Sicherheit für SMTP-Server beim Senden von E-Mails zu verbessern. MITM kann mit DKIM verringert werden.

DomainKeys Identified Mail (DKIM) ermöglicht Eine Organisation übernimmt die Verantwortung für eine Nachricht, die gerade gesendet wird. Die Organisation ist ein Handler der Nachricht, entweder als Urheber oder als Vermittler. Ihr Ruf ist die Grundlage für die Beurteilung, ob der Nachricht für die weitere Bearbeitung, z. B. die Zustellung, vertraut werden soll. Technisch gesehen bietet DKIM eine Methode zum Überprüfen einer Domänennamenidentität, die einer Nachricht durch kryptografische Authentifizierung zugeordnet ist.

Kurz gesagt, mit DKIM können Sie feststellen, ob E-Mails vom Ursprung stammen, den der E-Mail-Header angibt kommt von. Wo der Server dann zuverlässig entscheiden kann, ob die Nachricht vertrauenswürdig ist (wenn die DKIM-Authentifizierung fehlschlägt, können Sie die E-Mail löschen und müssen sich keine Sorgen machen, wenn eine gefälschte Nachricht den SMTP-Server in eine Spam-House-Liste aufnimmt).

Und diese Art rundet den Kreis. Mit STARTTLS zur sicheren Authentifizierung können Sie eine zuverlässige Verbindung zu einem SMTP-Server herstellen und Ihre E-Mails an einen Mailserver senden. DKIM kann feststellen, ob ein bestimmter SMTP-Server berechtigt ist, E-Mails von einer bestimmten Adresse zu senden E-Mail-Zustellung vom SMTP-Server zum Mailserver, um die Verbindung zu verschlüsseln. STARTTLS zwischen E-Mail-Client und E-Mail-Server (sofern es sich nicht um einen Webmail-Client handelt, kann eine sichere Socket-Verbindung über POP oder IMAP ausreichen)



Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...