Outgoing DANE ignoriert fehlerhafte DANE Einträge
Hallo zusammen,
bisher hatte ich mich bei meinem privaten E-Mail Server immer auf eingehende E-Mails bei DANE konzentriert. Allerlei Testtools bestätigen auch, dass dies funktioniert.
Nun habe ich mal geschaut, ob es auch ausgehend funktioniert und folgendes bei havedane.net herausbekommen:
Email to non-DANE domain delivered.
Email to DANE domain delivered.
Email to domain with invalid DANE delivered.
Letzteres ist ja ehr bedenklich, da es bedeutet, dass mein Server auch an falsche DANE Einträge die E-Mails zustellt. Nun habe ich alle möglichen Seiten zur DANE Einrichtung abgeklappert und alle sind sich einig, dass DANE folgendermaßen konfiguriert werden soll:
smtp_dns_support_level = dnssec smtp_tls_security_level = dane smtp_host_lookup = dns
Dem ist auch bei mir so. Die Logs zeigen eigentlich nichts verdächtiges, dass einzige was mir aufgefallen ist:
Apr 10 19:58:37 server docker/postfix/smtp[143]: Untrusted TLS connection established to do.havedane.net[2001:1af8:4700:a118:90::7c0]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) Apr 10 19:58:37 server docker/postfix/smtp[144]: Untrusted TLS connection established to dont.havedane.net[2001:1af8:4700:a118:90::7c0]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) Apr 10 19:58:37 server docker/postfix/smtp[145]: Untrusted TLS connection established to wrong.havedane.net[5.79.70.105]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Alle Verbindungen sind untrusted, entsprechend scheint etwas grundlegendes falsch zu sein? Ich habe andere TLS Verbindungen geprüft und diese werden als Trusted angezeigt. Ehrlicherweise weiß ich nicht mehr wie ich nun den Fehler finden kann.
Kann mir jemand hier weiter helfen? Wenn ja, welche Infos werden benötigt?
Lieben Gruß Christian
Am 10.04.2020 um 20:34 schrieb Christian:
Hallo zusammen,
bisher hatte ich mich bei meinem privaten E-Mail Server immer auf eingehende E-Mails bei DANE konzentriert. Allerlei Testtools bestätigen auch, dass dies funktioniert.
Nun habe ich mal geschaut, ob es auch ausgehend funktioniert und folgendes bei havedane.net herausbekommen:
Email to non-DANE domain delivered.
Email to DANE domain delivered. Email to domain with invalid DANE delivered.Letzteres ist ja ehr bedenklich, da es bedeutet, dass mein Server auch an falsche DANE Einträge die E-Mails zustellt. Nun habe ich alle möglichen Seiten zur DANE Einrichtung abgeklappert und alle sind sich einig, dass DANE folgendermaßen konfiguriert werden soll:
smtp_dns_support_level = dnssec smtp_tls_security_level = dane smtp_host_lookup = dns
Dem ist auch bei mir so. Die Logs zeigen eigentlich nichts verdächtiges, dass einzige was mir aufgefallen ist:
Apr 10 19:58:37 server docker/postfix/smtp[143]: Untrusted TLS connection established to do.havedane.net[2001:1af8:4700:a118:90::7c0]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) Apr 10 19:58:37 server docker/postfix/smtp[144]: Untrusted TLS connection established to dont.havedane.net[2001:1af8:4700:a118:90::7c0]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) Apr 10 19:58:37 server docker/postfix/smtp[145]: Untrusted TLS connection established to wrong.havedane.net[5.79.70.105]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Alle Verbindungen sind untrusted, entsprechend scheint etwas grundlegendes falsch zu sein? Ich habe andere TLS Verbindungen geprüft und diese werden als Trusted angezeigt. Ehrlicherweise weiß ich nicht mehr wie ich nun den Fehler finden kann.
Kann mir jemand hier weiter helfen? Wenn ja, welche Infos werden benötigt?
Postfix weiß von sich aus nicht welche Zertifikate du als vertrauenswürdig erachtest. Deshalb musst du mit smtp_tls_CAfile bzw. smtp_tls_CApath angeben, wo sich die vertrauenswürdigen Zertifikate befinden.
Hallo Alex,
danke für die schnelle Antwort. smtp_tls_CAfile ist bei mir auf mein ca-certificate file gesetzt. So wie ich die Doku verstanden habe, sollte es reichen und CApath is eine Performance Alternative?! Dies würde auch erklären, warum andere Verbindungen (z.B. web.de) als "Trusted" eingestuft werden.
Bei DANE hätte ich nun erwartet, dass dies keine, bzw. geringere Rolle spielt. Es soll ja nun die Validität des Zertifikats durch den DNSSEC gesicherten TLSA Eintrag geprüft werden. Und das scheint irgendwie nicht zu funktionieren?
Am Samstag, den 11.04.2020, 14:10 +0200 schrieb Alex JOST:
Am 10.04.2020 um 20:34 schrieb Christian: Hallo zusammen,
bisher hatte ich mich bei meinem privaten E-Mail Server immer auf eingehende E-Mails bei DANE konzentriert. Allerlei Testtools bestätigen auch, dass dies funktioniert.
Nun habe ich mal geschaut, ob es auch ausgehend funktioniert und folgendes bei havedane.net herausbekommen:
Email to non-DANE domain delivered.
Email to DANE domain delivered. Email to domain with invalid DANE delivered.Letzteres ist ja ehr bedenklich, da es bedeutet, dass mein Server auch an falsche DANE Einträge die E-Mails zustellt. Nun habe ich alle möglichen Seiten zur DANE Einrichtung abgeklappert und alle sind sich einig, dass DANE folgendermaßen konfiguriert werden soll:
smtp_dns_support_level = dnssec smtp_tls_security_level = dane smtp_host_lookup = dns
Dem ist auch bei mir so. Die Logs zeigen eigentlich nichts verdächtiges, dass einzige was mir aufgefallen ist:
Apr 10 19:58:37 server docker/postfix/smtp[143]: Untrusted TLS connection established to do.havedane.net[2001:1af8:4700:a118:90::7c0]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) Apr 10 19:58:37 server docker/postfix/smtp[144]: Untrusted TLS connection established to dont.havedane.net[2001:1af8:4700:a118:90::7c0]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) Apr 10 19:58:37 server docker/postfix/smtp[145]: Untrusted TLS connection established to wrong.havedane.net[5.79.70.105]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Alle Verbindungen sind untrusted, entsprechend scheint etwas grundlegendes falsch zu sein? Ich habe andere TLS Verbindungen geprüft und diese werden als Trusted angezeigt. Ehrlicherweise weiß ich nicht mehr wie ich nun den Fehler finden kann.
Kann mir jemand hier weiter helfen? Wenn ja, welche Infos werden benötigt?
Postfix weiß von sich aus nicht welche Zertifikate du als vertrauenswürdig erachtest. Deshalb musst du mit smtp_tls_CAfile bzw. smtp_tls_CApath angeben, wo sich die vertrauenswürdigen Zertifikate befinden.
Am 11.04.2020 um 14:35 schrieb Christian:
Hallo Alex,
danke für die schnelle Antwort. smtp_tls_CAfile ist bei mir auf mein ca-certificate file gesetzt. So wie ich die Doku verstanden habe, sollte es reichen und CApath is eine Performance Alternative?! Dies würde auch erklären, warum andere Verbindungen (z.B. web.de) als "Trusted" eingestuft werden.
Bei DANE hätte ich nun erwartet, dass dies keine, bzw. geringere Rolle spielt. Es soll ja nun die Validität des Zertifikats durch den DNSSEC gesicherten TLSA Eintrag geprüft werden. Und das scheint irgendwie nicht zu funktionieren?
Habe mit DANE leider selbst keine Erfahrungen gesammelt, deshalb kann ich dir nur Hilfe leisten. Aber soweit ich gelesen habe, sollte Postfix bei DANE ein "Verified" anstatt "Trusted" loggen. Und da web.de meines Wissens DANE unterstützt dürfte da wirklich was nicht funktionieren.
Hast Du überprüft, dass dein DNS Resolver DNSSEC unterstützt? Welche Version von Postfix verwendest du?
Meine Postfix Version ist 3.4.9 Den Resolver habe ich mit dig vom Postfix host aus geprüft und er gibt mir ein "ad" Flag zurück. Also müsste DNSSEC grundsätzlich funktionieren.
Wenn ich wenigstens irgendwelche debugging tools finden würde, mit denen ich den Käse nachvollziehen kann. Irgendwie ist das sehr Black Boxig was Postfix da macht.
Am Samstag, den 11.04.2020, 14:59 +0200 schrieb Alex JOST:
Am 11.04.2020 um 14:35 schrieb Christian:
Hallo Alex,
danke für die schnelle Antwort. smtp_tls_CAfile ist bei mir auf mein ca-certificate file gesetzt. So wie ich die Doku verstanden habe, sollte es reichen und CApath is eine Performance Alternative?! Dies würde auch erklären, warum andere Verbindungen (z.B. web.de) als "Trusted" eingestuft werden.
Bei DANE hätte ich nun erwartet, dass dies keine, bzw. geringere Rolle spielt. Es soll ja nun die Validität des Zertifikats durch den DNSSEC gesicherten TLSA Eintrag geprüft werden. Und das scheint irgendwie nicht zu funktionieren?
Habe mit DANE leider selbst keine Erfahrungen gesammelt, deshalb kann ich dir nur Hilfe leisten. Aber soweit ich gelesen habe, sollte Postfix bei DANE ein "Verified" anstatt "Trusted" loggen. Und da web.de meines Wissens DANE unterstützt dürfte da wirklich was nicht funktionieren.
Hast Du überprüft, dass dein DNS Resolver DNSSEC unterstützt? Welche Version von Postfix verwendest du?
Hallo,
On 11.04.2020 14:35, Christian wrote:
Bei DANE hätte ich nun erwartet, dass dies keine, bzw. geringere Rolle spielt.
genau das ist ein Fehler, den viele machen; DANE ist nur ein Add-on, das bereits valididierte zu verifizieren;
Es soll ja nun die Validität des Zertifikats durch den DNSSEC gesicherten TLSA Eintrag geprüft werden. Und das scheint irgendwie nicht zu funktionieren?
hast Du geprüft, ob auch sämtliche notwendigen Zertifikate im ca-certificate file sind? (z.B CentOS meinte beim Update ich denke es war von 6.8 auf 6.9 da so ziemlich alles wegzuwerfen, und es blieb gerade mal ¼ vom urspr. übrig)
On 4/11/20 6:03 PM, Walter H. wrote:
On 11.04.2020 14:35, Christian wrote:
Bei DANE hätte ich nun erwartet, dass dies keine, bzw. geringere Rolle spielt.
genau das ist ein Fehler, den viele machen; DANE ist nur ein Add-on, das bereits valididierte zu verifizieren;
Woraus schliesst Du das? Das Gegenteil ist der Fall. DANE ist explizit angetreten, X.509 komplett zu ersetzen.
Zum ursprünglichen Problem:
http://www.postfix.org/TLS_README.html#client_tls_dane
"Therefore, it is strongly recommended (DANE security guarantee void otherwise) that each MTA run a local DNSSEC-validating recursive resolver [..] listening on the loopback interface, and that the system be configured to use only this local nameserver."
Frage an den Original-Poster: Wird von Deinem postfix wirklich ein lokaler DNS-Resolver auf 127.0.0.1 (oder ::1) benutzt?
Ciao, Michael.
Hallo Michael, da haben sich unsere E-Mails überschnitten. Ich laufe in einem Docker Setup und habe einen eigenen Unbound container laufen. Der ist explizit Postfix zugeordnet. Er ist also nicht auf localhost, sondern a la Docker auf 127.0.0.11. So ist es auch in der resolv.conf eingetragen. Nach der verlinkten Doku nutzt Postfix den System-Resolver. Ich hab es verstanden als: es muss kein localhost sein, wäre nur aus Sicherheitsgründen wünschenswert. Ein Test aus dem Postfix Container sieht dann wie unten angehängt aus. Da es immer schwer ist einen Unbound zu identifizieren, kann ich nur mit dem Cache arbeiten. Erneuter Aufruf der selben Records ergibt eine Query time von 0ms. Das sollte eigentlich nur ein lokaler Unbound schaffen, oder? Kennst Du einen Weg um die Ausführung des DANE Tests sichtbar zu machen?
/ # dig _25._tcp.do.havedane.net TLSA +dnssec ; <<>> DiG 9.14.8 <<>> _25._tcp.do.havedane.net TLSA +dnssec;; global options: +cmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16107;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION:; EDNS: version: 0, flags: do; udp: 4096;; QUESTION SECTION:;_25._tcp.do.havedane.net. IN TLSA ;; ANSWER SECTION:_25._tcp.do.havedane.net. 3600 IN TLSA 2 1 1 27B694B51D1FEF8885372ACFB39193759722B736B0426864DC1C79D0 651FEF73_25._tcp.do.havedane.net. 3600 IN TLSA 3 1 1 553ACF88F9EE18CCAAE635CA540F32CB84ACA77C47916682BCB542D5 1DAA871F_25._tcp.do.havedane.net. 3600 IN RRSIG TLSA 8 5 3600 20200423000000 20200402000000 42609 havedane.net. OH0RwDScHtrf8z2GNJ4KnRi+fjTvcJJUyke0eA94IntRn4qDCzRVz4/Q bfojdMGSsKg0KqBVuCdWzwI2Tv2mPQVGJW3uIcBllwkHAJd0JSLZjLpg jR7r9ew/KrI/G31cuZn3TLbzW44b/VD4mmDjsZ71XyRUrSuZRE0pYAyo 8nE= ;; Query time: 112 msec;; SERVER: 127.0.0.11#53(127.0.0.11);; WHEN: Sat Apr 11 18:47:35 CEST 2020;; MSG SIZE rcvd: 319 Am Samstag, den 11.04.2020, 18:28 +0200 schrieb Michael Ströder:
On 4/11/20 6:03 PM, Walter H. wrote: On 11.04.2020 14:35, Christian wrote:
Bei DANE hätte ich nun erwartet, dass dies keine, bzw. geringere Rollespielt. genau das ist ein Fehler, den viele machen; DANE ist nur ein Add-on, dasbereits valididierte zu verifizieren; Woraus schliesst Du das?Das Gegenteil ist der Fall. DANE ist explizit angetreten, X.509 komplettzu ersetzen. Zum ursprünglichen Problem: http://www.postfix.org/TLS_README.html#client_tls_dane "Therefore, it is strongly recommended (DANE security guarantee voidotherwise) that each MTA run a local DNSSEC-validating recursiveresolver [..] listening on the loopback interface, and that the systembe configured to use only this local nameserver." Frage an den Original-Poster:Wird von Deinem postfix wirklich ein lokaler DNS-Resolver auf 127.0.0.1(oder ::1) benutzt? Ciao, Michael.
Hallo Michael, ich habe nun mal havedane.net auf dane-only gesetzt. Und siehe da, endlich meckert Postfix. Apr 11 19:14:39 server docker/postfix/smtp[904]: warning: TLS policy lookup for do.havedane.net/do.havedane.net: non DNSSEC destinationApr 11 19:14:39 server docker/postfix/smtp[904]: warning: TLS policy lookup for do.havedane.net/do.havedane.net: non DNSSEC destination Also scheint es tatsächlich ein Problem mit dem DNS Resolver zu sein und der Test ob ich DNSSEC Informationen im System bekomme nicht aussagekräftig zu sein.Nicht das ich nun ein Lösung wüsste.... :-D
Am Samstag, den 11.04.2020, 18:58 +0200 schrieb Christian:
Hallo Michael, da haben sich unsere E-Mails überschnitten. Ich laufe in einem Docker Setup und habe einen eigenen Unbound container laufen. Der ist explizit Postfix zugeordnet. Er ist also nicht auf localhost, sondern a la Docker auf 127.0.0.11. So ist es auch in der resolv.conf eingetragen. Nach der verlinkten Doku nutzt Postfix den System-Resolver. Ich hab es verstanden als: es muss kein localhost sein, wäre nur aus Sicherheitsgründen wünschenswert. Ein Test aus dem Postfix Container sieht dann wie unten angehängt aus. Da es immer schwer ist einen Unbound zu identifizieren, kann ich nur mit dem Cache arbeiten. Erneuter Aufruf der selben Records ergibt eine Query time von 0ms. Das sollte eigentlich nur ein lokaler Unbound schaffen, oder? Kennst Du einen Weg um die Ausführung des DANE Tests sichtbar zu machen?
/ # dig _25._tcp.do.havedane.net TLSA +dnssec ; <<>> DiG 9.14.8 <<>> _25._tcp.do.havedane.net TLSA +dnssec;; global options: +cmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16107;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION:; EDNS: version: 0, flags: do; udp: 4096;; QUESTION SECTION:;_25._tcp.do.havedane.net. IN TLSA ;; ANSWER SECTION:_25._tcp.do.havedane.net. 3600 IN TLSA 2 1 1 27B694B51D1FEF8885372ACFB39193759722B736B0426864DC1C79D0 651FEF73_25._tcp.do.havedane.net. 3600 IN TLSA 3 1 1 553ACF88F9EE18CCAAE635CA540F32CB84ACA77C47916682BCB542D5 1DAA871F_25._tcp.do.havedane.net. 3600 IN RRSIG TLSA 8 5 3600 20200423000000 20200402000000 42609 havedane.net. OH0RwDScHtrf8z2GNJ4KnRi+fjTvcJJUyke0eA94IntRn4qDCzRVz4/Q bfojdMGSsKg0KqBVuCdWzwI2Tv2mPQVGJW3uIcBllwkHAJd0JSLZjLpg jR7r9ew/KrI/G31cuZn3TLbzW44b/VD4mmDjsZ71XyRUrSuZRE0pYAyo 8nE= ;; Query time: 112 msec;; SERVER: 127.0.0.11#53(127.0.0.11);; WHEN: Sat Apr 11 18:47:35 CEST 2020;; MSG SIZE rcvd: 319 Am Samstag, den 11.04.2020, 18:28 +0200 schrieb Michael Ströder:
On 4/11/20 6:03 PM, Walter H. wrote: On 11.04.2020 14:35, Christian wrote:
Bei DANE hätte ich nun erwartet, dass dies keine, bzw. geringere Rollespielt. genau das ist ein Fehler, den viele machen; DANE ist nur ein Add- on, dasbereits valididierte zu verifizieren; Woraus schliesst Du das?Das Gegenteil ist der Fall. DANE ist explizit angetreten, X.509 komplettzu ersetzen. Zum ursprünglichen Problem: http://www.postfix.org/TLS_README.html#client_tls_dane "Therefore, it is strongly recommended (DANE security guarantee voidotherwise) that each MTA run a local DNSSEC-validating recursiveresolver [..] listening on the loopback interface, and that the systembe configured to use only this local nameserver." Frage an den Original-Poster:Wird von Deinem postfix wirklich ein lokaler DNS-Resolver auf 127.0.0.1(oder ::1) benutzt? Ciao, Michael.
Hallo zusammen, nach weiteren Tests, habe ich nun die queries im unbound mitgeschrieben. Postfix kontaktiert den richtigen resolver, allerdings scheint kein TLSA Record angefragt zu werden: Apr 12 14:00:56 server docker/unbound[567]: [1586692856] unbound[1:0] info: 192.168.4.5 do.havedane.net. MX IN#015Apr 12 14:00:56 server docker/unbound[567]: [1586692856] unbound[1:0] info: 192.168.4.5 do.havedane.net. A IN#015Apr 12 14:00:56 server docker/unbound[567]: [1586692856] unbound[1:0] info: 192.168.4.5 do.havedane.net. AAAA IN#015 Ich hätte auch eine Abfrage des TLSA Records erwartet (Hier mal mit dig vom Postfix host angefordert)Apr 12 14:01:25 server docker/unbound[567]: [1586692885] unbound[1:0] info: 192.168.4.5 _25._tcp.do.havedane.net. TLSA IN#015 Hat jemand das schon mal gehabt?
Am Samstag, den 11.04.2020, 19:21 +0200 schrieb Christian:
Hallo Michael, ich habe nun mal havedane.net auf dane-only gesetzt. Und siehe da, endlich meckert Postfix. Apr 11 19:14:39 server docker/postfix/smtp[904]: warning: TLS policy lookup for do.havedane.net/do.havedane.net: non DNSSEC destinationApr 11 19:14:39 server docker/postfix/smtp[904]: warning: TLS policy lookup for do.havedane.net/do.havedane.net: non DNSSEC destination Also scheint es tatsächlich ein Problem mit dem DNS Resolver zu sein und der Test ob ich DNSSEC Informationen im System bekomme nicht aussagekräftig zu sein.Nicht das ich nun ein Lösung wüsste.... :-D
Am Samstag, den 11.04.2020, 18:58 +0200 schrieb Christian:
Hallo Michael, da haben sich unsere E-Mails überschnitten. Ich laufe in einem Docker Setup und habe einen eigenen Unbound container laufen. Der ist explizit Postfix zugeordnet. Er ist also nicht auf localhost, sondern a la Docker auf 127.0.0.11. So ist es auch in der resolv.conf eingetragen. Nach der verlinkten Doku nutzt Postfix den System-Resolver. Ich hab es verstanden als: es muss kein localhost sein, wäre nur aus Sicherheitsgründen wünschenswert. Ein Test aus dem Postfix Container sieht dann wie unten angehängt aus. Da es immer schwer ist einen Unbound zu identifizieren, kann ich nur mit dem Cache arbeiten. Erneuter Aufruf der selben Records ergibt eine Query time von 0ms. Das sollte eigentlich nur ein lokaler Unbound schaffen, oder? Kennst Du einen Weg um die Ausführung des DANE Tests sichtbar zu machen?
/ # dig _25._tcp.do.havedane.net TLSA +dnssec ; <<>> DiG 9.14.8 <<>> _25._tcp.do.havedane.net TLSA +dnssec;; global options: +cmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16107;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION:; EDNS: version: 0, flags: do; udp: 4096;; QUESTION SECTION:;_25._tcp.do.havedane.net. IN TLSA ;; ANSWER SECTION:_25._tcp.do.havedane.net. 3600 IN TLSA 2 1 1 27B694B51D1FEF8885372ACFB39193759722B736B0426864DC1C79D0 651FEF73_25._tcp.do.havedane.net. 3600 IN TLSA 3 1 1 553ACF88F9EE18CCAAE635CA540F32CB84ACA77C47916682BCB542D5 1DAA871F_25._tcp.do.havedane.net. 3600 IN RRSIG TLSA 8 5 3600 20200423000000 20200402000000 42609 havedane.net. OH0RwDScHtrf8z2GNJ4KnRi+fjTvcJJUyke0eA94IntRn4qDCzRVz4/Q bfojdMGSsKg0KqBVuCdWzwI2Tv2mPQVGJW3uIcBllwkHAJd0JSLZjLpg jR7r9ew/KrI/G31cuZn3TLbzW44b/VD4mmDjsZ71XyRUrSuZRE0pYAyo 8nE= ;; Query time: 112 msec;; SERVER: 127.0.0.11#53(127.0.0.11);; WHEN: Sat Apr 11 18:47:35 CEST 2020;; MSG SIZE rcvd: 319 Am Samstag, den 11.04.2020, 18:28 +0200 schrieb Michael Ströder:
On 4/11/20 6:03 PM, Walter H. wrote: On 11.04.2020 14:35, Christian wrote:
Bei DANE hätte ich nun erwartet, dass dies keine, bzw. geringere Rollespielt. genau das ist ein Fehler, den viele machen; DANE ist nur ein Add- on, dasbereits valididierte zu verifizieren; Woraus schliesst Du das?Das Gegenteil ist der Fall. DANE ist explizit angetreten, X.509 komplettzu ersetzen. Zum ursprünglichen Problem: http://www.postfix.org/TLS_README.html#client_tls_dane "Therefore, it is strongly recommended (DANE security guarantee voidotherwise) that each MTA run a local DNSSEC-validating recursiveresolver [..] listening on the loopback interface, and that the systembe configured to use only this local nameserver." Frage an den Original-Poster:Wird von Deinem postfix wirklich ein lokaler DNS-Resolver auf 127.0.0.1(oder ::1) benutzt? Ciao, Michael.
Hallo zusammen, um dies abzuschließen: Das Problem lag an der Nutzung von musl-libc in Alpine.Die Implementierung kann die nötigen Flags nicht an den resolver weiterleiten und Postfix funktioniert entsprechend nicht auf musl-libc. Ich war dazu mit Viktor Dukhovni im Austausch, er hat sich auch den Code angeschaut und einige andere fehlende Implementierungen in musl- libc gefunden.Sein abschließendes Verdict: "DO NOT run Postfix over musl-libc." Damit auch nicht auf Alpine. Danke an alle die geholfen haben! Am Sonntag, den 12.04.2020, 14:14 +0200 schrieb Christian:
Hallo zusammen, nach weiteren Tests, habe ich nun die queries im unbound mitgeschrieben. Postfix kontaktiert den richtigen resolver, allerdings scheint kein TLSA Record angefragt zu werden: Apr 12 14:00:56 server docker/unbound[567]: [1586692856] unbound[1:0] info: 192.168.4.5 do.havedane.net. MX IN#015Apr 12 14:00:56 server docker/unbound[567]: [1586692856] unbound[1:0] info: 192.168.4.5 do.havedane.net. A IN#015Apr 12 14:00:56 server docker/unbound[567]: [1586692856] unbound[1:0] info: 192.168.4.5 do.havedane.net. AAAA IN#015 Ich hätte auch eine Abfrage des TLSA Records erwartet (Hier mal mit dig vom Postfix host angefordert)Apr 12 14:01:25 server docker/unbound[567]: [1586692885] unbound[1:0] info: 192.168.4.5 _25._tcp.do.havedane.net. TLSA IN#015 Hat jemand das schon mal gehabt?
Am Samstag, den 11.04.2020, 19:21 +0200 schrieb Christian:
Hallo Michael, ich habe nun mal havedane.net auf dane-only gesetzt. Und siehe da, endlich meckert Postfix. Apr 11 19:14:39 server docker/postfix/smtp[904]: warning: TLS policy lookup for do.havedane.net/do.havedane.net: non DNSSEC destinationApr 11 19:14:39 server docker/postfix/smtp[904]: warning: TLS policy lookup for do.havedane.net/do.havedane.net: non DNSSEC destination Also scheint es tatsächlich ein Problem mit dem DNS Resolver zu sein und der Test ob ich DNSSEC Informationen im System bekomme nicht aussagekräftig zu sein.Nicht das ich nun ein Lösung wüsste.... :-D
Am Samstag, den 11.04.2020, 18:58 +0200 schrieb Christian:
Hallo Michael, da haben sich unsere E-Mails überschnitten. Ich laufe in einem Docker Setup und habe einen eigenen Unbound container laufen. Der ist explizit Postfix zugeordnet. Er ist also nicht auf localhost, sondern a la Docker auf 127.0.0.11. So ist es auch in der resolv.conf eingetragen. Nach der verlinkten Doku nutzt Postfix den System-Resolver. Ich hab es verstanden als: es muss kein localhost sein, wäre nur aus Sicherheitsgründen wünschenswert. Ein Test aus dem Postfix Container sieht dann wie unten angehängt aus. Da es immer schwer ist einen Unbound zu identifizieren, kann ich nur mit dem Cache arbeiten. Erneuter Aufruf der selben Records ergibt eine Query time von 0ms. Das sollte eigentlich nur ein lokaler Unbound schaffen, oder? Kennst Du einen Weg um die Ausführung des DANE Tests sichtbar zu machen?
/ # dig _25._tcp.do.havedane.net TLSA +dnssec ; <<>> DiG 9.14.8 <<>> _25._tcp.do.havedane.net TLSA +dnssec;; global options: +cmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16107;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION:; EDNS: version: 0, flags: do; udp: 4096;; QUESTION SECTION:;_25._tcp.do.havedane.net. IN TLSA ;; ANSWER SECTION:_25._tcp.do.havedane.net. 3600 IN TLSA 2 1 1 27B694B51D1FEF8885372ACFB39193759722B736B0426864DC1C79D0 651FEF73_25._tcp.do.havedane.net. 3600 IN TLSA 3 1 1 553ACF88F9EE18CCAAE635CA540F32CB84ACA77C47916682BCB542D5 1DAA871F_25._tcp.do.havedane.net. 3600 IN RRSIG TLSA 8 5 3600 20200423000000 20200402000000 42609 havedane.net. OH0RwDScHtrf8z2GNJ4KnRi+fjTvcJJUyke0eA94IntRn4qDCzRVz4/Q bfojdMGSsKg0KqBVuCdWzwI2Tv2mPQVGJW3uIcBllwkHAJd0JSLZjLpg jR7r9ew/KrI/G31cuZn3TLbzW44b/VD4mmDjsZ71XyRUrSuZRE0pYAyo 8nE= ;; Query time: 112 msec;; SERVER: 127.0.0.11#53(127.0.0.11);; WHEN: Sat Apr 11 18:47:35 CEST 2020;; MSG SIZE rcvd: 319 Am Samstag, den 11.04.2020, 18:28 +0200 schrieb Michael Ströder:
On 4/11/20 6:03 PM, Walter H. wrote: On 11.04.2020 14:35, Christian wrote:
Bei DANE hätte ich nun erwartet, dass dies keine, bzw. geringere Rollespielt. genau das ist ein Fehler, den viele machen; DANE ist nur ein Add-on, dasbereits valididierte zu verifizieren; Woraus schliesst Du das?Das Gegenteil ist der Fall. DANE ist explizit angetreten, X.509 komplettzu ersetzen. Zum ursprünglichen Problem: http://www.postfix.org/TLS_README.html#client_tls_dane "Therefore, it is strongly recommended (DANE security guarantee voidotherwise) that each MTA run a local DNSSEC-validating recursiveresolver [..] listening on the loopback interface, and that the systembe configured to use only this local nameserver." Frage an den Original-Poster:Wird von Deinem postfix wirklich ein lokaler DNS-Resolver auf 127.0.0.1(oder ::1) benutzt? Ciao, Michael.
On 11.04.2020 18:28, Michael Ströder wrote:
On 4/11/20 6:03 PM, Walter H. wrote:
On 11.04.2020 14:35, Christian wrote:
Bei DANE hätte ich nun erwartet, dass dies keine, bzw. geringere Rolle spielt.
genau das ist ein Fehler, den viele machen; DANE ist nur ein Add-on, das bereits valididierte zu verifizieren;
Woraus schliesst Du das?
am aktuellen Status Quo
ja das mit dem, dass DANE angetreten ist, sogar selbstsignierte Zertifikate verwenden zu können hör ich schon öfters, und was hustet Dir Dein Browser, wenn Du genau auf sowas stößt? (dass die Domain selbst per DNSSEC gesichert und die entsprechenden DANE DNS-Records (TLSA) gesetzt sind, ist hier selbstredend)
On 4/11/20 7:04 PM, Walter H. wrote:
On 11.04.2020 18:28, Michael Ströder wrote:
On 4/11/20 6:03 PM, Walter H. wrote:
On 11.04.2020 14:35, Christian wrote:
Bei DANE hätte ich nun erwartet, dass dies keine, bzw. geringere Rolle spielt.
genau das ist ein Fehler, den viele machen; DANE ist nur ein Add-on, das bereits valididierte zu verifizieren;
Woraus schliesst Du das?
am aktuellen Status Quo
ja das mit dem, dass DANE angetreten ist, sogar selbstsignierte Zertifikate verwenden zu können hör ich schon öfters, und was hustet Dir Dein Browser, wenn Du genau auf sowas stößt?
DANE für HTTPS ist nicht in Browsern implementiert. Also völlig andere Baustelle und Deine Schlussfolgerung ist daher falsch.
Ciao, Michael.
On 11.04.2020 22:46, Michael Ströder wrote:
On 4/11/20 7:04 PM, Walter H. wrote:
On 11.04.2020 18:28, Michael Ströder wrote:
On 4/11/20 6:03 PM, Walter H. wrote:
On 11.04.2020 14:35, Christian wrote:
Bei DANE hätte ich nun erwartet, dass dies keine, bzw. geringere Rolle spielt.
genau das ist ein Fehler, den viele machen; DANE ist nur ein Add-on, das bereits valididierte zu verifizieren;
Woraus schliesst Du das?
am aktuellen Status Quo
ja das mit dem, dass DANE angetreten ist, sogar selbstsignierte Zertifikate verwenden zu können hör ich schon öfters, und was hustet Dir Dein Browser, wenn Du genau auf sowas stößt?
DANE für HTTPS ist nicht in Browsern implementiert.
stimmt.
Also völlig andere Baustelle
falsch
und Deine Schlussfolgerung ist daher falsch.
leider nicht;
nenne mir nur ein Softwarepaket beim User, welches auch damit umgehen kann?
On 12/04/2020 07:49, Walter H. wrote:
On 11.04.2020 22:46, Michael Ströder wrote:
On 4/11/20 7:04 PM, Walter H. wrote:
On 11.04.2020 18:28, Michael Ströder wrote:
On 4/11/20 6:03 PM, Walter H. wrote:
On 11.04.2020 14:35, Christian wrote:
Bei DANE hätte ich nun erwartet, dass dies keine, bzw. geringere Rolle spielt.
genau das ist ein Fehler, den viele machen; DANE ist nur ein Add-on, das bereits valididierte zu verifizieren;
Woraus schliesst Du das?
am aktuellen Status Quo
ja das mit dem, dass DANE angetreten ist, sogar selbstsignierte Zertifikate verwenden zu können hör ich schon öfters, und was hustet Dir Dein Browser, wenn Du genau auf sowas stößt?
DANE für HTTPS ist nicht in Browsern implementiert.
stimmt.
Also völlig andere Baustelle
falsch
Michael hat Recht. DANE ist aktuell nur für MTAs interessant.
und Deine Schlussfolgerung ist daher falsch.
leider nicht;
nenne mir nur ein Softwarepaket beim User, welches auch damit umgehen kann?
Gibt keines, weshalb Michael auch schrieb, dass DANE für Webbrowser nicht implementiert wird. Siehe auch https://www.golem.de/news/dnssec-chain-dane-fuer-browser-ist-praktisch-tot-1...
Gruß, Juri
On 12.04.2020 11:42, Juri Haberland wrote:
On 12/04/2020 07:49, Walter H. wrote:
On 11.04.2020 22:46, Michael Ströder wrote:
On 4/11/20 7:04 PM, Walter H. wrote:
On 11.04.2020 18:28, Michael Ströder wrote:
On 4/11/20 6:03 PM, Walter H. wrote:
On 11.04.2020 14:35, Christian wrote: > Bei DANE hätte ich nun erwartet, dass dies keine, bzw. geringere Rolle > spielt. genau das ist ein Fehler, den viele machen; DANE ist nur ein Add-on, das bereits valididierte zu verifizieren;
Woraus schliesst Du das?
am aktuellen Status Quo
ja das mit dem, dass DANE angetreten ist, sogar selbstsignierte Zertifikate verwenden zu können hör ich schon öfters, und was hustet Dir Dein Browser, wenn Du genau auf sowas stößt?
DANE für HTTPS ist nicht in Browsern implementiert.
stimmt.
Also völlig andere Baustelle
falsch
Michael hat Recht.
eigentlich hat er nicht recht;
DANE ist aktuell nur für MTAs interessant.
die Geschichte mit TLSA mag sein, aber die RFC schreiben haben ja auch S/MIME for DANE zu Wege gebracht: https://tools.ietf.org/html/rfc8162
und wo ist das im Einsatz, der RFC stammt aus 2017(!)
und das macht nur f. Software beim User Sinn ... -> End-to-End Verschlüsselung
leider nicht;
nenne mir nur ein Softwarepaket beim User, welches auch damit umgehen kann?
Gibt keines, weshalb Michael auch schrieb, dass DANE für Webbrowser nicht implementiert wird.
sollte man überdenken; der nutzen von DNSSEC schwindet dahin ...
Siehe auch https://www.golem.de/news/dnssec-chain-dane-fuer-browser-ist-praktisch-tot-1...
ohne DNSSEC auch schwierig ;-)
Hallo Walter, bevor ich in die falsche Richtung losrenne: Das würde nicht mit der DANE RFC übereinstimmen, die sogar als Motivation angibt, die Validätskette über CAs lieber durch DNSSEC abgebildet zu sehen. Entsprechend können komplett Selbstzertifizierte Zertifikate genutzt werden. Ich habe trotzdem die CAs angeschaut:Zum einen nutzt havedane.net ein Selbstzertifiziertes, das erklärt auch das "Untrusted". Zum anderen habe ich einen Test mit web.de (Diese haben DANE eingerichtet) gemacht. Dafür habe ich sicher die CA und ich bekomme auch eine "Trusted" Verbindung, jedoch nicht eine "Verified". Entsprechend scheint die reguläre Verbindung zu funktionieren, jedoch der DANE Test nicht. Ich kann auch nirgendwo in den Logs etwas finden, dass auf einen Fehler hindeuten würde.
Am Samstag, den 11.04.2020, 18:03 +0200 schrieb Walter H.:
Hallo, On 11.04.2020 14:35, Christian wrote:
Bei DANE hätte ich nun erwartet, dass dies keine, bzw. geringere Rolle spielt.genau das ist ein Fehler, den viele machen; DANE ist nur ein Add-on, das bereits valididierte zu verifizieren; Es soll ja nun die Validität des Zertifikats durch den DNSSEC gesicherten TLSA Eintrag geprüft werden. Und das scheint irgendwie nicht zu funktionieren? hast Du geprüft, ob auch sämtliche notwendigen Zertifikate im ca- certificate file sind?(z.B CentOS meinte beim Update ich denke es war von 6.8 auf 6.9 da so ziemlich alles wegzuwerfen, und es blieb gerade mal ¼ vom urspr. übrig)
participants (5)
-
Alex JOST -
Christian -
Juri Haberland -
Michael Ströder -
Walter H.