Quantcast

Einmal DANE immer DANE?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Einmal DANE immer DANE?

Jan Behrend
Moin Liste,

wie stelle ich es an, dass Postfix, wenn es denn einmal eine "Verified TLS
connection established" (DANE) erfolgreich durchgeführt hat, diese dann zu
dieser Domain auch zukünfig auch immer wieder verlangt?
Ich kann schon immer die smtp_tls_policy_maps anpassen, wenn ich im Logfile
entsprechende Einträge finde, jedoch ist das niemals vollständig und zeitnah
schon gar nicht.

Ist so etwas überhaupt sinnvoll?  Reicht die bloße Existenz des TLSA-RR Eintrags
aus, damit Postfix DANE erzwingt?  Könnte es ein Angriffs-Szenario geben, dass
das den obigen Wunsch rechtfertigt?  Wenn ja, warum gibt es dann die Option
"dane-only" für smtp_tls_policy(_maps)?

Bsp:
mailbox.org                       dane-only    
.mailbox.org                      dane-only

Vielen Dank schon im Voraus und
Gruß aus Bonn von Jan

--
MAX-PLANCK-INSTITUT fuer Radioastronomie
Jan Behrend - Rechenzentrum
----------------------------------------
Auf dem Huegel 69, D-53121 Bonn                                  
Tel: +49 (228) 525 359, Fax: +49 (228) 525 229
http://www.mpifr-bonn.mpg.de



smime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Einmal DANE immer DANE?

Patrick Ben Koetter-2
* Jan Behrend <[hidden email]>:

> Moin Liste,
>
> wie stelle ich es an, dass Postfix, wenn es denn einmal eine "Verified TLS
> connection established" (DANE) erfolgreich durchgeführt hat, diese dann zu
> dieser Domain auch zukünfig auch immer wieder verlangt?
> Ich kann schon immer die smtp_tls_policy_maps anpassen, wenn ich im Logfile
> entsprechende Einträge finde, jedoch ist das niemals vollständig und zeitnah
> schon gar nicht.
>
> Ist so etwas überhaupt sinnvoll?  Reicht die bloße Existenz des TLSA-RR Eintrags
> aus, damit Postfix DANE erzwingt?  Könnte es ein Angriffs-Szenario geben, dass
> das den obigen Wunsch rechtfertigt?  Wenn ja, warum gibt es dann die Option
> "dane-only" für smtp_tls_policy(_maps)?


Boah, ey. Das sind ja gleich vier Dinge auf einmal... ;)

DANE dreht die Policy-Richtung um. Wo du vormals auf Deiner Seite eine Policy
(z.B. fingerprint) hattest, da holt Postfix sich die Anweisungen bei DANE von
der Zieldomain.

Diese Umkehr hat den Vorteil, dass Postfix Änderungen der Policy jetzt
vollautomatisch erfährt. Ändert sich der TLSA RR wegen Austausch des Certs,
dann geht das vollautomatisch von statten. Beschliesst die Gegenseite kein
DANE mehr anzubieten, dann geht auch das vollautomatisch. Wenn sie dann noch
STARTTLS im Service anbietet, wird Postfix das opportunistisch nutzen - mit
allen Angriffsvektoren (Session Downgrade, Man in the Middle etc.), die DANE
so schön verhindert.

Die bloße Existenz eines TLSA RRs genügt und Postfix erwartet zwingend, dass
die Gegenseite STARTTLS anbietet. Ein denkbares Angriffs-Szenario ist, die
Zieldomain zu kontrollieren und den TLSA zu entfernen. Dann weiß Postfix nicht
mehr ob der MX der Zieldomain STARTTLS zwingend anbietet und wird sich auf ein
"mal sehen ob und wenn nicht dann halt keine Verschlüsselung" einlassen.

Dem kannst Du, wie in Deinem Beispiel hier, entgegentreten indem Du als Policy
DANE erzwingst:

> Bsp:
> mailbox.org                       dane-only    
> .mailbox.org                      dane-only

Ist das sinnvoll? Ich denke, das ist eine Frage, die nur Du selber durch eine
Risikobetrachtung Deiner Plattform, Eurer Kommunikationsgewohnheiten und Eurer
Kommunikationsinhalte beantworten kannst. Was wäre wenn? Was würde das
bedeuten? Was wäre der Schaden?

HTH

p@rick


--
[*] sys4 AG
 
https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG,80333 München
 
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
 
Loading...