Outgoing DANE ignoriert fehlerhafte DANE Einträge

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Outgoing DANE ignoriert fehlerhafte DANE Einträge

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?

Lieben Gruß
Christian
Reply | Threaded
Open this post in threaded view
|

Re: Outgoing DANE ignoriert fehlerhafte DANE Einträge

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.

--
Alex JOST
Reply | Threaded
Open this post in threaded view
|

Re: Outgoing DANE ignoriert fehlerhafte DANE Einträge

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?


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.


Reply | Threaded
Open this post in threaded view
|

Re: Outgoing DANE ignoriert fehlerhafte DANE Einträge

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?

--
Alex JOST
Reply | Threaded
Open this post in threaded view
|

Re: Outgoing DANE ignoriert fehlerhafte DANE Einträge

Christian
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?


Reply | Threaded
Open this post in threaded view
|

Re: Outgoing DANE ignoriert fehlerhafte DANE Einträge

Walter H.
In reply to this post by Christian
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)


Reply | Threaded
Open this post in threaded view
|

Re: Outgoing DANE ignoriert fehlerhafte DANE Einträge

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 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.
Reply | Threaded
Open this post in threaded view
|

Re: Outgoing DANE ignoriert fehlerhafte DANE Einträge

Christian
In reply to this post by Walter H.
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)



Reply | Threaded
Open this post in threaded view
|

Re: Outgoing DANE ignoriert fehlerhafte DANE Einträge

Christian
In reply to this post by Michael Ströder
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 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.

Reply | Threaded
Open this post in threaded view
|

Re: Outgoing DANE ignoriert fehlerhafte DANE Einträge

Walter H.
In reply to this post by Michael Ströder
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)



Reply | Threaded
Open this post in threaded view
|

Re: Outgoing DANE ignoriert fehlerhafte DANE Einträge

Christian
In reply to this post by 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 destination
Apr 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 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.

Reply | Threaded
Open this post in threaded view
|

Re: Outgoing DANE ignoriert fehlerhafte DANE Einträge

Michael Ströder
In reply to this post by Walter H.
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.
Reply | Threaded
Open this post in threaded view
|

Re: Outgoing DANE ignoriert fehlerhafte DANE Einträge

Walter H.
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?




smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Outgoing DANE ignoriert fehlerhafte DANE Einträge

Juri Haberland
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-1905-141559.html

Gruß,
  Juri
Reply | Threaded
Open this post in threaded view
|

Re: Outgoing DANE ignoriert fehlerhafte DANE Einträge

Walter H.
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-1905-141559.html
ohne DNSSEC auch schwierig ;-)



smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Outgoing DANE ignoriert fehlerhafte DANE Einträge

Christian
In reply to this post by 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#015
Apr 12 14:00:56 server docker/unbound[567]: [1586692856] unbound[1:0] info: 192.168.4.5 do.havedane.net. A IN#015
Apr 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 destination
Apr 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 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.

Reply | Threaded
Open this post in threaded view
|

Re: Outgoing DANE ignoriert fehlerhafte DANE Einträge

Christian
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#015
Apr 12 14:00:56 server docker/unbound[567]: [1586692856] unbound[1:0] info: 192.168.4.5 do.havedane.net. A IN#015
Apr 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 destination
Apr 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 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.