DNSSEC und DANE

DNS Workshop

Created: 2019-08-29 Thu 10:23

Agenda

  • DNSSEC Anwendungen
    • x509 Zertifikate absichern
    • SSH-Verbindungen absichern
    • PGP-Schlüssel verteilen (E-Mail Verschlüsselung)
    • S/MIME-Zertifikate verteilen (E-Mail Verschlüsselung)
    • IPSec-Parameter verteilen
    • DDoS Angriffe abschwächen

DNSSEC als neue Internet PKI

  • die traditionelle Internet PKI über Zertifizierungsstellen (CA) ist problematisch:
    • allen CAs muss ultimativ vertraut werden
    • es gibt zu viele CAs (2.000 +)
    • Sicherheit des Modells nur so gut wie Sicherheit des schwächsten Glied

DNSSEC als neue Internet PKI

DNSSEC als neue Internet PKI

  • der Besitzer einer DNSSEC signierten Domain erstellt oder bekommt ein x509-Zertifikat
  • der Besitzer der Domain publiziert den Hash des Zertifikats im DNS (TLSA-Record, DNSSEC gesichert) und konfiguriert das Zertifikat auf dem Dienst (Server)

DNSSEC als neue Internet PKI

  • Beispiel eines TLSA-Records (für einen der GMX.DE Mail-Server):
     % dig _25._tcp.mx01.emig.gmx.net tlsa +multi

     ; <<>> DiG 9.10.4-P4-RedHat-9.10.4-2.P4.fc25 <<>> _25._tcp.mx01.emig.gmx.net tlsa +multi
     ;; global options: +cmd
     ;; Got answer:
     ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29351
     ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

     ;; OPT PSEUDOSECTION:
     ; EDNS: version: 0, flags:; udp: 4096
     ;; QUESTION SECTION:
     ;_25._tcp.mx01.emig.gmx.net. IN TLSA

     ;; ANSWER SECTION:
     _25._tcp.mx01.emig.gmx.net. 293 IN TLSA 3 1 1 (
                                     9BDE51EA74128A327A6A4F3A4F21CBA855475DCF88BC
                                     1532A2B45B35E16E6D61 )

     ;; WHEN: Mon Dec 19 07:41:58 CET 2016
     ;; MSG SIZE  rcvd: 102

DNSSEC als neue Internet PKI

  • ein Dienst-Client:
  • prüft ob das vom Server präsentierte x509-Zertifikat mit den Informationen (Hash) im TLSA-Record übereinstimmt
  • der Dienst-Domainname wird über den Namen des TLSA-Records abgeglichen. Der Common-Name (CN) oder die Domain-Namen im Zertifikat müssen nicht mit dem Servernamen des Dienstes übereinstimmen
  • das von Server gesendete Zertifikat ist solange gültig, wie es einen passenden TLSA-Record im DNS gibt. Das Ablaufdatum (Expire-Time) des x509-Zertifikats wird nicht ausgewertet
  • die Zertifikats-Kette des x509-Zertifikats muss nicht ausgewertet werden, die Vertrauensstellung zum Zertifikate wird über DNSSEC und den TLSA-Record erstellt

DANE-TLSA

  • DANE-TLSA ist spezifiziert für
    • SMTP (E-Mail)
    • HTTPS (Web) (Client-Browser Support fehlt)
    • IRC
    • XMPP/Jabber
    • generische Dienste mit SRV-Records (RFC 7673)

DANE-SMTP

  • Technische Richtlinie BSI TR-03108, "Sicherer E-Mail-Transport" -Anforderungen an E-Mail-Diensteanbieter für einen sicheren Transport von E-Mails
    • "Zertifikate … mittelfristig automatisiert durch … DANE/TLSA … über DNSSEC … gesicherte Verbindung vom … EMDA" abrufen
    • DANE wird "Verpflichtend bei Rezertifizierung"
    • Posteo.de als erster Mail-Provider im Dezember 2016 zertifiziert

DANE-SMTP

  • weitere DANE-SMTP Anbieter:
    • Unitymedia
    • Mailbox.org
    • Web.de/Gmx.de
    • mail.de
    • bund.de
    • viele Universitäten (z.B. Bayrisches Hochschulnetz)

DANE-SMTP

  • DANE-SMTP Nutzer
   gmx.at                   lrz.de                  ouderportaal.nl
   travelbirdbelgie.be      mail.de                 overheid.nl
   travelbirdbelgique.be    posteo.de               pathe.nl
   nic.br                   ruhr-uni-bochum.de      uvt.nl
   registro.br              tum.de                  xs4all.nl
   gmx.ch                   uni-erlangen.de         domeneshop.no
   open.ch                  unitybox.de             handelsbanken.no
   switch.ch                unitymedia.de           webcruitermail.no
   anubisnetworks.com       web.de                  aegee.org
   gmx.com                  egmontpublishing.dk     debian.org
   isavedialogue.com        netic.dk                freebsd.org
   mail.com                 tilburguniversity.edu   gentoo.org
   solvinity.com            octopuce.fr             ietf.org
   t-2.com                  comcast.net             isc.org
   trashmail.com            dd24.net                netbsd.org
   xfinity.com              dns-oarc.net            openssl.org
   xfinityhomesecurity.com  gmx.net                 samba.org
   xfinitymobile.com        hr-manager.net          torproject.org
   nic.cz                   mpssec.net              asf.com.pt
   bayern.de                t-2.net                 handelsbanken.se
   bund.de                  xs4all.net              t-2.si
   fau.de                   bhosted.nl              mail.co.uk
   freenet.de               boozyshop.nl            govtrack.us
   gmx.de                   hierinloggen.nl

DANE-SMTP

  • DANE-SMTP Domains nach Ländern
Land DANE Domains
Deutschland 1277
USA 770
Niederlande 450
Frankreich 321
Grossbritannien 102
Tschechische Republik 102
  • einigen dieser Domains werden von Millionen von E-Mail Kunden benutzt. Die Anzahl der Domains gibt daher nur bedingt Auskunft über die Verbreitung von DANE gemessen an Mail-Konten.

DANE-SMTP

DANE Probleme

SSH Verbindungen absichern

Administratoren können die Hashes von SSH-Server-Schlüsseln im DNS ablegen

    # ssh-keygen -r sshhost.example.com -f /etc/ssh/sshd_host_ecdsa_key.pub
    sshhost.example.com IN SSHFP 3 1 48bbfcca77cb1e724dbd47cbc383c949060824c3
    sshhost.example.com IN SSHFP 3 2 52622614c83c2bcc3782c0219e477d184ba6ff5db32ecb324072d260888ae85f

Beispiel:

$ dig SSHFP echo.example.com +short
1 1 EC24FF1229F69EE4A51881D4D0152A3F95696560
1 2 8E1289CFAC1BD019B5A29B41F6F9A08912C29B1F811283CC33D30F15 1734D32E

SSH Verbindungen absichern

  • SSH-Clients prüfen den öffentlichen Schlüssel des Servers mittels des SSHFS-Records im DNS
  • die DNS-Antwort muss mit DNSSEC abgesichert werden (AD-Flag)
  • es wird auf dem SSH-Client keine known_hosts Datei mit den Hashes der Server-Schlüssel angelegt

SSH Verbindungen per SSHFP absichern

  • Vorteile:
    • Sicherheit schon bei der ersten Kommunikation mit dem SSH-Server (kein TOFU - "Trust on First Use")
    • der Administrator kann die SSH-Schlüssel ersetzen (Key-Roll, Algorithmus-Roll), ohne das SSH-Clients manuell Fingerprints prüfen oder austauschen müssen

S/MIME Zertifikate

  • Benutzer/Organisationen können x509 Zertifikate für die E-Mail Verschlüsselung per S/MIME im DNS hinterlegen
  • Vorteile:
    • manuelle Verteilung der x509-Zertifikate entfällt
    • Mail-Gateways können Mail ohne Handlung des Benutzers absichern
  • Implementationen:
    • Postfix/Sendmail-Milter "smilla"
    • Thunderbird Plugin "smaug"

OPENPGPKEY

  • mit dem OPENPGPKEY DNS-Record können die öffentlichen PGP-Schlüssel von Benutzern im DNS abgelegt werden
gpg2 --auto-key-locate dane --locate-keys "user@example.com"
  • heute in Benutzung bei Posteo.de, Mailbox.org …

IPSECKEY

  • mittels des DNS Record-Typ "IPSECKEY" können IPSEC-Kommunikationsparameter im DNS gespeichert werden
  • IPSEC-Gateway System können automatisiert gesicherte VPN-Tunnel zu Gegenstellen aufbauen, ohne das manuell Konfigurationsparameter oder Zertifikate ausgetauscht werden müssen
  • Implementationen: LibReSWAN (Red Hat Linux), StrongSWAN (Ubuntu, Debian, Suse …)

DDoS Angriffe abschwächen

  • eine Änderung in der Bedeutung des NXDOMAIN Rückgabewertes aus einer DNSSEC signierten Zone erlaubt es einem DNS-Resolver, selbstständig NXDOMAIN Antworten für die Zone zu generieren
  • NSEC oder NSEC3 definieren die Domain-Namen, welche in der Zone existieren

DDoS Angriffe abschwächen

  • der DNS-Resolver darf für die TTL der NSEC/NSEC3-Records bei Anfragen an Namen in den Zwischenräumen eigenständig NXDOMAIN-Antworten herausgeben, ohne diese Information vom authoritativen Server bekommen zu haben
  • dies entlastet die authoritativen DNS-Server bei "Random-Subdomain"-Angriffen (auch "Chinese-Water-Torture"-Angriffe)
  • Vorraussetzung:
    • angegriffende Zone ist DNSSEC signiert
    • (moderne) DNSSEC validierende Resolver

DDoS Angriffe abschwächen

Fragen?