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


Ich betreibe einen E-Mail-Server, der derzeit so eingerichtet ist, dass er beim Senden und Empfangen von E-Mails möglichst TLS verwendet.

Wenn Sie in der Dokumentation darüber nachlesen, gibt es auch die Option, TLS zu erzwingen und keine reine Textübertragung von E-Mails zu akzeptieren. Sie warnen auch, dass einige Mail-Server die Verschlüsselung möglicherweise noch nicht unterstützen und die Durchsetzung der Verschlüsselung diese Server blockieren könnte.

Aber ist das immer noch ein Thema, über das man nachdenken sollte, oder ist es sicher, zu behaupten, dass die Durchsetzung der Verschlüsselung kein Problem mehr ist?

Gibt es vielleicht einen großen Anbieter, der das schon macht oder was halten Sie heute für Best Practice?


36
2017-10-18 12:33


Ursprung




Antworten:


Das praktische Problem ist, dass nicht jeder SMTP-konforme (der RFC ist ziemlich alt) Server TLS mit Ihrem Server sprechen kann, so dass 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 (oder bevor) sie auf Ihrem Server angekommen ist.

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

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

Um Ihre Frage zu beantworten, ist die Verschlüsselung auf der SMTP-Schicht wahrscheinlich sinnlos, erhöht Ihre Chance, E-Mails zu verpassen, und es gibt keine garantierte vorteilhafte Auszahlung.

Edit: Dies bezieht sich auf SMTP-Durchsetzung für die Zwecke der Weiterleitung, nicht Übermittlung von E-Mails. Bei Mail-Übermittlungen sollte die Verschlüsselung erzwungen werden, da die SMTP-Konversation (nicht die eigentliche E-Mail) möglicherweise Authentifizierungsdaten enthält.


34
2017-10-18 12:43



Ich denke nicht, dass dies die beste Antwort ist. Es kommt zu der richtigen Schlussfolgerung, aber aus den falschen Gründen. Es ist "lass das Perfekte der Feind des Guten sein" Argumentation. Ich denke, die bessere Antwort ist, dass Sie, wenn Sie eine Verschlüsselung benötigen, verhindern, dass einige legitime E-Mails durchkommen (weil einige SMTP-Server nicht verschlüsseln können). Wenn es diesen Faktor nicht gäbe, dann erzwinge Verschlüsselung würde von Vorteil sein, auch wenn es aus allen Gründen, die Sie aufführen, nicht perfekt ist - es wäre besser als nichts, auch wenn es nicht perfekt ist. - D.W.
Ich tendiere dazu, der Perfektion durch bloße Hinzufügung von Subperfektionen zu widersprechen; Dennoch habe ich der Antwort eine Änderung hinzugefügt, um die mögliche technische Inkompatibilität von Servern hervorzuheben, die dem RFC entsprechen, aber TLS 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 gesagt haben, wo die Nachricht "war schon" bevor sie mich erreichte. Natürlich hat es keinen Sinn, die Verschlüsselung zu erzwingen, wenn die empfangende Seite sie im Klartext sendet (vielleicht an einen Subserver desselben Unternehmens, aber immer noch über das Internet). - comfreak
Ich habe diese Antwort als die akzeptierte gewählt, da sie klarstellt, 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 denke, diese Antwort ist gut, aber versäumt es zu erwähnen, dass die Verschlüsselung immer noch erwünscht ist, wenn man bedenkt, dass nur in einer begrenzten Anzahl von Fällen jemand die Klartext-Nachricht des Absenders abfängt, um Sie zu täuschen. Wenn du dich vor der CIA / NSA versteckst, ist das sicher nicht hilfreich. Aber was wäre besser, Verschlüsselung zu erzwingen, so dass niemand mit explizitem Interesse, es zu lesen / Abfangen der Absender-Nachricht und versteckt es, bis eine dritte Partei beschließt, versuchen Sie zu schnüffeln oder alle Ihre Nachrichten auf den NSA-Servern gespeichert, so dass eines Tages können sie nicht nur anfangen ... - momo


Nein

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

Ich habe vor nicht allzu langer Zeit erlebt, dass abgehende E-Mails fehlgeschlagen sind, weil das empfangende Ende so konfiguriert war, dass nur SMTP über TLS zugelassen wurde. Es war ein Problem im Absender (es sollte nicht diese Konfiguration verwendet haben), aber zeigt, dass es passiert.

Ich würde eingehende Nachrichten nur von manuell konfigurierten IP-Adressen beschränken. Wenn Ihr Kreditkartenprozessor STARTTLS nicht startet, ziehen Sie es wahrscheinlich vor, die Verbindung abzubrechen (und den lokalen Administrator zu informieren, damit er sie warnen kann!), Anstatt diese (potenziell vertraulichen) Daten unverschlüsselt zu erhalten. Wenn Sie bei ausgehenden Nachrichten zuvor mithilfe von STARTTLS eine Verbindung zu diesem Host hergestellt haben, möchten Sie dies möglicherweise nicht noch einmal unsicher machen und stattdessen als potenziellen Kompromiss behandeln. Sie können auch eine Liste bekannter STARTTLS-Hosts verwenden, wie z. B. gmail oder yahoo.

Da ist https://www.eff.org/startltls-everywhere Projekt, das eine Liste von SMTP-Servern zur Verfügung stellt, für die Sie die Verwendung von startls sicher durchführen können (sollten?).


20
2017-10-18 17:49



Danke für die Antwort und 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 Konversation herabgestuft wird. - comfreak


Es ist völlig sinnlos und wahrscheinlich aktiv schädlich, E-Mails von verschlüsselungsunfähigen Peers abzulehnen.

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

Solange es Server gibt, die keine Verschlüsselung unterstützen, bedeutet das, dass sie nicht mit Ihnen kommunizieren können; das ist schlecht. Sobald jeder es unterstützt, gibt es keinen Unterschied zwischen opportunistischer und verpflichtender Verschlüsselung.

Und wie andere darauf hingewiesen haben, sind Verschlüsselung auf dem Draht und Ende-zu-Ende-Verschlüsselung zwei völlig unterschiedliche Dinge, die unterschiedliche Bedrohungsmodelle ansprechen. Verwechsle die beiden nicht.


11
2017-10-18 15:38



Ich würde argumentieren, dass das Beste aus beiden Welten Ihnen auch erlauben würde, den Unterschied zu sehen, ähnlich dem "Lock" einer SSL-Seite im Internet, damit Sie wissen, welche E-Mails blockiert wären, wenn Sie TLS erzwungen hätten - user2813274
@ user2813274 Ich stimme zu, und es tut es. Überprüfen Sie Ihre Header; Sie zeigen Ihnen, ob ein bestimmter Schritt der Übertragungskette mit oder ohne Verschlüsselung durchgeführt wurde. - MadHatter
@MadHatter, es sei denn, diese Header wurden vollständig durch den Hop vor Ihnen geschmiedet. - thrig
Dort ist ein Unterschied zwischen opportunistischer und obligatorischer Verschlüsselung. Es ist oft möglich, dass ein aktives MITM die opportunistische Verschlüsselung stört, sodass die Endpunkte auf keine Verschlüsselung zurückfallen, die überwacht werden kann. Bei einer obligatorischen Verschlüsselung würde die Verbindung getrennt, was zu einem Denial-of-Service, aber nicht zu einer Verletzung der Privatsphäre führen würde. - cjm
@cjm daher mein Punkt über Bedrohungsmodelle. Wenn Sie ernsthaft versuchen, sich gegen MITM-Angriffe zu wehren, kann nur eine Ende-zu-Ende-Verschlüsselung helfen. Sich allein auf SMTP-Verschlüsselung zu verlassen, ist sinnlos; Ein ausgeklügeltes MITM wird sich einfach als Ihr Server ausgeben und Sie dann nach dem Lesen an Sie weiterleiten. Sicher, Ihr Server verfügt möglicherweise über ein korrekt signiertes Zertifikat (was überraschend selten ist), aber Sie können nicht kontrollieren, ob das System, das zu Ihnen sendet, das erfordert, so wird ein MITM-Angriff wie dieser trotz aller Anforderungen, die Sie an eine verschlüsselte Verbindung stellen, erfolgreich sein. - MadHatter


Dies ist eine politische Angelegenheit.

Wenn TLS für eingehende und ausgehende E-Mails durchgesetzt wird, erfolgt dies in der Regel für eine begrenzte Anzahl von Domänen, die von den Parteien zur Erfüllung eines Bedarfs vereinbart werden (z. B. können Geschäftspartner eine Vereinbarung zur Verschlüsselung aller E-Mails zwischen ihren Unternehmen haben).

Wenn keine solche Vereinbarung besteht, schalten Sie den Erzwingungsmodus nicht ein.


10
2017-10-18 14:29





Nein, es ist eine sehr schlechte Idee.

In der Tat, wie sich herausstellt, am meisten STARTTLS Server / Clients implementieren keine Art von Wiederholungsalgorithmus ohne StartTLS, sollte eine TLS-Verbindung nicht verhandeln.

Daher reduziert sogar die Werbung für STARTTLS als Option Ihre Chancen, E-Mails zu erhalten (und zu versenden)!

Suchen Sie einfach, und Sie werden feststellen, dass viele Personen keine E-Mails an Microsoft Outlook-Domänen senden können, die vom * .protection.outlook.com-Cluster verarbeitet werden:

Sendmail-Nachrichten, die von Microsoft abgelehnt wurden, wenn TLS verwendet wurde

Grund: 403 4.7.0 TLS-Handshake fehlgeschlagen

Um die Probleme zusammenzufassen, die in den beiden obigen Beiträgen dargestellt werden:

  • Sie können beliebige E-Mails an andere Hosts als die von Outlook mit oder ohne STARTTLS senden.
  • kann Mail ohne Client-Zertifikat und ohne STARTTLS an Outlook senden,
  • oder mit einem Zero-Length-Client-Zertifikat,
  • aber nicht mit einem Zertifikat, das Microsoft nicht mag, und bei einem Fehler versuchen die Clients (nun, Server, die im Client-Modus agieren) 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 Ihres Steuerelements auftreten, wenn Sie STARTTLS aktivieren. Wenn ein Clientserver feststellt, dass Ihr Server im Servermodus STARTTLS anbietet, versucht er, TLS auszuhandeln, aber wenn die Aushandlung fehlschlägt warten sie einfach und wiederholen die gleichen Schritte erneut, bis die Nachricht an den Absender zurückgeschickt werden muss!

Und das passiert ziemlich oft mit verschiedenen Domains im STARTTLS Land!

Leider war ich, so sehr ich in der Vergangenheit ein STARTTLS-Unterstützer gewesen bin, jetzt sehr entrechtet, dass ich durch die risikofreie Werbung meiner vermeintlich opportunistischen Verschlüsselung in die Irre geführt wurde.

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


2
2017-10-20 10:20





Ich muss der Idee zustimmen, opportunistische TLS zu verwenden. Obwohl, ich habe etwas, um die Idee zu ergänzen. Einige werden wahrscheinlich durch die Vorschläge gestört werden, da meine Vorschläge hier nicht leichtfertig und ohne angemessene Berücksichtigung gemacht werden, bevor Sie ein Urteil fällen, bitte ich Sie, die vollständige Diskussion aus dem 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 Ablenkungsmanöver. Schließlich, wie MH in einem Kommentar erwähnt, kann sogar ein "legitimes" SMTP mit TLS-Verbindung MITM sein und der Endnutzer ist nicht klüger, weil die große Mehrheit der Mail-Clients nicht daran interessiert ist, Zertifikate zu validieren, die mit der großen Mehrheit gekoppelt sind MTAs, die TLS verwenden, verwenden selbstsignierte Zertifikate (zumindest, wenn Sie nicht DNSSEC und TLSA / DANE verwenden). Aufgrund dieser und möglicherweise anderer Faktoren ist es sogar bis zu Ihnen und dem Rest der Welt strittig hat DANE / TLSA und DNSSEC implementiert, dass es beim Ausführen von opportunistischem TLS besser ist, auch anonymes diffie-hellman (das PFS ebenfalls verwendet) zu aktivieren. Zumindest teilweise, wenn nicht hauptsächlich, weil es den Verkehr vor dem flüchtigen Beobachter schützt. Zur weiteren Unterstützung dieser Konfiguration (mit einer viel ausführlicheren Erklärung als meiner), siehe die Kommentare von Viktor Dukhovni in diesem Post in einem Postfix-Forum: http://postfix.1071664.n5.nabble.com/Disabling-Anonymous-Diffie-Hellman-td67965.html 

Warum sollte man Viktors Vorschläge gegenüber denen anderer annehmen? Nun, er schrieb sowohl den TLS-Code als auch den DNSSEC-, TLSA / DANE-Code für den Postfix-MTA und war derjenige, der die IETF-Entwürfe auf beiden DNSSEC geschrieben hatte und TLSA / DANE. Als solches würde ich sagen, dass seine Worte zu diesem Thema ziemlich viel Gewicht haben, wahrscheinlich mehr als die meisten.

Hoffe das hilft.


2
2017-10-20 19:07





Aus Sicht des E-Mail-Marketings ist die Verwendung von TLS eine gute Methode und sicher, wenn Sie wissen, dass sie über die gesamte Lieferkette implementiert wird. Wenn jedoch die Sicherheit an oberster Stelle steht, dann ist das Verschlüsseln der E-Mail selbst vor dem Senden die sicherste Option (z. B. mit PGP).


0
2017-10-20 01:25