Das größte Hindernis für Ihren Vorschlag ist die Benutzerakzeptanz und Verhaltensänderung. Stellen Sie sich vor, Sie müssen jedem erklären, was ein öffentlicher Schlüssel ist und wie großartig er ist. Dies wird einfach nicht passieren.

Stattdessen hat sich die E-Mail-Sicherheit auf die Seite des Mailservers verlagert, mit mehreren Zielen:

• Transportverschlüsselung. Dies ist bereits ziemlich weit verbreitet
• Absenderauthentifizierung (zur Authentifizierung der sendenden Domäne, nicht des einzelnen Benutzers), was etwas langwieriger ist und auf beträchtlichem Wissen des einzelnen E-Mail-Servers beruht Administratoren (als jemand, der SPF / DKIM / DMARC einrichten musste, kann ich Ihnen sagen, dass es nicht viel Spaß macht).

Ihr Vorschlag abzüglich des Hochladens Ihres persönlichen Schlüssels (stattdessen wird er automatisch generiert) ist mehr oder weniger Transportsicherheit, aber ohne Authentifizierung. Der Authentifizierungsteil ist schwierig und wird von den genannten Akronymen versucht, wenn auch mühsam.

Als Randnotiz: Für eine ordnungsgemäße End-to-End-E-Mail-Verschlüsselung müssen Sie entweder 1) dem Web vertrauen -basierter E-Mail-Anbieter mit Ihren Schlüsseln oder 2) Verwenden Sie einen lokalen Client, der Ihren privaten Schlüssel kennt. Ersteres ist für viele unerwünscht, letzteres ist für die meisten Menschen unpraktisch.

Eine weitere Randnotiz: HTTPS wurde weitgehend übernommen, da es für die meisten Benutzer (meistens) unsichtbar ist, abgesehen von den Browser-Warnungen. Moderne E-Mail-Verschlüsselung / Authentifizierung ist das Äquivalent dazu. Aber das Äquivalent zu jedem, der ein Schlüsselpaar für E-Mails hat, würde die Leute bitten, Client-Zertifikate zu verwenden, um sich auf Websites anzumelden. ugh!

Es mag einfach erscheinen, ist es aber nicht. Es ist tatsächlich sehr kompliziert.

Es gibt einige bewegliche Teile, die schwer zu reparieren sind:

• Benutzererziehung: Verlassen Sie sich nicht darauf, dass die Leute wissen, was ein Schlüsselpaar ist ist, wie man einen erstellt, wie man seine Schlüssel schützt.

• vergessene / verlorene Schlüssel: Wenn ein TLS-Zertifikat verloren geht, fordert der Eigentümer nur einen anderen an. Es geht kein Verkehr verloren. Wenn ein Benutzer seinen Schlüssel verliert, sind alle seine vorherigen E-Mails nicht lesbar. Für immer.

• MiTM: Wenn Ihr Provider sowohl Ihre E-Mails als auch Ihr Schlüsselpaar speichert, kann er jede E-Mail lesen und ändern. Wenn sie nur über Ihren öffentlichen Schlüssel verfügen, können sie Ihre E-Mails mitmischen, indem sie Ihren Freunden einen Schlüssel zur Verfügung stellen, den sie besitzen, und Ihren Schlüssel erneut verschlüsseln, bevor sie an Sie weitergeleitet werden. Wenn Sie ihnen nicht den Schlüssel außerhalb des Bandes senden (SMS, E-Mail von einem anderen Server, persönlich), wissen sie nicht, dass Ihr Schlüssel nicht wirklich Ihr Schlüssel ist.

Angesichts der Tatsache, dass sogar TLS ist nahtlos und die Leute klicken immer noch auf Fehler und laden unsichere Websites mit gefälschten Zertifikaten und verwenden Passwort als Passwort. Ich bezweifle, dass dies weit verbreitet wird und Benutzer sicher sind.

Es wurde in anderen Antworten und Kommentaren angesprochen, aber ich denke, der grundlegende Unterschied zwischen Web- und E-Mail-Verkehr besteht darin, wer die beteiligten Parteien sind.

HTTPS macht tatsächlich zwei Dinge:

• Es verschlüsselt die Kommunikation, so dass sie von einem Angreifer nicht gelesen werden kann. Dies wird durch eine zustandsbehaftete Sitzung erreicht, die direkt zwischen dem Browser des Benutzers und dem Webserver ausgehandelt wird. Dies geschieht auf derselben TCP- (oder QUIC-) Verbindung, über die die eigentlichen Nachrichten gesendet werden.
• Es authentifiziert die Kommunikation, sodass sie nicht manipuliert werden kann / em> von einem Angreifer. Dies wird mithilfe einer Hierarchie vertrauenswürdiger Berechtigungen erreicht, wobei an einem Ende eine statische Liste vorhanden ist, die jeder Client verwalten muss, und am anderen Ende ein eindeutiges Zertifikat, das jeder Server erhalten muss.

Beide Diese nutzen die besondere Topologie des Webs: Viele Clients stellen eine direkte Verbindung zu einer viel geringeren Anzahl von Servern her. Vermittler, die den Klartextverkehr lesen müssen, um ihn weiterzuleiten, sind relativ selten.

Bei E-Mails sind beide problematisch:

• Für die Verschlüsselung Der tatsächliche Absender einer Nachricht stellt im Allgemeinen keine direkte Verbindung zu ihrem Empfänger her, sodass eine zustandsbehaftete Sitzung zwischen ihnen nicht auf die gleiche Weise bestehen kann. Einzelne Verbindungen, bei denen die Nachricht übertragen wird, können verschlüsselt werden (und sind es jetzt häufig) - z. von Ihrem Desktop-Mail-Client zu GMail und von GMail zu FastMail - es gibt jedoch kein Äquivalent zu der End-to-End-TCP-Verbindung, über die HTTPS ausgehandelt wird.
• Für die Authentifizierung sind die Entitäten, die authentifiziert werden müssen, die Millionen einzelner Benutzer, nicht eine kleine Anzahl von Servern. Dies bedeutet, dass wir eine Vertrauenshierarchie benötigen, die von jedem E-Mail-Client (der ein authentifiziertes Schlüsselpaar auswählt) zu jeder einzelnen Adresse führen kann. Wenn Sie darauf vertrauen, dass Fastmail Schlüssel für jede @ fastmail.com -Adresse bereitstellt, wird nichts wirklich gelöst. Sie können den Transport der Nachricht wieder verschlüsseln, anstatt zu beweisen, wer sie erhalten hat. Dies wird noch komplizierter, da die Authentifizierung, die Sie für E-Mails wünschen, tatsächlich umgekehrt ist : Um Spam und Identitätswechsel zu vermeiden, möchten Sie den Absender jeder Nachricht nicht authentifizieren der Empfänger .

Dies alles führt, wie andere gesagt haben, zum aktuellen Stand der Dinge:

• Verschlüsselung auf Transportebene in POP3, IMAP und SMTP sind üblich und im Allgemeinen vollständig transparent.
• Absender, die authentifizierte Verschlüsselung an bestimmte Empfänger aushandeln, sind außerhalb geschlossener Netzwerke selten.
• Für Empfänger gibt es verschiedene Protokolle Absender authentifizieren (z. B. DKIM usw.), was durch das Fehlen einer direkten Verhandlungsverbindung und die komplexe Art und Weise, wie Benutzer mit dem Netzwerk interagieren, erschwert wird. Wenn Sie sich Adressen ansehen, die mit @ gmail.com enden, scheint dies einfach zu sein. Stellen Sie sich jedoch vor, wie viele Kunden und Dienste zum Senden und Empfangen von E-Mails für Adressen mit der Endung @apple.com berechtigt sind.

Das Thema ist sehr komplex und in einer einzelnen Antwort schwer zu erklären. Ich verstehe, dass Sie Ihren Mangel an CS-Ausbildung offengelegt haben. Deshalb müssen wir dies hier erklären.

Transport vs. Ende zu Ende

Es gibt einen großen Unterschied zwischen Transportverschlüsselung starke> und End-to-End-Verschlüsselung . Sie sollten sie nicht verwechseln.

HTTP wird als Transportverschlüsselung ( Transport Sicherheitsschicht) geboren, damit die Kommunikation zwischen Browser und Server geschützt bleibt. Wenn Sie sich bei Ihrem Home Banking anmelden, ist Transport gleich Ende zu Ende, da Ihre Bank das andere Ende der Kommunikation ist. Wenn Sie sich bei Webmail anmelden, handelt es sich nur um einen Transport, da Ihr Anbieter Ihre E-Mails lesen kann, um sie anzuzeigen.

E-Mails sind bereits (meistens) transportverschlüsselt.

Was Sie Möglicherweise wissen Sie nicht, dass E-Mails bereits über TLS (das Protokoll unter https) gesendet werden. Mit Ausnahme einiger Small-Office-Netzwerke, kleinster ISPs, Homebrew-Server usw. werden alle E-Mails verschlüsselt zwischen ISPs übertragen. Nur sie kennen den Inhalt der E-Mails.

Der Umfang Ihrer Frage könnte also etwas verwirrend sein. Zur Vereinfachung werden E-Mails bereits mit dem Äquivalent von https übertragen. Sie sagten, "https ist beliebt", ich sage, dass TLS auch für E-Mails beliebt ist.

Die Last der End-to-End-Verschlüsselung

Https ist einfach bereitzustellen. Nur der Server muss ein Zertifikat bereitstellen, jede Verbindung ist zustandslos und vergisst alles über den Verlauf.

Verschlüsselte End-to-End-E-Mails sind für Verbraucher ein großer Schmerz . P. >

• Zertifikate müssen eingerichtet werden. Nicht alle Personen verfügen über ausreichend Fachwissen.
• Was ist, wenn der Benutzer den Schlüssel / das Gerät verliert? Sie verlieren den gesamten E-Mail-Verlauf.
• Heute geben Sie einfach Benutzername / Passwort ein. Welche zusätzlichen Konfigurationsschritte sind für e2e-geschützte E-Mails erforderlich? Akzeptiert meine Oma alle Arten von Sicherheitskonfigurationen?
• Was ist mit mehreren Geräten? Wie gehe ich mit mehreren Geräten um? Zum Beispiel Outlook + Mobile. Oh, und Webmail beim Roaming

Nehmen Sie ein Beispiel: WhatsApp. Es gab nie eine Funktion zum Teilen des Konversationsverlaufs auf mehreren Geräten (die WhatsApp-Desktopversion lädt Nachrichten von Ihrem Telefon herunter, die verbunden sein müssen). Wenn Sie Ihr Telefon verlieren oder formatieren und keine unverschlüsselte Sicherung haben, geht Ihr Verlauf verloren.

Es gibt einen wichtigen Unterschied zwischen den beiden.

In der Entscheidungstheorie gibt es die Idee des Dienstprogramms , dh den Wert, den jemand den verschiedenen Optionen in einer Entscheidung zuweist . Für ein Infrastrukturnetz wie ein Straßennetz, eine Eisenbahn, das Internet oder eine E-Mail ist der Wert für eine Person die Anzahl potenzieller Verbindungen / anderer Personen, die Teil des Netzes sind, der Wert für den Betreiber des Netzes als Ganz ist die Anzahl der Verbindungen, die in der Größenordnung des Quadrats der Elemente liegt.

Das Problem dabei ist, dass sowohl für das einzelne Mitglied als auch für den Bediener die Kosten anfänglich sehr hoch sind, während in drehen Sie den Wert ist niedrig. Es erfordert das Überschreiten eines bestimmten Schwellenwerts (als kritische Masse bezeichnet), bis der Wert tatsächlich die Kosten überwiegt. Für den Betreiber bedeutet dies im Allgemeinen, dass sich nur große Betreiber den Aufbau eines solchen Netzwerks leisten können. In der Vergangenheit bedeutete dies Regierungsorganisationen. Dies bedeutet auch, dass es keinen Sinn macht, mehrere Netzwerke zu haben: Je größer das Netzwerk, desto höher der Wert, und sobald die kritische Masse überschritten ist, wächst der Wert schneller als die Kosten. Diese beiden zusammen führen zu einem sogenannten natürlichen Monopol , bei dem ein einzelner Bediener "gewinnt" und alle anderen verdrängt, ohne auf dieses Ziel hinzuarbeiten. Der Betreiber wird nicht durch Maßnahmen zum Monopolisten, sondern einfach aufgrund der Art und Weise, wie der Markt für dieses besondere Gut funktioniert.

Lange Rede, kurzer Sinn: Für verschlüsselte E-Mails gibt es kein Unternehmen, das bereit ist, die Kosten für das Netzwerk zu investieren. und die Individuen werden die Kosten nicht investieren, weil ... nun ... warum sollten sie? Warum sollte ich mir die Mühe machen, verschlüsselte E-Mails einzurichten, wenn es niemanden gibt, an den ich sie senden kann?

Bei HTTPS ist die Situation ganz anders: Hier gibt es einen Vorteil für jeden einzelnen Serverbetreiber. Der Schutz der Benutzer schützt das Unternehmen. Der Wert liegt in der Größenordnung der Anzahl der Benutzer, während die Kosten nahezu konstant sind (und bei Diensten wie Let's Encrypt eher niedrig sind und fast nicht existieren), wobei der Stromverbrauch pro Benutzer nur geringfügig linear ist. Sie müssen einer großen Anzahl von Servern im Netzwerk kein TLS hinzufügen, um einen Vorteil zu erzielen, und es müssen keine massiven Vorabinvestitionen getätigt werden. Dies kann Server für Server von jedem einzelnen Serverbetreiber mit geringen Vorlauf- und Betriebskosten und sofortigem Wert durchgeführt werden.

(Ich beschönige hier die erforderliche Zertifikatinfrastruktur, was wiederum ein Beispiel ist eines Infrastrukturnetzwerks mit einem natürlichen Monopol, aber es ist ein viel kleineres Problem, da die Teilnehmer im Wesentlichen nur die Zertifizierungsstellen sind, nicht "alle Webbenutzer", was ein völlig unlösbares Problem wäre.)

Es ist die Schlüsselverteilung.

Ich werde nicht auf alle wichtigen Details eingehen, aber wenn Sie eine Verbindung zu einer HTTPS-Site herstellen, passieren einige Dinge. Ihr Computer tauscht Schlüssel mit der Site aus und überprüft vor allem, ob die Site (z. B. Ihre Bank) tatsächlich Ihre Bank ist. Wenn dies nicht der Fall wäre, könnte sich etwas als Ihre Bank ausgeben, Ihren Datenverkehr entschlüsseln, Ihre Passwörter lesen und den Datenverkehr an die Bank senden (dies wird als MITM-Angriff (Man In the Middle) bezeichnet).

Um dies zu verhindern, müssen Sie beim Einrichten einer SSL-Site ein Zertifikat erhalten, für das eine vertrauenswürdige Partei bürgt, die Ihr Eigentum an dem Domainnamen überprüft hat. Früher war dies ziemlich schwierig und teuer (Hunderte von Dollar), aber da es nur für die Websites und nicht für den Endbenutzer benötigt wird, wurde es toleriert. (In letzter Zeit ist es billiger und einfacher geworden, aber es ist immer noch nicht trivial.)

Damit ein ähnliches System für E-Mails verwendet werden kann, müssen Endbenutzer einen ähnlichen Überprüfungsprozess durchlaufen. Da Benutzer davon ausgehen, dass E-Mails kostenlos sind, zögern sie, dies zu tun.

(Der andere Weg ist, dass Sie ein verteiltes System anstelle eines vertrauenswürdigen Organisationsmodells haben - dies ist billiger und beliebt als Angelegenheit der Politik, ist aber in der Praxis umständlich).

Um die Hauptfrage zu beantworten:

Für viele HTTPS-Sites wird Ihnen nicht einmal eine Auswahl angeboten. Sie leiten Sie zu HTTPS weiter und verwenden häufig HSTS, was Sie daran hindert, wieder zu HTTP zu wechseln.

Wenn eine Site Sie nicht umleitet, gibt es immer Verwendungen, die nur HTTP ohne TLS verwenden, da sie sich nicht darum kümmern Sicherheitsindikatoren in der Adressleiste. Wenn HTTP (ohne TLS) beliebter war, erzwangen Websites häufig TLS auf Anmeldeseiten, sodass Ihre Kennwörter geschützt sind und Sie auch keine andere Wahl haben.

Wenn der Benutzer dies nicht tut Pflege, die Entscheidung liegt auf der Seite der Website / E-Mail-Administrator. Das Hinzufügen von TLS ist einfach und funktioniert in allen modernen Browsern. Wenn Sie dies wirklich möchten, können Sie (sehr) alte Browser unterstützen, indem Sie HTTP ohne TLS anbieten. Da dies für den Benutzer wie oben erwähnt größtenteils transparent ist, können Sie frei entscheiden, und das Hinzufügen von Verschlüsselung kann Ihre Bewertung nur durch (Haupt-) Benutzer verbessern.

Bei E-Mails sieht dies völlig anders aus. Wenn Sie verschlüsselt mit dem Benutzer kommunizieren möchten, muss der Benutzer Mailprogramm- oder Browser-Addons installieren, einen Schlüssel erstellen, den Schlüssel verwalten, sicherstellen, dass der Schlüssel auf allen von ihm verwendeten Geräten verfügbar ist, und möglicherweise eine Passphrase eingeben von Zeit zu Zeit.

Dies ist eine Belastung für den Benutzer, und wenn er nicht versteht, worum es geht, wird er dies als Ärger empfinden. Die Einführung der Verschlüsselung ist also überhaupt nicht transparent, erfordert jedoch, dass der Benutzer einen neuen Workflow lernt und einen komplizierteren Workflow verwendet . Für einen Benutzer, der den Unterschied nicht kennt oder sich nicht darum kümmert, ist dies ein Grund gegen Ihren Dienst.

Genau wie bei HTTPS gibt es Transportschichtsicherheit für E-Mails und weil es genauso ist So transparent HTTPS für den Benutzer ist, es ist weit verbreitet. Es gibt einige Nachteile (wie Fallbacks bei unverschlüsselten Verbindungen), aber im Allgemeinen werden viele E-Mails verschlüsselt zwischen den E-Mail-Servern und zwischen dem ersten / letzten E-Mail-Server und dem Absender- / Empfänger-Client übertragen.