[Postfixbuch-users] Untrusted TLS connection mit eigener Root-CA unter SLES

Sa Mai 30 06:27:33 CEST 2015

* Matthias Döring <postfixbuch-users at listen.jpberlin.de>:
> Nur so mal so. Ich finde trusted Connections sehr gut. Aber wieso sollte ich mir die Arbeit machen bestimmte Connections zu trusten? Es gibt keine Funktionseinschränkung. Ich sehe noch nicht denn Grund warum ein Mailadmin sich diese Arbeit machen soll?

Wir nutzen certificate pinning und DANE, weil wir nicht nur verschlüsseln
wollen, sondern weil wir auch wissen wollen _mit wem_ wir dabei 'reden'.
STARTTLS ist angreifbar im Verbindungsaufbau gegen "Downgrade Attack" und "Man
in the Middle". Das dürfte der Grund sein, den Du suchst.

Diese beiden Angriffsvektoren unterbindest Du mit certificate pinning, das -
wie Du selber anmerkst - arbeitsaufwändig ist. Eleganter und mit weitaus
geringerem Administrationsaufwand verbunden ist DANE. Hier announced man über
einen DNSSEC-Kanal die Tatsache, dass ein SMTP-Server STARTTLS unterstützt und
wie man den Server identifizieren kann.

Auf Clientseite ist DANE ruck zuck eingerichtet. Du brauchst einen lokalen,
DNSSEC-fähigen Resolver wie z.B. unbound. Nach dem Start prüfst Du, ob er
DNSSEC verifizeren kann:

$ dig +dnssec sys4.de

; <<>> DiG 9.8.1-P1 <<>> +dnssec sys4.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5075
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 3

Wenn Du das 'ad' in der letzten Zeilen oben erhältst, dann hat er sys4.de als
'authenticated domain' erkannt und das bedeutet er konnte ihren DNSSEC-Status
verifizieren. Dann trägst du 127.0.0.1 als ersten resolver in die
/etc/resolv.conf ein und aktualisierst ggf. auch noch die
/var/spool/postfix/etc/resolv.conf.

In Deinem Postfix (version +2.11.1) setzt Du jetzt für den smtp Client:

smtp_dns_support_level = dnssec
smtp_tls_security_level = dane
smtp_tls_loglevel = 1

Zum Testen sendest Du eine Mail an sink at dane.sys4.de. Im Log solltest Du jetzt
anstatt 'trusted' ein 'verified' sehen. Fertig. Aus die Maus. ;)

Auf Serverseite braucht es eine DNSSEC-aktivierte ZONE. Das ist - technisch
betrachet - auch nicht so schwierig, aber es ist mit mehr operativen Risiken
und Hürden verbunden. Bekommt man mit der erforderlichen Erfahrung auch alles
gut hin. Wir machen das seit 1 1/2 Jahren sehr erfolgreich im
Grosskundenbereich.

Im Privatbereich ist DANE im Moment noch ein echtes Liebhaberstück. Es beginnt
schon damit, dass Registrare selten "Wir supporten DNSSEC" an ihre Haustür
schreiben. In .nl ist das anders. Da fördert der Staat DNSSEC indem er Domains
bei der Konnektivierung bezuschusst wenn sie von Anfang an DNSSEC-aktiviert
werden.

> 
> 
> > Am 22.05.2015 um 21:32 schrieb Patrick Ben Koetter <p at sys4.de>:
> > 
> > * Daniel <postfixbuch-users at listen.jpberlin.de>:
> >> Hi Patrick,
> >> 
> >> danke, hat geklappt im Test mit nem Synology Server und posteo als Mailrelay.
> >> 
> >> Konkret in /volume1/@appstore/MailServer/etc/template/main.template
> >> smtp_tls_security_level = may
> >> 
> >> ersetzt durch
> >> smtp_tls_security_level = fingerprint
> >> smtp_tls_fingerprint_cert_match = 3A:89:D8:AD:DC:A7:23:5C:8F:44:E9:DD:2E:85:6A:31:D2:D3:C9:70 
> >> 
> >> Fingerprints kann man sich auch z.B. https://de.ssl-tools.net/mailservers/posteo.de hier entnehmen.
> >> 
> >> Rest wie smtp_tls_fingerprint_digest = sha1 passte schon im Template.
> >> 
> >> Wenn man mit Path arbeitet, kann man den postfix sagen, soll die Certs selbst dort sammeln und speichern, oder müsste ich mir für
> >> sätmliche große Server wenn dann Cert dort einfügen bzw. die fingerprints?
> > 
> > Bei Trust willst Du Postfix nicht selber sammeln lassen. Wie sollte er denn
> > herausfinden, ob er dem was er gefunden hat, trusten soll? Das geht mit DANE
> > TLS, aber nicht mit statischen Cert Stores im Filesystem wie z.b. einer Datei
> > auf die Du mit CApath verweist.
> > 
> > Wenn Du sämtliche Server verifzieren willst, dann musst Du das entweder von
> > Hand machen oder DANE einsetzen. Das geht dann automatisch - vorausgesetzt das
> > Ziel bietet DNSSEC und TLSA RRs an.
> > 
> > Deine Beispieldomain posteo.de unterstützt DANE, wie Du dem DANE Validator
> > entnehmen kannst:
> > https://dane.sys4.de/smtp/posteo.de
> > 
> > p at rick
> > 
> > 
> > 
> >> 
> >> Gruß Daniel
> >> -----Ursprüngliche Nachricht-----
> >> Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Patrick Ben Koetter
> >> Gesendet: Freitag, 22. Mai 2015 18:01
> >> An: postfixbuch-users at listen.jpberlin.de
> >> Betreff: Re: [Postfixbuch-users] Untrusted TLS connection mit eigener Root-CA unter SLES
> >> 
> >> * Daniel <postfixbuch-users at listen.jpberlin.de>:
> >>> Hi Patrick,
> >>> 
> >>> denke der Fehler ist so schon korrekt mit untrustet, und mein Denkfehler war wohl in der schnelle, dass ich mein eigenes
> >> Zertifikat
> >>> angeben muss, und nicht mit dem vom Zielserver (Mailrelay)
> >>> 
> >>> also lasse ich es wie es war. Würde der Mailserver direkt versenden, müsste ich wohl Path angeben, und für sämtliche Servern wie
> >>> Telekom, Google, 1&1, GMX und co entsprechend dann hinterlegen in dem Ordner, oder?
> >> 
> >> Genau.
> >> 
> >> Wenn Du willst, dann kannst Du über smtp_tls_policy_maps das Zertifikat Deines
> >> Relayserver pinnen (fingerprint). Dann gilt er als Verified.
> >> 
> >> p at rick
> >> 
> >> 
> >> 
> >>> 
> >>> Gruß Daniel
> >>> 
> >>> -----Ursprüngliche Nachricht-----
> >>> Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Patrick Ben Koetter
> >>> Gesendet: Freitag, 22. Mai 2015 14:53
> >>> An: postfixbuch-users at listen.jpberlin.de
> >>> Betreff: Re: [Postfixbuch-users] Untrusted TLS connection mit eigener Root-CA unter SLES
> >>> 
> >>> * Daniel <postfixbuch-users at listen.jpberlin.de>:
> >>>> Hallo Patrick,
> >>>> 
> >>>> danke für die Antwort, leider klappt es nicht., weiterhin untrustet zum externen Mailrelay.
> >>>> 
> >>>> Ich habe probiert
> >>>> smtp_tls_CAfile = /usr/syno/etc/ssl/ssl.intercrt/server-ca.crt
> >>> 
> >>> Das server-ca.crt weist wen aus? Ist das die CA mit der das Zertifikat des
> >>> "externen Mailrelay" signiert wurde?
> >>> 
> >>>> und dann noch
> >>>> smtp_tls_cert_file = /var/packages/MailServer/target/etc/ssl/mailserver_ssl.pem
> >>>> smtp_tls_key_file = /usr/syno/etc/ssl/ssl.key/server.key
> >>>> smtp_tls_CAfile = /usr/syno/etc/ssl/ssl.intercrt/server-ca.crt
> >>>> 
> >>>> Weitere Optionen mit smtp_ in der main.cf sind:
> >>>> smtp_tls_security_level = may
> >>>> smtp_tls_loglevel = 1
> >>>> smtp_tls_fingerprint_digest = sha1
> >>>> smtp_tls_note_starttls_offer = yes
> >>>> smtp_host_lookup = dns, native
> >>>> smtp_use_tls = yes
> >>> 
> >>> Mach mal:
> >>> 
> >>> openssl s_client -starttls smtp -CAfile /usr/syno/etc/ssl/ssl.intercrt/server-ca.crt -connect $externesMailrelay:25
> >>> 
> >>> Und sende den output hier her.
> >>> 
> >>> p at rick
> >>> 
> >>> 
> >>> 
> >>> 
> >>>> 
> >>>> Gruß Daniel
> >>>> 
> >>>> -----Ursprüngliche Nachricht-----
> >>>> Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Patrick Ben Koetter
> >>>> Gesendet: Freitag, 22. Mai 2015 13:27
> >>>> An: postfixbuch-users at listen.jpberlin.de
> >>>> Betreff: Re: [Postfixbuch-users] Untrusted TLS connection mit eigener Root-CA unter SLES
> >>>> 
> >>>> * Daniel <postfixbuch-users at listen.jpberlin.de>:
> >>>>> Guten Tag,
> >>>>> 
> >>>>> ich habe ein ähnliches Anliegen.
> >>>>> 
> >>>>> Im Maillog steht beim Versenden von Mails z.B.:
> >>>>> postfix/smtp: Untrusted TLS connection established to mail.x.de[x.x.x.x]:587: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384
> >>>>> (256/256 bits)
> >>>>> 
> >>>>> Darauf hin habe ich habe ich mal main.cf geschaut nach dem in den Mail vom Werner bei den genannten Parameter.
> >>>>> 
> >>>>> Dort habe ich nur gefunden:
> >>>>> smtpd_tls_cert_file = /var/packages/MailServer/target/etc/ssl/mailserver_ssl.pem
> >>>>> smtpd_tls_key_file = /usr/syno/etc/ssl/ssl.key/server.key
> >>>>> 
> >>>>> Dieses bezieht sich dann ja wohl nur für eingehende Verbindung, also müsste ich z.B.
> >>>>> smtp_tls_cert_file = /var/packages/MailServer/target/etc/ssl/mailserver_ssl.pem
> >>>>> smtp_tls_key_file = /usr/syno/etc/ssl/ssl.key/server.key
> >>>>> 
> >>>>> hinzufügen damit auch für ausgehende Verbindung Zertifikat verwendet wird und das untrustet verschwindet?
> >>>> 
> >>>> 
> >>>> Nein. Mit Deiner Änderung könnte der Postfix smtp-Client sich einem Server
> >>>> gegenüber ausweisen, wenn
> >>>> 
> >>>> - das Zertifikat für Client Usage geeignet ist
> >>>> - der Server das Client-Zertifikat anfragt
> >>>> 
> >>>> Du musst smtp_tls_CAfile setzen, damit der Client die Zertifikate anderer
> >>>> SMTP-Server verifizieren kann, z.B.:
> >>>> 
> >>>> smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
> >>>> 
> >>>> p at rick
> >>>> 
> >>>> 
> >>>> 
> >>>>> 
> >>>>> Bin noch dabei mich mit ganzen Materie stärker vertraut zumachen.
> >>>>> 
> >>>>> Gruß Daniel
> >>>>> 
> >>>>> 
> >>>>> -----Ursprüngliche Nachricht-----
> >>>>> Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Werner Flamme
> >>>>> Gesendet: Freitag, 22. Mai 2015 07:53
> >>>>> An: postfixbuch-users at listen.jpberlin.de
> >>>>> Betreff: Re: [Postfixbuch-users] Untrusted TLS connection mit eigener Root-CA unter SLES
> >>>>> 
> >>>>> Roland Schnabel [21.05.2015 20:13]:
> >>>>>> 
> >>>>>>> On 21.05.2015 12:29, Ralf Hansen wrote:
> >>>>>>> 
> >>>>>>> Aber selbst bei Einrichtung eine Eintrages in /etc/hosts
> >>>>>>> 10.100.120.251   interner-server.mein-netz.de
> >>>>>>> 
> >>>>>>> und Nutzung von
> >>>>>>> relayhost = interner-server.mein-netz.de
> >>>>>>> 
> >>>>>>> erhalte ich eine Untrusted TLS connection…
> >>>>>> 
> >>>>>> Postfix ignoriert /etc/hosts per Default:
> >>>>>> smtp_host_lookup = dns
> >>>>> 
> >>>>> Trusted oder nicht hat nichts mit DNS zu tun, sondern damit, ob die
> >>>>> Zertifikatskette anerkannt wird. Das Root-Zertifikat der Kette sollte in
> >>>>> dem Verzeichnis liegen, das mit smtp_tls_CApath definiert wird (für
> >>>>> ausgehende Verbindungen; für eingehende ist es smtpd_tls_CApath).
> >>>>> 
> >>>>> HDH, Werner
> >>> 
> >>> 
> >>> -- 
> >>> _______________________________________________
> >>> Postfixbuch-users -- http://www.postfixbuch.de
> >>> Heinlein Professional Linux Support GmbH
> >>> 
> >>> Postfixbuch-users at listen.jpberlin.de
> >>> https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users
> >> 
> >> -- 
> >> [*] sys4 AG
> >> 
> >> https://sys4.de, +49 (89) 30 90 46 64
> >> Franziskanerstraße 15, 81669 München
> >> 
> >> Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
> >> Vorstand: Patrick Ben Koetter, Marc Schiffbauer
> >> Aufsichtsratsvorsitzender: Florian Kirstein
> >> 
> >> -- 
> >> _______________________________________________
> >> Postfixbuch-users -- http://www.postfixbuch.de
> >> Heinlein Professional Linux Support GmbH
> >> 
> >> Postfixbuch-users at listen.jpberlin.de
> >> https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users
> >> 
> >> 
> >> -- 
> >> _______________________________________________
> >> Postfixbuch-users -- http://www.postfixbuch.de
> >> Heinlein Professional Linux Support GmbH
> >> 
> >> Postfixbuch-users at listen.jpberlin.de
> >> https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users
> > 
> > -- 
> > [*] sys4 AG
> > 
> > https://sys4.de, +49 (89) 30 90 46 64
> > Franziskanerstraße 15, 81669 München
> > 
> > Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
> > Vorstand: Patrick Ben Koetter, Marc Schiffbauer
> > Aufsichtsratsvorsitzender: Florian Kirstein
> > 
> > -- 
> > _______________________________________________
> > Postfixbuch-users -- http://www.postfixbuch.de
> > Heinlein Professional Linux Support GmbH
> > 
> > Postfixbuch-users at listen.jpberlin.de
> > https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users
> -- 
> _______________________________________________
> Postfixbuch-users -- http://www.postfixbuch.de
> Heinlein Professional Linux Support GmbH
> 
> Postfixbuch-users at listen.jpberlin.de
> https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users

-- 
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein