Mailserver SSL S2S Prüfen

[AnonymusChaotic]

Hallo,

ich bin mit dem Einrichten meines Mailservers gestern fertig geworden, hatte allerdings noch ein Tutorial (https://thomas-leister.de/internet/erwe ... bindungen/), das ich heute umgesetzt habe.

Mich würde jetzt interessieren, wie ich die Verbindungen, die der Mailserver mit anderen Servern beim Versand von Mails aufbaut tatsächlich verschlüsselt sind, ...

Schließlich betreibe ich den Server u.a. auch, um zu verhindern, dass Datenspione wie Geheimdienste etc. nicht so schnell zu befriedigen. Wenn die jetzt aber im Klartext übertragene Mails bekommen, war alles für die Katz...

[wanne]

Zuerstmal: SSL und S2S in Mail ist kaputt.
Stellst du smtp_tls_security_level=encrypt Kannst du mit der hälfte der Kontakte nicht mehr Mailen, weil die kein TLS unterstützen.
Stellst du smtp_tls_security_level=may kann ein MITM einfach die Verschlüsslung abstellen.

Entsprechend ist es auch sinnlos smtp_tls_CApath zu setzen. Was btw. nochmal ärger macht, weil auch da die meisten Anbieter schlampen. Reagierst du auf ein nicht validierbares Cert mit senden kannst du die Validierung auch sein lassen. Reagierst du anders kannst du Web oder GMX nicht mehr verschicken.)
Positivlisten kennt postfix meines Wissens nicht.

Abhilfe würde DNSSEC und smtp_tls_security_level=dane schaffen.
Leider gibt es keine größeren Anbieter, die das unterstützen. (Schaden kann's aber nichts, wenn dein postfix aktuell genug ist.) Such mal nach dane. Du willst das auch für den smtpd unterstützen.

Bleibt als einfach auf gut glück zu verschlüsseln. Anfällig gegen MITM aber passiver Mitschnorchler, wie die typischen Geheimdienstaktionen sind dann erstmal außen vor.

Überprüfen kannst du das indem du das setzt:
smtp_tls_loglevel = 1
Und dann mal eine Mail an Googlemail verschickst. (Muss keine Adresse sein, die es wirklich gibt.)
Dann sollte im Syslog sowas auftauchen:

Code: Alles auswählen

Untrusted TLS connection established to gmail-smtp-in.l.google.com[2a00:1450:4013:c01::1b]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)

[AnonymusChaotic]

Die Antwort ein wenig gedauert, habe momentan viel anderes zu tun. Sorry.

Ich möchte hier mal wikipedia zitieren:

Wenn beispielsweise ein Nutzer mit seinem Browser als Client eine gesicherte TLS-Verbindung mit einer Webseite, etwa https://www.example.com/, aufbauen will, möchte er sicherstellen, dass der antwortende Server auch legitimiert ist, die gewünschte Webseite auszuliefern. Dazu prüft der Client zunächst, ob die genannte Domain in dem vom Server angebotenen Zertifikat eingetragen ist.
Anschließend gilt es noch sicherzustellen, dass das Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle (CA) ausgestellt und beglaubigt wurde. Welche CAs als vertrauenswürdig eingestuft werden, entscheidet in den meisten Fällen nicht der Benutzer. Vielmehr greift der Browser automatisch auf eine Liste vertrauenswürdiger CAs zurück, die ihrerseits wiederum als Trust Anchors (Vertrauensursprung) für die Zertifikatshierarchie des Client-Zertifikats dienen.
Zahlreiche schwerwiegende Zwischenfälle mit von Browserherstellern zunächst als vertrauenswürdig eingestuften CAs ließen jedoch Zweifel an der Sicherheit dieses Vorgehens aufkommen. Es gibt u. a. keinerlei Einschränkung, welche CAs Zertifikate für bestimmte Domains beglaubigen dürfen.
An dieser Stelle setzt DANE an: Clients können damit bei DNS-Servern nachfragen, welche Zertifikate sie als vertrauenswürdig einstufen können. Dazu wird ein neuer DNS Resource Record „TLSA“ definiert. Dieser enthält ein Zertifikat im PKIX-Format, dessen Fingerprint oder dessen öffentlichen Schlüssel. Bei diesem sind drei Arten von Antworten möglich:

1. Service Certificate Constraints: Der Client wird aufgefordert, nur ein definiertes Zertifikat zu akzeptieren. Das Zertifikat selbst muss die Prüfung auf Vertrauenswürdigkeit bestehen.
2. Domain-Issued Certificate: Der Client wird aufgefordert, dem im TLSA-Record referenzierten Zertifikat zu vertrauen. Eine Prüfung der Vertrauenshierarchie wird nicht durchgeführt.
3. Trust Anchor Assertion: Der Client wird aufgefordert, für die Validierung des Zertifikates einen definierten Trust Anchor zu benutzen. Das Zertifikat muss seine Vertrauenskette bis auf diesen Trust Anchor zurückführen und die Zertifikatsprüfung bestehen.

Service Certificate Constraint-Einträge dienen also dazu, durch öffentliche Roots ausgegebene Zertifikate zu bestätigen. „Domain-Issued Certificates“ geben dem Domaininhaber die Möglichkeit, für seine TLS-gesicherten Dienste eigene, auch selbst signierte Zertifikate auszugeben, ohne dass eine dem Client bekannte CA einbezogen werden muss. „Trust Anchor Assertion“ dient schließlich dazu, bei selbst betriebenen (privaten) Zertifizierungsstellen den betreffenden Trust Anchor bekanntzumachen.
Allen drei Antworten ist gemeinsam, dass sie die Reichweite von Trust Anchors beschränken. Während in den beiden ersten Fällen ganz bestimmte Vertrauensursprünge ausgeschlossen werden, wird im dritten Fall explizit ein Vertrauensursprung definiert.[2]

Meine Domain ist bei Cloudflare, ich will mir das mit eigenem Nameserver usw. nicht antun.
Cloudflare bietet keine „TLSA“-Einträge an. Heißt: TSLA funktioniert bei mir nicht. Sollte ich damit falsch liegen bitte anmerken.