Postfix (o.Ä.) nur mit TLS

[xsenon]

Hallo zusammen,

postfix und auch die meisten anderen MTAs ermöglichen Transportverschlüsselung per TLS. Wißt ihr, ob bei Postfix auch das bereitgestellte Zertifikat des anderen Mailservers geprüft wird (nicht abgelaufen, beglaubigte CA, etc.)? Und wenn das Zertifikat abgelaufen ist, der Mailtransport abgelehnt wird?

Grüße,
xsenon

 

[Joe User]

Derartige Prüfungen sind bei SMTP/IMAP/POP3 nicht vorgesehen und werden entsprechend auch nicht durchgeführt.

Es macht auch keinen Sinn, da SMTP per Design über mehrere unterschiedliche Hops hinweg laufen kann und dadurch keine End-to-End-Verschlüsselung stattfinden kann.

 

[d4f]

SMTP erlaubt nach RFC-Standard nicht dass man bei öffentlichen Mailserver TLS-exklusiv agiert (RFC 2487 Punkt 5 Abschnitt 6). Allerdings ist laut RFC erlaubt, dass wenn die Verbindung TLS-basiert aufgebaut ist auch die Sicherheit dieser Verbindung gewährleistet wird. ABER, meiner Interpretation und Auffassung nach muss der "Client" MTA mit "Server" MTA eine unverschlüsselte Verbindung versuchen wenn die Verschlüsselte nicht klappt zwecks Kompatibilitätswahrung. Ob man sich dann die Mühe machen soll?

Allein auf Port 587 (SMTP-Submission) ist verpflichtendes TLS möglich, allerdings bezieht sich deine Frage ja auf MTA-MTA Aktivität und nicht auf die (clientseitig gesteuerte) Submission-Aktivität.

 

[Joe User]

Allein auf Port 587 (SMTP-Submission) ist verpflichtendes TLS möglich,

Aber auch dort gibt es by Design keine Zertifikatsprüfung

 

[Lord Gurke]

Derartige Prüfungen sind bei SMTP/IMAP/POP3 nicht vorgesehen und werden entsprechend auch nicht durchgeführt.

Würde ich so nicht unterschreiben. Für SMTP ist mit DANE eine Möglichkeit im Standard vorgesehen, das Zertifikat der Gegenstelle zu verifizieren (RFC 7672). Und es spricht auch erstmal nichts dagegen, bei TLS das Zertifikat zu validieren. Denn wenn ich das nicht tue, kann ich TLS gleich ganz sein lassen, da jeder MITM spielen kann.
RFC 3207 sagt dazu:

After the TLS handshake has been completed, both parties MUST immediately decide whether or not to continue based on the authentication and privacy achieved. The SMTP client and server may decide to move ahead even if the TLS negotiation ended with no authentication and/or no privacy because most SMTP services are performed with no authentication and no privacy, but some SMTP clients or servers may want to continue only if a particular level of authentication and/or privacy was achieved.

Und auch

Both the SMTP client and server must check the result of the TLS negotiation to see whether an acceptable degree of authentication and privacy was achieved. Ignoring this step completely invalidates using TLS for security. The decision about whether acceptable authentication or privacy was achieved is made locally, is implementation-dependent, and is beyond the scope of this document.

Es ist also vollkommen legitim, bei erfolgtem STARTTLS das Zertifikat der Gegenstelle zu validieren und abzubrechen, wenn man mit der Authentizität nicht zufrieden ist. Bei Verwendung von DANE wird im Standard sogar empfohlen, die Existenz eines TLSA-Records entsprechend als "TLS Mandatory" zu werten und ausschließlich verschlüsselte Verbindungen zu verwenden sowie implizit auch die Gegenstelle zu verifizieren.

Es macht auch keinen Sinn, da SMTP per Design über mehrere unterschiedliche Hops hinweg laufen kann und dadurch keine End-to-End-Verschlüsselung stattfinden kann.

TLS war noch nie als Ende-zu-Ende-Verschlüsselung gedacht und deine Begründung finde ich ziemlich dürftig.
Eine HTTPS-Verbindung kann (Reverse-Proxy) ja auch über mehrere Hops hinweg laufen und trotzdem verifizieren die Browser die Zertifikate gegen eine CA-Liste.

Aber auch dort [SMTP-Submission] gibt es by Design keine Zertifikatsprüfung

Siehe oben: Liegt komplett in der Hand des Clients, ob er das will oder nicht. Gilt für SMTPS (465) natürlich auch.




Um auf die Frage des TO zurückzukommen:
Sobald du in Postfix den "smtp_tls_CApath" auf das Verzeichnis konfigurierst, in dem sich die CA-Zertifikate deines Systems befinden, macht Postfix eine Verifikation dagegen. Unter Debian ist das z.B. /etc/ssl/certs/.
Mit "smtp_tls_security_level" kannst du steuern, wie scharf die Prüfung stattfindet. Ich habe das bei mir auf "dane" stehen (du musst dafür einen DNSSEC-Fähigen DNS-Resolver benutzen) und bisher keine Probleme damit.

 

[Joe User]

SMTP kennt, wie auch sein Vorgänger UUCP, keine direkte Verbindung zwischen Client-MTA und Server-MTA, daran ändert auch DANE nichts.
Bei SMTP sind by Design zwischen Client-MTA und Server-MTA beliebig viele Relays vorgesehen und genau deshalb ist es für den Client-MTA nicht möglich das Zertifikat des Server-MTA zu verifizieren.
Der Client-MTA kann maximal das Zertifikat des ersten Relays verifizieren, nicht mehr. Es ist nichtmal sichergestellt, dass ab dem ersten Relay überhaupt noch SSL/TLS genutzt wird.
Und selbst wenn eine Zertifikatsprüfung stattfinden sollte und diese false ergibt, muss die Mail gemäss SMTP zwingend trotzdem zugestellt werden.


Und nochmal: Es geht hier um MTA<->MTA und nicht um MUA<->MTA (weshalb Verweise auf die Ports 587 oder 465 vollkommen sinnfrei sind, da sie nicht genutzt werden)

 

[danton]

Der (wichtige) Unterschied zwischen z.B. einem selbstsignierten und einem CA-signierten Zertifikat ist doch, dass bei letzterem irgendeine Stelle eine mehr oder weniger umfangreiche Überprüfung des Zertifikatsinhabers vorgenommen hat. Und diese Information bringt ja kaum was bei der Kommunikation zwschen zwei Mailservern. Auf die Stärke der Verschlüsselung hat es aber keinen EInfluss, ob es sich um ein selbstsigniertes oder von einer CA signiertes Zertifikat handelt.
Und ganz realistisch betrachtet: Wer hat denn den Ärger, wenn der eigene Mailserver Zertifikate zu scharf überprüft? Doch nur man selber - entweder man versucht den Admin des empfangenden Mailserver zu überzeugen, ein ordentliches Zertifikat zu verwenden (Erfolg evtl. fraglich) oder man verzichtet doch auf die Prüfung.

 

[GwenDragon]

Was soll das überhaupt bringen dem MTA einen Zertifikatscheck auf zu zwingen? Damit MiM nicht mitlesen?
Die Integrität der Mail ist sowieso nicht gewährleistet. Sowas ginge nur mit Signatur/Verschlüsselung per S/MIME bzw. OpenPGP.

 

[Lord Gurke]

Der Client-MTA kann maximal das Zertifikat des ersten Relays verifizieren, nicht mehr. Es ist nichtmal sichergestellt, dass ab dem ersten Relay überhaupt noch SSL/TLS genutzt wird.

1. Genau das ist bei TLS doch immer der Fall und mehr will der TO auch nicht. Er will das Zertifikat der Gegenstelle prüfen, mit der er spricht (zumindest verstehe ich das so). Davon ausgehend, dass er direkt an die im MX-Record gelisteten Server zustellt, erfolgt dadurch eine Prüfung des Zertifikats des vom Empfänger bestimmten Servers.

Und selbst wenn eine Zertifikatsprüfung stattfinden sollte und diese false ergibt, muss die Mail gemäss SMTP zwingend trotzdem zugestellt werden.

2. Wie aus den von mir zitierten RFC hervor geht, darf der Client (also der Absender-MTA) sehr wohl selbst entscheiden ob er bei fehlerhafter Zertifikatprüfung weiter macht oder nicht.

Was soll das überhaupt bringen dem MTA einen Zertifikatscheck auf zu zwingen? Damit MiM nicht mitlesen?
Die Integrität der Mail ist sowieso nicht gewährleistet. Sowas ginge nur mit Signatur/Verschlüsselung per S/MIME bzw. OpenPGP.

Als MITM kann ich mich dann aber als Empfänger-Server ausgeben und so Mails unterdrücken, indem ich sie annehme und schlicht verwerfe. Für mich als Absender sieht das so aus, als sei sie zugestellt und der Empfänger antwortet einfach nicht.
Prüfe ich aber das Zertifikat und rede nur mit verifizierten Gegenstellen, bleibt die Mail in solchen Fällen in der Queue liegen und ich bekomme mit, dass sie nicht zugestellt wird.

 

[Joe User]

Dein nett zitierter RFC 7672 bestätigt meine Aussagen bereits im Intro, dort liest sich der dritte Absatz wie folgt:

With opportunistic DANE TLS, traffic from SMTP clients to domains
   that publish "usable" DANE TLSA records in accordance with this memo
   is authenticated and encrypted.  Traffic from legacy clients or to
   domains that do not publish TLSA records will continue to be sent in
   the same manner as before, via manually configured security,
   (pre-DANE) opportunistic TLS, or just cleartext SMTP.

Der zweite Satz bestätigt nicht nur mich, sondern macht DANE an sich bereits überfällig und erklärt auch warum DANE sich nie durchgesetzt hat und sich auch künftig nicht durchsetzen können wird.

Es hilft auch, sich mal Mailheader genauer anzusehen und den Weg der Mail step-by-step nachzuverfolgen. Spätestens bei grossen Mailprovidern und/oder Firmennetzwerken wird es lustig. Auch Mailinglisten oder Newsgroups (ja, die sind auch mailbasiert und existieren noch) sind hier interessant...
Was passiert bei DANE mit Bounces oder Autoreplys oder anderen mailbasierten Statusnachrichten?
Und spätestens die Statuscodes (welche im Log landen) müssen zwingend übertragen werden, vollkommen egal ob da SSL/TLS mitspielt oder nicht.

SMTP ist halt erheblich komplexer als HTTP, deshalb kann ja auch jeder Depp einen Webserver aufsetzen, aber noch lange keinen Mailserver...
Deswegen gibt es auch so viele Webserver (Software) da draussen, aber nur sehr wenige Mailserver (Software).
Darum finden Projekte wie Sendmail oder Courier kaum/keine neuen Entwickler oder es werden Projekte wie QMüll nicht nachhaltig geforkt, es gibt einfach viel zu wenige Entwickler die diese Komplexitität verstehen (wollen).


Naja, ich habe meine 2c fallen lassen, nun bin ich (hoffentlich) auch wieder raus...

 

[greystone]

Wißt ihr, ob bei Postfix auch das bereitgestellte Zertifikat des anderen Mailservers geprüft wird (nicht abgelaufen, beglaubigte CA, etc.)? Und wenn das Zertifikat abgelaufen ist, der Mailtransport abgelehnt wird?

Wenn ein Zertifikat abgelaufen ist, oder wenn mein Server(postfix) die CA eines fremden Serverzertifikates nicht kennt, dann ist das Zertifikat ungültig und die Verbindung sollte doch per Default abgelehnt werden? Wenn nicht, wo wäre denn da der Sinn von TLS?

 

[d4f]

dann ist das Zertifikat ungültig und die Verbindung sollte doch per Default abgelehnt werden? Wenn nicht, wo wäre denn da der Sinn von TLS?

Das stimmt, bei Postfix wäre das laut Handbuch smtp_tls_security_level = verify. ABER, und das ist die Krux, im öffentlichen Netz ist es laut RFC nicht erlaubt auf TLS zu beharren. Wenn das Zertifikat nicht stimmt, ungültig, abgelaufen oder sonstwas ist, wird also meines Erachtens plaintext Pflicht, da die TLS-Verbindung nicht funktionierte.
Imho ist es also nicht sinnvoll zu strikt zu sein, da man zumindest passives Mitlesen (zb das Anzapfen von Glasfasern) verhindern kann.

Wenn nicht, wo wäre denn da der Sinn von TLS?

Security meets Legacy. Bei Netzwerktechnologien gewinnt halt generell Legacy. Das gleiche Problem kennt man ja von SS7, BGP, FTP, ...
Es wird nicht grundlos mittlerweile alles, sogar DNS, auf HTTPS geknallt; HTTP und seine grundlegende Verschlüsslung sind die einzigen Internetstandards welche extrem schnell und teilweise ohne Rücksicht auf Legacy-Standards weiterentwickelt werden.

Naja, ich habe meine 2c fallen lassen, nun bin ich (hoffentlich) auch wieder raus...

Bargeld wird aktuell nicht gerne gesehen. Nicht dass da etwa Viren oder gar Trojaner dran kleben


EDIT/PS:
Zur Vollständigung der eigentlichen Frage des OP; hier die Konfigurationsoptionen für Postfix http://www.postfix.org/TLS_README.html#client_tls_verify

 

[Joe User]

Bargeld wird aktuell nicht gerne gesehen. Nicht dass da etwa Viren oder gar Trojaner dran kleben

Mein Bargeld lagere ich in 98%igem Aceton, damit haben die meisten Viren, insbesondere SARS-CoV-2, keine Überlebenschance und die Trojaner geben sich als HID aus, solange man mein Bargeld also nicht in den USB/TB-Slot steckt, besteht auch kein Problem

 

[Lord Gurke]

Das stimmt, bei Postfix wäre das laut Handbuch smtp_tls_security_level = verify. ABER, und das ist die Krux, im öffentlichen Netz ist es laut RFC nicht erlaubt auf TLS zu beharren. Wenn das Zertifikat nicht stimmt, ungültig, abgelaufen oder sonstwas ist, wird also meines Erachtens plaintext Pflicht, da die TLS-Verbindung nicht funktionierte.

Der RFC zu STARTTLS bei SMTP, ich zitiere das nochmal, sagt sehr eindeutig, dass genau diese Frage nicht geklärt wird:

The decision about whether acceptable authentication or privacy was achieved is made locally, is implementation-dependent, and is beyond the scope of this document.

Es ist dem SMTP-Client (also dem sendenden MTA) aber erlaubt, nicht weitermachen zu wollen. Keine Klartext-Pflicht.

[...] but some SMTP clients or servers may want to continue only if a particular level of authentication and/or privacy was achieved.

Im RFC wird später das Szenario skizziert, dass du halt eben auf deinen ausgehenden Mails sitzen bleibst, wenn du auf strikter Zertifikatsprüfung bestehst und das Zertifikat der Gegenstelle "schlecht" ist und nicht validiert. Es bleibt aber komplett in deiner lokalen Entscheidung, ob das für den Szenario der richtige Weg ist - denn eine Mail, die in der Queue liegen bleibt, ist da im Zweifel besser aufgehoben als bei einem MITM-Server.

 

[Lord Gurke]

Es hilft auch, sich mal Mailheader genauer anzusehen und den Weg der Mail step-by-step nachzuverfolgen. Spätestens bei grossen Mailprovidern und/oder Firmennetzwerken wird es lustig. Auch Mailinglisten oder Newsgroups (ja, die sind auch mailbasiert und existieren noch) sind hier interessant...

Was nach dem Server passiert, dem ich die Mail gegeben habe, ist mir als MTA egal.
Wir reden hier ja nicht davon, dass wir die E-Mail-Inhalte geheim halten wollen - es geht vielmehr darum dass wir vor dem Ausliefern einer Mail prüfen, ob die Gegenstelle, mit der wir sprechen, sich authentifizieren kann. Und das dient nur dem, was man mit TLS generell erreichen will: MITM verhindern oder wenigstens erkennen.
Siehe hier auch den letzten Absatz.

Was passiert bei DANE mit Bounces oder Autoreplys oder anderen mailbasierten Statusnachrichten?

Die werden, wenn es schlecht läuft, vom generierenden MTA unverschlüsselt verschickt.
Nur weil ich auf meinem MTA für ausgehende Verbindungen das Zertifikat auf Gültigkeit prüfe, heißt das ja noch lange nicht, dass andere Server bei mir nicht unverschlüsselt einliefern können.

Und spätestens die Statuscodes (welche im Log landen) müssen zwingend übertragen werden, vollkommen egal ob da SSL/TLS mitspielt oder nicht.

Die werden, wenn STARTTLS zustande kommt, ebenfalls im STARTTLS-Kanal übertragen.
Wenn es nicht zustande kommt, weil ich das Zertifikat doof finde, breche ich die Verbindung einfach mit RSET ab.


Wie gesagt: Ich habe als Konfigurationsoption für Postfix das Security-Level "dane" empfohlen. Dabei findet die Verifikation nur dann gegen TLSA-Records statt, wenn sie vorhanden sind. Ist aktuell nicht die große Masse und wird vermutlich auch nicht mehr viel mehr, aber es ist abwärtskompatibel zu allem, was da draußen an Mailservern am Netz ist.

 

[Joe User]

Du hast SMTP immer noch nicht verstanden: MITM kann by Design weder erkannt noch verhindert werden, weder mit DANE noch ohne.

MTA01 schickt eine Mail an MTA02, zwischen beiden MTA können by Design beliebig viele weitere MTA diese Mail transportieren, z.B. so:
MTA01->MTA05->MTA08->MTA04->MTA07->MTA03->MTA06->MTA02
Wie soll MTA01 nun das Zertifikat von MTA02 prüfen?
Wie soll MTA01 nun sicherstellen, dass ab MTA05 überhaupt noch TLS gesprochen wird?
Wie soll MTA01 nun sicherstellen, dass ab MTA05 gültige Zertifikate zum Einsatz kommen?
Wie soll MTA01 nun sicherstellen, dass MTA07 kein MITM ist?

SMTP kennt dafür keine Möglichkeiten, daran ändert auch DANE nichts, denn SMTP steht immer über DANE (und STARTTLS).


Deine Argumente treffen unwiedersprochen auf HTTP zu, aber eben nicht auf SMTP.

RFC 821: Simple Mail Transfer Protocol

The objective of Simple Mail Transfer Protocol (SMTP) is to transfer mail reliably and efficiently. SMTP is independent of the particular transmission subsystem and requires only a reliable ordered data stream channel. Obsoletes RFC 788, 780, and 772.

tools.ietf.org

 

[Lord Gurke]

Ich habe das wohl verstanden. Wirklich.
Aber vielleicht möchtest du nochmal über den von mir verwendeten Begriff "Gegenstelle" nachdenken ;-)

Und dein Argument mit den "Beliebig vielen Hops" bei SMTP habe ich oben auch bereits für HTTP zerpflückt. Und dennoch ändert es an meinem Argument und dem von mir verwendeten Begriff "Gegenstelle" nichts.

 

[Joe User]

Was nützt es denn, nur bis zur ersten Gegenstelle/Relay/Hop eine geprüfte SSL/TLS-Verbindung besteht, dahinter aber nichtmehr?
Es ist doch völlig Wumpe ob der MITM vor oder hinter der ersten Gegenstelle sitzt, er ist und bleibt MITM.
Du kannst MITM bei SMTP nicht verhindern, nicht mit geprüften Zertifikaten und auch nicht mit DANE.

Wenn es ginge, wäre es längst Pflicht... Aber dazu müsste man SMTP verbieten und ein neues Protokoll erfinden...

Da wir uns noch ewig im Kreis drehen können, bin ich hier jetzt raus.

 

[d4f]

Ok nach langem Googeln (ca 5Minuten!!!) habe ich die Antwort schwarz auf weiss...
Aus RFC-7435 (Informational purposes)

For encryption to be used more broadly, authentication needs to be optional. The use of encryption defends against pervasive monitoring and other passive attacks. Even unauthenticated, encrypted communication (defined below) is preferable to cleartext.

Some client MTAs employing STARTTLS abandon the TLS handshake when the server MTA fails authentication and immediately start a cleartext connection. Other MTAs have been observed to accept unverified self-signed certificates, but not expired certificates; again falling back to cleartext. These and similar behaviors are NOT consistent with OS principles, since they needlessly fall back to cleartext when encryption is clearly possible.

OS (Opportunistic security) protocol designs should minimize the possibility of failure of negotiated security mechanisms. OS protocols may need to employ
"fallback", to work-around a failure of a security mechanisms that is found in practice to encounter interoperability problems. The choice to implement or enable fallback should only be made in response to significant operational obstacles. [...] Failure to encrypt may be more often a symptom of an
interoperability problem than an active attack. In such a situation, occasional fallback to cleartext may serve the greater good. Even
though some traffic is sent in the clear, the alternative is to ask the administrator or user to manually work-around such
interoperability problems. If the incidence of such problems is non-negligible, the user or administrator might find it more expedient to just disable Opportunistic Security.

IETF ist also klar der Meinung dass man ungültige Zertifikate akzeptieren SOLL ausser man kann das damit einhergehende Sicherheitsrisiko nicht akzeptieren. Es gibt übrigens noch das interessante rfc8689 welches dem Email Absender ermöglicht fest zu legen wie sicher die Inter-MTA Kommunikation ablaufen muss, ob das aber wirklich schon Implementierung findet ist fraglich, es ist nicht mal ein Jahr alt...

Aber dazu müsste man SMTP verbieten und ein neues Protokoll erfinden...

Man sollte M$ überzeugen Activesync für Server-Server Datentransfer weiter zu entwickeln. Wobei, lieber doch nicht...

Und dein Argument mit den "Beliebig vielen Hops" bei SMTP habe ich oben auch bereits für HTTP zerpflückt.

Proxies sind für HTTP, ausser im Firmenumfeld, durchaus selten. RFC2817 definiert trotzdem die Vorgehensweise. Zuerst baut der Client eine TLS-Verbindung mit dem Proxy auf und dann via connect eine ende-zu-ende TLS-Verbindung mit dem eigentlichen HTTP Server. Bei SMTP existiert dieser Ende-zu-Ende Charakter aber gewollt genau wie Echtzeitzustellung nicht, auch wenn beides aktuell gängige Praxis bei Mailsystemen ist.

Mein Bargeld lagere ich in 98%igem Aceton

Ich konnte keine peer-reviewed Paper finden welche die Disinfektionswirkung von Acetone auf Sars-Cov-2 Virii beschreibt.
Die Frage gab es aber in Fachkreisen tatsächlich schon mal https://www.researchgate.net/post/W...nfectant_pure_acetone_or_70_isopropyl_alcohol
Mein Problem mit deinen 2C ist eher dass sie auf den Boden gefallen sind, und dort eine der höchsten Virenbelastungen herrscht (https://wwwnc.cdc.gov/eid/article/26/7/20-0885_article)

 

[xsenon]

Hallo zusammen! Ich merke gerade, ich habe genau das richtige Forum für diese Diskussion ausgesucht. Vielen dank für die vielen wertvollen Beiträge.

@Joe User : Durch die Verkettung von MTAs kann man nicht sicherstellen, dass auf dem nachgelagerten Weg eine MITM-Attacke durchgeführt wird. Aber die Prüfung der Zertifikate stellt zumindest sicher, dass das erste Glied in der Kette der richtige Empfänger ist. Damit kann ich zumindest einen Teil der Kete absichern. Wenn jetzt der Empfänger sein Mailrouting so gestaltet, dass auch nachgelagert alle Hops (sofern überhaupt vorhanden) entsprechend prüfen, wäre ein MITM deutlich unwahrscheinlicher. Letztlich geht es doch darum, die Wahrscheinlichkeit für Angriffe zu reduzieren. Eine absolute Sicherheit ist nie gewährleistet, aber als Inhaber einer Domain kann ich bestimmen wer mein MX ist und damit die Kette ab da beeinflußen.

@d4f : Das RFC-7435 ist "informational". Damit ist es doch nur eine Empfehlung, oder? Aber selbst wenn man gegen diese Standards verstößt, könnte das doch dem Eigentümer des MTA egal sein. Oder?