Abo
  1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › MTA-STS: Neuer Standard sichert…

Problem mit DANE & Co?

  1. Thema

Neues Thema Ansicht wechseln


  1. Problem mit DANE & Co?

    Autor: OlafLostViking 28.09.18 - 16:12

    Wie schon in dieser Diskussion angesprochen, erscheint mir die Lösung solche Infrastruktur-Daten mittels DNSSEC abgesichert im DNS zu hinterlegen als ziemlich gut. Ob DANE und TLSA jetzt der Weisheit letzter Schluss sind, lasse ich mal außen vor (ich setze sie jedenfalls ohne Probleme und v.a. auch automatisiert ein).

    Mich würde daher ernsthaft mal eine andere Sichtweise der Dinge interessieren. Was seht ihr als so problematisch an der DNS-Variante, dass solche Umwege gegangen werden müssen?

    Natürlich ist die Verbreitung ein Problem! Aber das ist ja kein technischer Grund - auch neue Techniken müssen sich erst verbreiten. Würden die großen z.B. DANE/TLSA mit DNSSEC nutzen, hätten wir doch schon das, was wir wollen. Insofern: Was sind die technischen Stolpersteine, die man sich mit dieser Lösung aus dem Weg räumt?

  2. Re: Problem mit DANE & Co?

    Autor: RipClaw 28.09.18 - 19:02

    OlafLostViking schrieb:
    --------------------------------------------------------------------------------

    > Natürlich ist die Verbreitung ein Problem! Aber das ist ja kein technischer
    > Grund - auch neue Techniken müssen sich erst verbreiten. Würden die großen
    > z.B. DANE/TLSA mit DNSSEC nutzen, hätten wir doch schon das, was wir
    > wollen. Insofern: Was sind die technischen Stolpersteine, die man sich mit
    > dieser Lösung aus dem Weg räumt?

    Ein Problem das ich mit DANE habe ist das ich Let's Encrypt Zertifikate verwende.

    Da habe ich 4 Optionen damit das ganze funktioniert:

    Die erste Option ist das ich alle 3 Monate den Eintrag erneuere bzw. mir eine Möglichkeit überlege das ganze so zu automatisieren das die Einträge automatisch im DNS gesetzt werden.
    Da müsste ich mir einen neuen Anbieter suchen der eine vernünftige API hat.

    Die zweite Option ist das ich immer den gleichen Private Key verwende und auf Betriebsmodus setzen bei dem nicht der Hash vom Zertifikat verwendet wird sondern nur der Hash des Public Keys. Kann man machen aber wird eigentlich von Let's Encrypt nicht empfohlen.

    Die dritte Option ist das ich den Betriebsmodus verwende bei dem nicht mein Zertifikat geprüft wird sondern das Zwischenzertifikat von meinem Aussteller. Hat zwei Nachteile. Zum einen ist dann auch jedes Zertifikat gültig das irgendwer von Let's Encrypt ausstellen lässt und zum anderen kann das auch problematisch werden wenn Let's Encrypt das Zwischenzertifikat ändert und das neue Zertifikat mit einem anderen Zwischenzertifikat ausgestellt wird. Das ist schon einmal passiert und hat mich in den Hintern gebissen.

    Die vierte Option ist das ich ein selbstsigniertes Zertifikat verwende. Würde zwar gehen da die meisten Mailserver da nicht so pingelig sind aber ich würde lieber ein offizielles Zertifikat verwenden.

    Die vorgestellte Technik ist in meinen Augen ein Zwischending zwischen "Ich hab keine Ahnung ob die Gegenseite TLS will oder nicht" und "Ich kann genau verifizieren was für ein Zertifikat auf der anderen Seite zu sein hat". Klar ist das es nicht die endgültige Lösung darstellt aber immerhin ein Ansatz damit was vorwärts geht.



    1 mal bearbeitet, zuletzt am 28.09.18 19:04 durch RipClaw.

  3. Re: Problem mit DANE & Co?

    Autor: OlafLostViking 28.09.18 - 22:24

    RipClaw schrieb:
    --------------------------------------------------------------------------------
    > Ein Problem das ich mit DANE habe ist das ich Let's Encrypt Zertifikate
    > verwende.

    Vielen Dank für Deine Antwort und Meinung!


    > Die erste Option ist das ich alle 3 Monate den Eintrag erneuere bzw. mir
    > eine Möglichkeit überlege das ganze so zu automatisieren das die Einträge
    > automatisch im DNS gesetzt werden.

    Ich möchte an dieser Stelle gerne acmebot empfehlen. Damit kann ich von einem externen Rechner (der nicht andauernd am Netz hängt) meine ganzen Server automatisch mit neuen Zertifikaten versehen und dabei auch gleich den DNS anpassen (ich nutze die DNS-Autorisierung um eben keinen Webserver auf meinen XMPP oder SMTP-Domains betreiben zu müssen... tja...). Dies schließt auch TLSA-Einträge mit ein.


    > Da müsste ich mir einen neuen Anbieter suchen der eine vernünftige API
    > hat.

    Das ist natürlich richtig. Der sollte einfach sauber RFC2136 ermöglichen. Da kann ich leider keine Empfehlungen aussprechen, da ich meine DNS-Server selber betreibe (schon alleine um Manipukationsmöglichkeiten dritter zu verringern - jedenfalls theoretisch ;-) ). Falls dies zur Debatte stünde, möchte ich hier PowerDNS empfehlen. Dieser ermöglicht es mir einen hidden master aufzusetzen, welcher sogar dynamische Zonen mit DNSSEC signiert und dann auf die im Netz erreichbaren slaves^Wworker^Wchildren repliziert. Ansonsten ist DYNDNS mit DNSSEC kein Spaß ;-)


    > Die dritte Option ist das ich den Betriebsmodus verwende bei dem nicht mein
    > Zertifikat geprüft wird sondern das Zwischenzertifikat von meinem
    > Aussteller. Hat zwei Nachteile. Zum einen ist dann auch jedes Zertifikat
    > gültig das irgendwer von Let's Encrypt ausstellen lässt und zum anderen
    > kann das auch problematisch werden wenn Let's Encrypt das
    > Zwischenzertifikat ändert und das neue Zertifikat mit einem anderen
    > Zwischenzertifikat ausgestellt wird. Das ist schon einmal passiert und hat
    > mich in den Hintern gebissen.

    Das stimmt - das würde ich ebenfalls nicht machen. Rein theoretisch ist es ja dank TLSA sogar möglich gänzlich auf eine CA zu verzichten. Praktisch aber natürlich momemtan nicht durchführbar, da nirgendwo diese Angaben im DNS inkl. DNSSEC auch zuverlässig geprüft und dem Nutzer entpsrechend präsentiert werden.

    Schönen Abend.

  4. Re: Problem mit DANE & Co?

    Autor: RipClaw 29.09.18 - 18:31

    OlafLostViking schrieb:
    --------------------------------------------------------------------------------
    > RipClaw schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Ein Problem das ich mit DANE habe ist das ich Let's Encrypt Zertifikate
    > > verwende.
    >
    > Vielen Dank für Deine Antwort und Meinung!
    >
    > > Die erste Option ist das ich alle 3 Monate den Eintrag erneuere bzw. mir
    > > eine Möglichkeit überlege das ganze so zu automatisieren das die
    > Einträge
    > > automatisch im DNS gesetzt werden.
    >
    > Ich möchte an dieser Stelle gerne acmebot empfehlen. Damit kann ich von
    > einem externen Rechner (der nicht andauernd am Netz hängt) meine ganzen
    > Server automatisch mit neuen Zertifikaten versehen und dabei auch gleich
    > den DNS anpassen (ich nutze die DNS-Autorisierung um eben keinen Webserver
    > auf meinen XMPP oder SMTP-Domains betreiben zu müssen... tja...). Dies
    > schließt auch TLSA-Einträge mit ein.

    Danke für den Hinweis. Die Software kannte ich bisher noch nicht. Scheint ja ziemlich viele Funktionen zu unterstützen.

    Bisher habe ich vor allem auf acme.sh gesetzt. Der Client ist in Bash geschrieben und über eine Art Pluginstruktur auch sehr anpassungsfähig.

  5. Re: Problem mit DANE & Co?

    Autor: My1 19.03.19 - 13:11

    ja die beiden DANE-Modi sind schon geil, da man eben entweder mit einem unabhängigen end-cert (DANE-EE) oder eben einer unabhängigen CA (DANE-TA) arbeiten kann, und würde es echt feiern wenn das endlich mal kommt, denn ehrlich gesagt, haben CAs nur probleme vor allem das "alle dürfen alles" konzept ist halt mMn sehr problematisch. Bei DNSSec hingegen kann verisign (verwalter der .com) zwar für .com Signieren, aber nicht bspw für .info weil da Afilias dranhängt und das nicht geht.

    Bei den CAs muss man den ca 150 oder CAs die ein browser drin hat (zugegeben lange nicht mehr gezählt) ALLEN vertrauen, dass die keinen mist bauen.

    eine sache die DNSSec gegener schreien ist doch dass bspw bei .ly domains Libyen als zusätzlicher nötiger vertrauenspunkt kommt, jedoch ist das nicht der Fall, denn Libyen IST bereits ein nötiger vertrauenspunkt, und die können notfalls sachen an der domain anpassen um sich schnell n HTTPS-cert zu besorgen oder so, dazu ist das ein fall von selbst schuld, soll man sich keine .ly holen wenn man keinen bock auf Libyen hat.

    im prinzip der einzige unterschied in der Trust Struktur ist, dass du bei DNSSec dem Root trauen musst, welches als einziges die Befugnis hat, alles zu signieren, während du bei der bisherigen struktur über 150 CAs hast die alles dürfen.

    ich weiß ja nicht wie viel die CAs Preisgeben (bezweifle dass es mehr als nötig ist), jedoch ist beim Root alle 3 monate ein Signing neuer Root-ZSKs angesagt und der KSK, der diese signiert ist SEHR strikt und sicher verwahrt. Im Prinzip gibt es fast keine Möglichkeit, da Müll zu machen, vor allem auch da jede Zeremonie aufgenommen, protokolliert wird etc. UND IM WEB FÜR JEDEN EINSEHBAR IST.

    dazu braucht es mindestens 7 Leute für eine solche Zeremonie um technisch zu gehen, jedoch sind u.a. auch externe Zeugen und so dabei.

    diese 7 Leute sind.
    Zeremonie Admin (die nennen das halt so)
    Interner Zeuge
    (ohne die beiden gibts keinen Zugang in den Käfig mit den Safes)

    Hardwaresafeoperator (der holt den Vorbereiteten Laptop sowie das TPM ausm safe.)

    Crypto-Safe operator (öffnet sen safe mit den Schließfächern für die Smartcards des TPM)

    mindestens 3 aus 7 Crypto Officer (haben Zusammen mit dem admin [jedes fach hat 2 schlösser, die beide geöffnet werden müssen] zugang zu den schließfächern, in denen die Smartcards sind)

    Dazu ist alles in bspw tütchen die nummeriert und versiegelt sind sodass man diese nicht öffnen kann ohne dass man sieht, dass diese eben geöffnet wurden

    es ist sogar spezifiziert dass es bei einer Unehrlichkeitsrate von 5% immer noch nur eine 1 in 1 Mio chance gibt, dass da Müll passiert.

    https://www.cloudflare.com/dns/dnssec/root-signing-ceremony/

    dazu hat man einen deutlichen vorteil gegenüber den CAs. deren Zwischencerts sind meist viele Jahre gültig, da dies nötig ist weil die signaturkette sonst bricht, da man das nicht einfach so schnell tauschen kann, da der Websitebetreiber das Zertifikat in der Hand hält.

    bei DNSSec hingegen hat die Delegation plus Signatur (also den DS und den dazugehörigen RRSIG) immer die jeweilige Registry, ergo die können ihre keys immer tauschen wenn das Interesse besteht, solange man zumindest eine Kurze zeit die alten noch drin lässt als Übergangszeit. wegen caching der DNS Server und so.

    Ein Wechsel eines Zwischencerts kann richtig nervig sein, da wenn nur das ding neu signiert wird muss eben jeder betroffene webserver dieses tauschen, jedoch wenn der Key getauscht wird muss das ganze Zertifikat neugemacht werden, da die signatur bricht. das ist das abtrennen der Signatur keine dumme Idee.

    Asperger inside(tm)



    1 mal bearbeitet, zuletzt am 19.03.19 13:17 durch My1.

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Viega Holding GmbH & Co. KG, Attendorn
  2. Zentrum Bayern Familie und Soziales, Bayreuth
  3. BWI GmbH, Meckenheim, Wilhelmshaven, Frankfurt
  4. Bisping & Bisping GmbH & Co. KG, Lauf an der Pegnitz

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 98,00€ (Bestpreis!)
  2. 469,00€
  3. 92,90€ (Bestpreis!)
  4. bis zu 85% reduziert


Haben wir etwas übersehen?

E-Mail an news@golem.de


Adblock Plus: Adblock-Filterregeln können Code ausführen
Adblock Plus
Adblock-Filterregeln können Code ausführen

Unter bestimmten Voraussetzungen können Filterregeln für Adblocker mit einer neuen Funktion Javascript-Code in Webseiten einfügen. Adblock Plus will reagieren und die entsprechende Funktion wieder entfernen. Ublock Origin ist nicht betroffen.
Von Hanno Böck


    Elektromobilität: Was hat ein Kanu mit Autos zu tun?
    Elektromobilität
    Was hat ein Kanu mit Autos zu tun?

    Veteranen der deutschen Autoindustrie wollen mit Canoo den Fahrzeugbau und den Vertrieb revolutionieren. Zunächst scheitern die großen Köpfe aber an den kleinen Hürden der Startupwelt.
    Ein Bericht von Dirk Kunde

    1. EU Unfall-Fahrtenschreiber in Autos ab 2022 Pflicht
    2. Verkehrssenatorin Fahrverbot für Autos in Berlin gefordert
    3. Ventomobil Mit dem Windrad auf Rekordjagd

    Fitbit Versa Lite im Test: Eher smartes als sportliches Wearable
    Fitbit Versa Lite im Test
    Eher smartes als sportliches Wearable

    Sieht fast aus wie eine Apple Watch, ist aber viel günstiger: Golem.de hat die Versa Lite von Fitbit ausprobiert. Neben den Sport- und Fitnessfunktionen haben uns besonders der Appstore und das Angebot an spaßigen und ernsthaften Anwendungen interessiert.
    Von Peter Steinlechner

    1. Smartwatch Fitbit stellt Versa Lite für Einsteiger vor
    2. Inspire Fitbits neues Wearable gibt es nicht im Handel
    3. Charge 3 Fitbit stellt neuen Fitness-Tracker für 150 Euro vor

    1. Model S und Model X: Tesla verbaut neue Motoren für mehr Reichweite
      Model S und Model X
      Tesla verbaut neue Motoren für mehr Reichweite

      Tesla kann durch modernisierte Motoren für das Model X und das Model S die Reichweite der Elektroautos steigern. Außerdem lassen sich die Akkus schneller laden.

    2. Macbooks: Apple repariert defekte Butterfly-Tastaturen direkt im Laden
      Macbooks
      Apple repariert defekte Butterfly-Tastaturen direkt im Laden

      Macbook-Tastaturen mit Butterfly-Mechanismus verärgern wegen klebender und klemmender Tasten die betroffenen Besitzer. Apple repariert die Geräte künftig in den Apple Stores, um die Wartezeit für Kunden zu reduzieren.

    3. Sportwagen: Porsche Boxster und Cayman sollen elektrifiziert werden
      Sportwagen
      Porsche Boxster und Cayman sollen elektrifiziert werden

      Porsches Sportwagen Boxster und Cayman sollen laut Medienbericht bald rein elektrisch fahren sowie als Hybridfahrzeuge angeboten werden. Die Reichweite der Elektromodelle soll jedoch nicht besonders hoch sein, wenn an der Fahrzeugarchitektur nichts Grundlegendes geändert wird.


    1. 07:41

    2. 07:27

    3. 07:13

    4. 19:00

    5. 17:41

    6. 16:20

    7. 16:05

    8. 16:00