Ist die Durchsetzung der Verschlüsselung für SMTP (noch) eine gute Idee?

36

Ich verwende einen E-Mail-Server, der derzeit so eingerichtet ist, dass er TLS verwendet, wenn E-Mails gesendet und empfangen werden.

Wenn Sie in der Dokumentation darüber lesen, können Sie auch TLS erzwingen und die Übertragung von E-Mails im Klartext nicht akzeptieren. Außerdem werden Sie gewarnt, dass einige Mailserver die Verschlüsselung möglicherweise noch nicht unterstützen und dass die Durchsetzung der Verschlüsselung diese Server blockieren kann.

Aber ist dies immer noch ein Thema, über das man nachdenken sollte, oder kann man mit Sicherheit sagen, dass die Durchsetzung der Verschlüsselung kein Problem mehr ist?

Gibt es möglicherweise einen großen Anbieter, der dies bereits tut, oder was halten Sie derzeit für die beste Vorgehensweise?

encryption tls smtps

— comfreak
quelle

34

Das praktische Problem ist, dass nicht jeder SMTP-kompatible (der RFC ist ziemlich alt) Server TLS mit Ihrem Server sprechen kann, sodass Sie möglicherweise einige E-Mail-Nachrichten nicht erhalten.

Das philosophische Problem dabei ist, dass es unmöglich ist zu sagen, wie die E-Mail weitergeleitet wird, nachdem sie auf Ihrem Server angekommen ist (oder bevor sie angekommen ist).

Dies bedeutet, dass die E-Mail möglicherweise bereits über ein Relais im Klartext übertragen wurde.

Jeder, der es ernst meint, den Inhalt seiner E-Mails zu schützen, sollte den Text tatsächlich verschlüsseln. Mit Verschlüsselung unterwegs ist es immer plausibel, dass es bereits im Klartext übertragen wurde.

Die Beantwortung Ihrer Frage nach der Durchsetzung der Verschlüsselung auf der SMTP-Ebene ist wahrscheinlich sinnlos, erhöht die Wahrscheinlichkeit, dass E-Mails fehlen, und es gibt keine garantierte vorteilhafte Auszahlung.

Bearbeiten: Dies bezieht sich auf die SMTP-Erzwingung zum Weiterleiten, nicht zum Senden von E-Mails. Bei E-Mail-Übermittlungen sollte die Verschlüsselung erzwungen werden, da die SMTP-Konversation (nicht die eigentliche E-Mail) möglicherweise Authentifizierungsinformationen enthält.

— Matthew Ife
quelle

7

Ich denke nicht, dass dies die beste Antwort ist. Es kommt zum richtigen Fazit, aber aus den falschen Gründen. Es geht darum, "das Perfekte zum Feind des Guten zu machen". Ich denke, die bessere Antwort ist, dass Sie, wenn Sie eine Verschlüsselung benötigen, verhindern, dass legitime E-Mails durchkommen (da einige SMTP-Server nicht verschlüsseln können). Ohne diesen Faktor wäre die Durchsetzung der Verschlüsselung von Vorteil, auch wenn sie aus allen Gründen, die Sie auflisten, nicht perfekt ist - sie wäre besser als nichts, auch wenn sie nicht perfekt ist.

— DW

Ich neige dazu, Perfektion durch bloße Hinzufügung von Subperfektionen nicht zu akzeptieren. Trotzdem habe ich eine Änderung an der Antwort vorgenommen, um die mögliche technische Inkompatibilität von Servern hervorzuheben, die dem RFC entsprechen, TLS jedoch nicht unterstützen.

— Alex Mazzariol

Danke für deine Antwort! Zuerst habe ich nicht darüber nachgedacht, was passiert, nachdem mein Server die Mail an den nächsten Server gesendet hat oder, wie Sie sagten, wo die Nachricht "schon" war, bevor sie mich erreichte. Natürlich macht es keinen Sinn, die Verschlüsselung durchzusetzen, wenn die empfangende Seite sie im Klartext weiterleitet (möglicherweise an einen Subserver der gleichen Firma, aber immer noch über das Internet).

— Comfreak

Ich habe diese Antwort als die akzeptierte Antwort ausgewählt, da klar ist, dass die Durchsetzung der Verschlüsselung auf meinem Server keine sichere / verschlüsselte Übertragung der Nachricht vom Absender zum Empfänger garantiert, sondern nur von meinem Server zum nächsten.

— Comfreak

Ich finde diese Antwort gut, erwähne aber nicht, dass eine Verschlüsselung immer noch erwünscht ist, wenn man bedenkt, dass nur in einer begrenzten Anzahl von Fällen jemand große Anstrengungen unternimmt, um die Klartextnachricht des Absenders abzufangen, um Sie zu täuschen. Wenn Sie sich vor der CIA / NSA verstecken, hilft Ihnen das möglicherweise nicht weiter. Aber was wäre besser, wenn Sie die Verschlüsselung erzwingen, damit niemand, der ein ausdrückliches Interesse daran hat, die Nachricht des Absenders zu lesen / abzufangen und sie zu verbergen, bis ein Dritter beschließt, Sie zu beschnüffeln oder alle Ihre Nachrichten auf den NSA-Servern zu speichern Eines Tages können sie nicht nur anfangen ...

— Momomo

20

Nein

RFC 821 ist 33 Jahre alt. Sie werden E-Mails finden, die von Programmen weitergeleitet werden, die STARTTLS nicht unterstützen. Manchmal handelt es sich um Stub-E-Mail-Absender (z. B. interne Skripte), manchmal um vollwertige Systeme, auf denen TLS deaktiviert / nicht kompiliert ist, Systeme ohne ausreichende Entropie ...

Ich habe vor nicht allzu langer Zeit gesehen, dass ausgehende E-Mails fehlschlagen, weil das empfangende Ende so konfiguriert war, dass nur SMTP über TLS zugelassen wird. Es war ein Problem beim Absender (er hätte diese Konfiguration nicht verwenden sollen), zeigt aber, dass es tatsächlich passiert.

Ich würde nur eingehende Nachrichten von manuell konfigurierten IP-Adressen einschränken. Wenn Ihr Kreditkartenprozessor STARTTLS nicht startet, ziehen Sie es wahrscheinlich vor, die Verbindung abzubrechen (und den lokalen Administrator zu benachrichtigen, damit er sie warnen kann!), Bevor Sie diese (potenziell vertraulichen) Daten unverschlüsselt empfangen. Wenn Sie bei ausgehenden Nachrichten zuvor mit STARTTLS eine Verbindung zu diesem Host hergestellt haben, möchten Sie dies möglicherweise nicht erneut mit Unsicherheit tun und es stattdessen als potenzielle Gefährdung behandeln. Möglicherweise verfügen Sie auch über eine Liste von STARTTLS-Hosts, von denen bekannt ist, dass sie immer verwendet werden, z. B. Google Mail oder Yahoo.

Es gibt ein https://www.eff.org/starttls-everywhere-Projekt , das eine Liste von SMTP-Servern bereitstellt, für die Sie die Verwendung von Starttls sicher erzwingen können (sollten?).

— Engel
quelle

3

Vielen Dank für die Antwort und für das Posten dieses Links! Dies scheint ein guter Ansatz zu sein, um das Problem eines Man-in-the-Middle-Angriffs zu lösen, bei dem die Verbindung zu einer unverschlüsselten Unterhaltung herabgestuft wird.

— Comfreak

11

Es ist völlig sinnlos und wahrscheinlich auch schädlich, E-Mails von unverschlüsselten Kollegen abzulehnen.

Solange Ihr Server für die opportunistische Verschlüsselung mit einem Peer eingerichtet ist, der ihn anbietet, erhalten Sie das Beste aus beiden Welten: Verschlüsselung, wenn verfügbar, und E-Mail über Nur-Text, wenn nicht.

Solange es Server gibt, die keine Verschlüsselung unterstützen, bedeutet dies, dass sie nicht mit Ihnen sprechen können. das ist schlecht. Sobald alle es unterstützen, gibt es keinen Unterschied zwischen opportunistischer und obligatorischer Verschlüsselung.

Und wie andere betont haben, sind die Verschlüsselung im laufenden Betrieb und die Ende-zu-Ende-Verschlüsselung zwei völlig unterschiedliche Dinge, die unterschiedliche Bedrohungsmodelle ansprechen. Verwechsle die beiden nicht.

— MadHatter unterstützt Monica
quelle

Ich würde argumentieren, dass das Beste aus beiden Welten es Ihnen auch ermöglichen würde, den Unterschied zu sehen, ähnlich wie bei der "Sperre" einer SSL-Seite im Web, sodass Sie wissen, welche E-Mails * blockiert worden wären, wenn Sie TLS erzwungen hätten

— user2813274

@ user2813274 Ich stimme zu, und das tut es auch. Überprüfen Sie Ihre Kopfzeilen. Sie zeigen Ihnen, ob ein bestimmter Schritt der Übertragungskette mit oder ohne Verschlüsselung ausgeführt wurde.

— MadHatter unterstützt Monica

@ MadHatter, es sei denn, diese Header wurden vom Hop vor Ihnen vollständig gefälscht.

— Thrig

8

Es gibt einen Unterschied zwischen opportunistischer und obligatorischer Verschlüsselung. Es ist häufig möglich, dass ein aktives MITM die opportunistische Verschlüsselung unterbricht und die Endpunkte auf keine Verschlüsselung zurückgreifen, die überwacht werden kann. Bei obligatorischer Verschlüsselung würde die Verbindung unterbrochen, was zu einem Denial-of-Service, jedoch nicht zu einer Verletzung der Privatsphäre führen würde.

— cjm

4

@cjm daher mein Standpunkt zu Bedrohungsmodellen. Wenn Sie ernsthaft versuchen, sich gegen MITM-Angriffe zu verteidigen, kann nur die End-to-End-Verschlüsselung Abhilfe schaffen. Sich nur auf die SMTP-Verschlüsselung zu verlassen, ist sinnlos. Ein ausgeklügeltes MITM tarnt sich einfach als Ihr Server und leitet die E-Mails nach dem Lesen an Sie weiter. Sicher, Ihr Server verfügt möglicherweise über ein ordnungsgemäß signiertes Zertifikat (was überraschend selten vorkommt), aber Sie können nicht steuern, ob das an Sie gesendete System dies erfordert , sodass ein MITM-Angriff wie dieser trotz aller Anforderungen an eine verschlüsselte Verbindung erfolgreich ist .

— MadHatter unterstützt Monica

10

Dies ist eine politische Angelegenheit.

Wenn TLS für eingehende und ausgehende E-Mails erzwungen wird, gilt dies im Allgemeinen für eine begrenzte Anzahl von Domänen, auf die sich die Parteien geeinigt haben, um einen Bedarf zu erfüllen (Geschäftspartner haben beispielsweise möglicherweise eine Vereinbarung zur Verschlüsselung aller E-Mails zwischen ihren Unternehmen).

Aktivieren Sie den Durchsetzungsmodus nicht, es sei denn, es liegt eine solche Vereinbarung vor.

— MikeyB
quelle

2

Nein, das ist eine sehr schlechte Idee.

Wie sich herausstellt, implementieren die meisten STARTTLS- Server / -Clients keinen Wiederholungsalgorithmus ohne StartTLS, falls eine TLS-Verbindung nicht ausgehandelt werden kann.

Daher verringert bereits die Werbung für STARTTLS als Option die Wahrscheinlichkeit, E-Mails zu erhalten (und zu senden)!

Wenn Sie nur suchen, werden Sie feststellen, dass viele Benutzer keine E-Mails an Microsoft Outlook-Domänen senden können, die vom Cluster * .protection.outlook.com verwaltet werden:

Von Microsoft abgelehnte Sendmail-Nachrichten bei Verwendung von TLS

Grund: 403 4.7.0 TLS-Handshake fehlgeschlagen

Um die in den beiden obigen Beiträgen behandelten Themen zusammenzufassen:

kann jede E-Mail mit oder ohne STARTTLS an jeden anderen Host als den von Outlook verarbeiteten senden,
kann E-Mails ohne Client-Zertifikat und ohne STARTTLS an Outlook senden,
oder mit einem Client-Zertifikat der Länge Null,
Aber nicht mit einem Zertifikat, das Microsoft nicht gefällt, und bei einem Fehler versuchen die Clients (also Server, die im Client-Modus arbeiten) nicht, die Nachricht ohne STARTTLS erneut zu senden, wenn der Server des Empfängers STARTTLS ankündigt!

Wenn Ihr Host als Server fungiert, kann eine ähnliche Situation außerhalb Ihrer Kontrolle eintreten, wenn Sie STARTTLS aktivieren. Wenn ein Client-Server feststellt, dass Ihr Server im Servermodus STARTTLS anbietet, wird versucht, TLS auszuhandeln, aber wenn die Aushandlung fehlschlägt Warten Sie einfach und wiederholen Sie die Schritte erneut. Scheitern Sie so lange, bis die Nachricht an den Absender zurückgeschickt werden muss.

Und das kommt ziemlich häufig bei verschiedenen Domains im STARTTLS-Land vor!

Leider bin ich, so wie ich früher ein STARTTLS-Unterstützer war, jetzt sehr entrechtet, dass ich durch die risikofreie Werbung für das, was ich für opportunistische Verschlüsselung hielt, in die Irre geführt wurde.

Sie sollten nicht nur kein STARTTLS benötigen, sondern es kann auch ratsam sein, es vollständig zu deaktivieren, wenn Sie die Interoperabilität sicherstellen möchten.

— cnst
quelle

2

Ich muss der Idee zustimmen, opportunistisches TLS zu verwenden. Obwohl ich der Idee noch einiges hinzufügen muss. Einige werden wahrscheinlich von den Vorschlägen gestört sein, da meine Vorschläge hier nicht leichtfertig und ohne angemessene Berücksichtigung gemacht werden. Bevor Sie ein Urteil abgeben, bitte ich Sie, die vollständige Diskussion über den beigefügten Link zu lesen.

Die Verwendung von opportunistischem TLS ist bei weitem die beste Lösung. Der MITM-Winkel als Argument dagegen ist ein roter Hering. Schließlich kann, wie MH in einem Kommentar erwähnte, sogar ein "legitimes" SMTP mit TLS-Verbindung mit MITM versehen werden, und der Endbenutzer ist keineswegs schlauer, da sich die überwiegende Mehrheit der E-Mail-Clients nicht die Mühe macht, Zertifikate in Verbindung mit der überwiegenden Mehrheit zu validieren Bei vielen MTAs, die TLS ausführen, werden selbstsignierte Zertifikate verwendet (zumindest, wenn Sie DNSSEC und TLSA / DANE nicht verwenden). Infolge dieser und möglicherweise weiterer Faktoren ist es sogar umstritten, dass bis Sie und der Rest der Welt hat DANE / TLSA und DNSSEC implementiert. Während der Ausführung von opportunistischem TLS ist es besser, auch anonymen Diffie-Hellman (bei gleichzeitiger Verwendung von PFS) zu aktivieren. Zumindest zum Teil, wenn nicht zum größten Teil, weil der vor dem gelegentlichen Beobachter schützende Datenverkehr weiterhin verschlüsselt wird. Zur weiteren Unterstützung dieser Konfiguration (mit einer viel ausführlicheren Erklärung als meiner) lesen Sie bitte die Kommentare von Viktor Dukhovni in diesem Beitrag in einem Postfix-Forum:http://postfix.1071664.n5.nabble.com/Disabling-Anonymous-Diffie-Hellman-td67965.html

Was den Grund angeht, warum man Viktors Vorschläge über die anderer nehmen könnte, schrieb er den TLS-Code sowie den DNSSEC-, TLSA / DANE-Code für den Postfix-MTA und war derjenige, der die IETF-Entwürfe für beide DNSSEC geschrieben hat und TLSA / DANE. Als solches würde ich sagen, dass seine Worte in dieser Angelegenheit ziemlich viel Gewicht haben, wahrscheinlich mehr als die der meisten.

Hoffe das hilft.

— Mce128
quelle

0

Aus Sicht des E-Mail-Marketings ist die Verwendung von TLS eine bewährte und sichere Methode, wenn Sie wissen, dass sie über die gesamte Lieferkette hinweg implementiert wird. Wenn jedoch Sicherheit Ihre oberste Anforderung ist, ist das Verschlüsseln der E-Mail selbst vor dem Senden die sicherste Option (z. B. mit PGP).

— ERM
quelle