Archive

Kategorien

DNS DANE Records für brain-force.ch

Heute habe ich im DNS von brain-force.ch sogenannte DANE Records (sehr technisch oder Wikipedia) angelegt (DNS-Based Authentication of Named Entities). Das ist eine zusätzliche Möglichkeit den verschlüsselten Zugriff auf Ressourcen abzusichern.

DANE setzt DNS-RR vom Typ TLSA ein. Diese legen vereinfacht gesagt fest wie der Zugriff auf einen Host erfolgen sollte.

1
_443._tcp.brain-force.ch. IN TLSA 3 0 1 7F287C60F29FDAB5965B4EF41E5FD3C493490F404C37740B46F50C7B5BA718E3

der Client (z.B. Euer Browser) kann diesen Record abfragen, wenn er auf Port 443 (https) und tcp auf brain-force.ch zugreifen will. Dann sagt der Typ TLSA, dass nur SSL Verbindungen „erlaubt“ sind (eigentlich logisch bei https, aber DNS hat keinen Plan von Anwendungsprotokollen). Die 3 legt fest, dass genau dem Zertifikat vertraut werden soll, das der Server liefert und nicht der ganzen Certificate-Chain nach oben. 0 legt fest, dass das vollständige Zertifikat verwendet werden soll und die 1 definiert der Typ des Fingerabdrucks des Zertifikats (1=SHA256 2=SHA512). Danach folgt der Fingerabdruck meines Zertifikats.
Hier gibt es mehr Infos zu den möglichen Optionen

Mit diesen Informationen kann der Client jetzt genau prüfen ob er wirklich mit meinem Server redet. Er baut eine SSL Verbindung auf und bekommt das Zertifikat des Servers. Davon bildet er einen SHA256 Hash und vergleicht den Wert mit dem Wert aus dem DNS RR.
Natürlich bietet SSL an sich bereits einen gewissen Schutz, aber SSL schützt nicht davor auf ein von der CA des Servers korrekt auf den Namen des Servers ausgestelltes Zertifikat hereinzufallen. Eine solche Man-in-the-Middle Attacke kann der Client erst erkennen, wenn er irgendwo abfragen kann wie das Zertifikat eigentlich auszusehen hat. Diesen „Referenzwert“ liefert dann der DNS.

DANE setzt voraus, dass die DNS Zonen selber mittels DNSSec geschützt sind. Obwohl es technisch auch „ohne“ gehen würde, verweigern praktisch alle Clients, welche DANE unterstützen, den TLSA Record, wenn dieser nicht mit DNSSec signiert ist. DANE lässt sich grundsätzlich für jedes Protokoll (Port) einsetzen z.B. auch für SMTP.

Zum Testen von DANE gibt es leider nicht soviele Tools. Für Online Tests kann ich https://www.had-pilot.com/dane/danelaw.html empfehlen. Damit kann man schnell einen DANE Record testen. Für diverse Browser gibt es Plugins von https://www.dnssec-validator.cz/pages/download.html
Zum Erstellen der DANE Records für das DNS File haben ich https://people.redhat.com/pwouters/hash-slinger/ verwendet. Daraus hilft dann das tlsa Kommando. Neben dem Generieren der Records kann das Teil auch Records validieren. tlsa validiert aber keine DNSSec Signaturen, sondern nur den Hash des Zertifikats des Server.

Wer mit dem Gedanken spielt selber auch DANE in seinem DNS zu nutzen, der/die sollte/muss erst die Zone(n) mittels DNSSec signieren. Sonst macht DANE keinen Sinn. Dazu muss die TLD Zone ebenfalls mit DNSSec gesichert sein. Bei .ch ist das bereits der Fall. Viele andere TLDs auch, aber nicht TLDs wie z.B. org, .com oder .info
Bei solchen Domains muss man dann auf sogeannte DLV (DNSSec Lookaside Validation) Lösungen ausweichen. Dafür gibt es die Möglichkeit dlv.isc.org als Anker zu verwenden. Die gesamte Kette von der Root Zone bis hinunter zu eurer Domain muss signiert sein. Da dies z.B. bei .com noch nicht der Fall ist muss man für solche Domains die DLV als vertrauenswürdige Anker nutzen. Diese stellen dann die Verbindung der eigenen Zone zu den Root Zonen her, damit eine ununterbrochene Kette von Signaturen entsteht.

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre lang="" line="" escaped="" cssfile="">

  

  

  

one × 1 =

This site uses Akismet to reduce spam. Learn how your comment data is processed.