HI!
Zwei kurze Fragen:
Welche Erfahrungswerte könnt Ihr mir denn TTL von TLSA-Records nennen? Was macht man bei einem zurückgerufenen Zertifikat? Reicht es den TLSA-Record zu klöschen, oder gibt es da ähnlich wie bei DKIM 'nen besonderen Eintrag zum Kennzeichnen, das das Zertifikat/Schlüssel revoced wurde?
ttyl Django
Am 31.01.2015 um 10:24 schrieb django@nausch.org:
Welche Erfahrungswerte könnt Ihr mir denn TTL von TLSA-Records nennen?
also ich hab die fuer TLSA DKIM SPF usw auf 600 gestellt, das ist das Kuerzeste was ich auswaehlen kann, das hat den praktischen Hintergrund dass wenn ich was aendern muss ( warum auch immer z.b auch durch eigene Daemlichkeit ) es moeglichst schnell rund um die Welt sein "sollte". Es ist naemlich nervig wenn man z.b mit einem Reflektor DKIM usw testet der immer auf von DNS Caching noch immer alte Eintraege sieht. Damit gabs bis jetzt keine Probleme.
Best Regards MfG Robert Schetterer
Am 31.01.2015 um 10:44 schrieb Robert Schetterer:
Am 31.01.2015 um 10:24 schrieb django@nausch.org:
Welche Erfahrungswerte könnt Ihr mir denn TTL von TLSA-Records nennen?
also ich hab die fuer TLSA DKIM SPF usw auf 600 gestellt, das ist das Kuerzeste was ich auswaehlen kann, das hat den praktischen Hintergrund dass wenn ich was aendern muss ( warum auch immer z.b auch durch eigene Daemlichkeit ) es moeglichst schnell rund um die Welt sein "sollte". Es ist naemlich nervig wenn man z.b mit einem Reflektor DKIM usw testet
der immer auf von DNS Caching noch immer alte Eintraege sieht.
sollte heissen
dieser immer noch ,auf Grund von DNS Caching , alte Eintraege sieht.
Damit gabs bis jetzt keine Probleme.
Best Regards MfG Robert Schetterer
Wo ist mein Kaffee...*g
Best Regards MfG Robert Schetterer
Am 31.01.2015 um 10:24 schrieb django@nausch.org:
Was macht man bei einem zurückgerufenen Zertifikat? Reicht es den TLSA-Record zu klöschen, oder gibt es da ähnlich wie bei DKIM 'nen besonderen Eintrag zum Kennzeichnen, das das Zertifikat/Schlüssel revoced wurde?
Intersante Frage, weiss ich so gar nicht..
Nun ein Kauf ssl crt kannst du zurueckziehen, und ein Neues einpflegen inklusive neuen TLSA, "eigentlich" duerften "dane" postfix server erst dann wieder an dich ausliefern, wenn sie den neuen TLSA aus dem DNS verifizieren koennen, sollten sie noch die alten Eintrage sehen waere wohl Warteschleife angesagt ( standard 5 Tage ), aber wart mal auf Yoda....*g
Best Regards MfG Robert Schetterer
* django@nausch.org django@nausch.org:
Zwei kurze Fragen:
Welche Erfahrungswerte könnt Ihr mir denn TTL von TLSA-Records nennen?
Es ergibt Sinn, eine vergleichsweise kurze TTL zu verwenden, falls man eben mal gezwungen wäre ein Cert zu widerrufen.
Was macht man bei einem zurückgerufenen Zertifikat? Reicht es den TLSA-Record zu klöschen, oder gibt es da ähnlich wie bei DKIM 'nen besonderen Eintrag zum Kennzeichnen, das das Zertifikat/Schlüssel revoced wurde?
Um ein Zertifikat als gültiges DANE-Cert zu widerrufen, musst Du den betreffenden TLSA-Eintrag entfernen.
Wenn Du von einem auf ein anderes Cert wechselst, dann kannst Du die TLSA RRs beider Certs zur selben Zeit (!) veröffentlichen. Die Specs für DANE besagen, es dürfen zeitgleich mehrere TLSA RRs veröffentlicht sein und es genügt wenn mindestens einer passt.
Das ist auch praktisch, wenn man z.B. ein Cluster aus mehreren Hosts hat, die unterschiedliche Certs verwenden. (Eher ein Sonderfall, weil man meist dasselbe Cert auf allen Hosts im Cluster verwendet)
p@rick
Am 31.01.2015 um 13:03 schrieb Patrick Ben Koetter:
Wenn Du von einem auf ein anderes Cert wechselst, dann kannst Du die TLSA RRs beider Certs zur selben Zeit (!) veröffentlichen. Die Specs für DANE besagen, es dürfen zeitgleich mehrere TLSA RRs veröffentlicht sein und es genügt wenn mindestens einer passt.
Ah, sehr gut !
Best Regards MfG Robert Schetterer
* Patrick Ben Koetter p@sys4.de:
Wenn Du von einem auf ein anderes Cert wechselst, dann kannst Du die TLSA RRs beider Certs zur selben Zeit (!) veröffentlichen. Die Specs für DANE besagen, es dürfen zeitgleich mehrere TLSA RRs veröffentlicht sein und es genügt wenn mindestens einer passt.
Es macht übrigens Sinn, sich den Selektor anzusehen - bei einer "1" geht der ja auf den Public Key. Wenn man den nicht ändert (z.B. bei einem Standard-Renewal mit selbem Key, weil das alte Zertifikat ausläuft), dann wird der sich nicht ändern.
Stefan
HI Joda!
Am 31.01.2015 um 13:03 schrieb Patrick Ben Koetter:
Wenn Du von einem auf ein anderes Cert wechselst, dann kannst Du die TLSA RRs beider Certs zur selben Zeit (!) veröffentlichen. Die Specs für DANE besagen, es dürfen zeitgleich mehrere TLSA RRs veröffentlicht sein und es genügt wenn mindestens einer passt.
O.K. gut zu wissen, ich werd' mir das mal versuchen zu merken. ;)
ttyl Django
HI Joda!
Quoting Patrick Ben Koetter p@sys4.de:
Wenn Du von einem auf ein anderes Cert wechselst, dann kannst Du die TLSA RRs beider Certs zur selben Zeit (!) veröffentlichen.
Na ja, meine Test's bei meinem extern genutzten DSN gingen wohl etwas daneben. O.K. nun bin ich wieder 3-fach grün bei https://tlsa.info
Hatte auch eine Post von Victor selbst bekommen, wegen meines Fehlers. :/
O.K., was ich noch loswerden wollte ist folgendes. Victor schrieb letztes Jahr "Avoid wildcard certs, they may allow MITM attackers to redirect connections to the wrong hosts." Warum wird bei tlsa.info ein TLSA-Record mit einem Rapid-SSL wildcard-certificate "grün" bewertet, ein passendes Zertifikat mit dem CN auf mx01.nausch.org von der CA CAcert.org aber nur als "orange"?
Müsste nicht ein wildcard-certificate ebenso mit einem malus belegt werden? Oder wie siehst Du das?
Servus Django
Zitat von django@nausch.org:
HI Joda!
Quoting Patrick Ben Koetter p@sys4.de:
Wenn Du von einem auf ein anderes Cert wechselst, dann kannst Du die TLSA RRs beider Certs zur selben Zeit (!) veröffentlichen.
Na ja, meine Test's bei meinem extern genutzten DSN gingen wohl etwas daneben. O.K. nun bin ich wieder 3-fach grün bei https://tlsa.info
Hatte auch eine Post von Victor selbst bekommen, wegen meines Fehlers. :/
O.K., was ich noch loswerden wollte ist folgendes. Victor schrieb letztes Jahr "Avoid wildcard certs, they may allow MITM attackers to redirect connections to the wrong hosts." Warum wird bei tlsa.info ein TLSA-Record mit einem Rapid-SSL wildcard-certificate "grün" bewertet, ein passendes Zertifikat mit dem CN auf mx01.nausch.org von der CA CAcert.org aber nur als "orange"?
Müsste nicht ein wildcard-certificate ebenso mit einem malus belegt werden? Oder wie siehst Du das?
Servus Django
Hallo,
Wildcard Zertifikate sind PKI, dh. bei DANE/TLSA mit "Usage FIeld" 3 spielt das überhaupt keine Rolle. Es wird nur kryptographisch geprüft ob der Server das passende Zertifikat zum per DNSSEC gesicherten "Selector" hat. Das Orange für nausch.org kommt eher daher das der zweite MX "20 mx1.tachtler.net" keinen TLSA Record hat, bzw. tachtler.net nicht per DNSSEC gesichert ist.
Gruß
Andreas
HI!
Quoting lst_hoe02@kwsoft.de:
Wildcard Zertifikate sind PKI,
echt? ich dachte immer 'n wildcard-certificate ist 'n Zertifikat, wo 'n *. im CN steht. :)
dh. bei DANE/TLSA mit "Usage FIeld" 3 spielt das überhaupt keine Rolle.
Na ja, dann stell doch mal 'n wildcard-certifikat für einen MX ein und kuck Dir an was passiert. Anschließend stellst Du ein self-sign-certifikat ein und kuckst Dir jeweils die Ergebnisse bei tlsa.info an. Da mäkelt tlsa.info rum, dass es "nur ein non-trused" ist, und genau das meinte ich!
Kannst Dir ja mal die Details zu nausch.org bei tlsa.info ansehen. Der 2te Eintrag ist "rot" hinterlegt, da da dies ein CAcert Zertifikat ist und von sys4.de als untrusted gewertet wird. Das grün markierte ist ein wildcard-Certificat, dessen Root CA sys4.de als vertrauenswürdig einstuft.
Eigentlich würde ich ja erwarten, dass auch ein wildcard als grundsätzlich problematisch gewertet werden würde, wenn ich Victor's "Vorgaben" beachte.
Das Orange für nausch.org kommt eher daher das der zweite MX "20 mx1.tachtler.net" keinen TLSA Record hat, bzw. tachtler.net nicht per DNSSEC gesichert ist.
;) Das ist mir schon klar. Der Kolleg eist noch nicht soweit ... :) GAnz auf der Brennsubbm bin ich ja auch nicht daherschwommn!
Pfiade Django
Zitat von django@nausch.org:
HI!
Quoting lst_hoe02@kwsoft.de:
Wildcard Zertifikate sind PKI,
echt? ich dachte immer 'n wildcard-certificate ist 'n Zertifikat, wo 'n *. im CN steht. :)
dh. bei DANE/TLSA mit "Usage FIeld" 3 spielt das überhaupt keine Rolle.
Na ja, dann stell doch mal 'n wildcard-certifikat für einen MX ein und kuck Dir an was passiert. Anschließend stellst Du ein self-sign-certifikat ein und kuckst Dir jeweils die Ergebnisse bei tlsa.info an. Da mäkelt tlsa.info rum, dass es "nur ein non-trused" ist, und genau das meinte ich!
Die Details hab ich mir tatsächlich nicht angesehen. Aber falls bei "Usage Field" = 3 der TLSA Test wegen selbst signierten Zertifikaten "warnt" sollte man überlegen ob das nicht eher "info" wäre. Könnte allerdinsg auch daran liegen das self-signed oft als root CA Zertifikat interpretiert wird und eine Sonderbehandlung erfährt. Hast du mal getestet was passiert wenn ein selbst erstelltes von einer privaten root-CA signiertes Zertifikat verwendet wird??
Kannst Dir ja mal die Details zu nausch.org bei tlsa.info ansehen. Der 2te Eintrag ist "rot" hinterlegt, da da dies ein CAcert Zertifikat ist und von sys4.de als untrusted gewertet wird. Das grün markierte ist ein wildcard-Certificat, dessen Root CA sys4.de als vertrauenswürdig einstuft.
Eigentlich würde ich ja erwarten, dass auch ein wildcard als grundsätzlich problematisch gewertet werden würde, wenn ich Victor's "Vorgaben" beachte.
Wo wird die Vorgabe gemacht das Wildcard Zertifikate für TLSA kritisch sind? Ich bin immer noch der Meinung das DANE/TLSA genau diese Probleme lösen kann und soll...?
Das Orange für nausch.org kommt eher daher das der zweite MX "20 mx1.tachtler.net" keinen TLSA Record hat, bzw. tachtler.net nicht per DNSSEC gesichert ist.
;) Das ist mir schon klar. Der Kolleg eist noch nicht soweit ... :) GAnz auf der Brennsubbm bin ich ja auch nicht daherschwommn!
Was immer das heißen mag...
Gruß
Andreas
HI Andreas!
Quoting lst_hoe02@kwsoft.de:
Die Details hab ich mir tatsächlich nicht angesehen.
Dachte ich mir schon, hatte mich ja auch "unscharf" ausgedrückt. ;)
Aber falls bei "Usage Field" = 3 der TLSA Test wegen selbst signierten Zertifikaten "warnt" sollte man überlegen ob das nicht eher "info" wäre.
Das wiederum könnte p@rick oder Robert von der sys4 sicherlich beantworten - wir können nur spekulieren. ;)
Könnte allerdinsg auch daran liegen das self-signed oft als root CA Zertifikat interpretiert wird und eine Sonderbehandlung erfährt. Hast du mal getestet was passiert wenn ein selbst erstelltes von einer privaten root-CA signiertes Zertifikat verwendet wird??
Nein, aber ich denke das würde genauso bewertet werden, wie ein von cacert.org signiertes Zertifikat.
Wo wird die Vorgabe gemacht das Wildcard Zertifikate für TLSA kritisch sind?
Wildcard sind für TLSA nicht kritisch, sondern generell, so sagt es zumindestens Viktor Dukhovni hier: http://www.ietf.org/mail-archive/web/dane/current/msg06294.html Am Ende der eMail: " ... Avoid wildcard certs, they may allow MITM attackers to redirect connections to the wrong hosts."
Ich bin immer noch der Meinung das DANE/TLSA genau diese Probleme lösen kann und soll...?
Tja, aber "nur" wenn der Zielserver auch DNSsec/DANE/TLSA nutzt. Wenn nicht, tja, dann ist das alte Problem wieder da, oder?
Servus Django
participants (6)
-
Django [BOfH] -
django＠nausch.org
-
lst_hoe02＠kwsoft.de -
Patrick Ben Koetter -
Robert Schetterer -
Stefan Förster