DNSSEC und DANE

Transport Layer Security (TLS) ist das Standardverfahren zum Verschlüsseln des Datentransports. Über eine PKI können digitale Zertifikate ausgestellt, verteilt und geprüft werden. Die Authentizität der verwendeten Zertifikate ist jedoch nicht immer gewährleistet.


Derzeit sind über 200 verschiedene CAs verfügbar, jede dieser CA kann Zertifikate für jeden beliebigen Hostnamen ausstellen. Wenn eine dieser CAs nachlässig bei der Systemsicherheit oder der Prüfung des Antragsstellers ist, kann sich ein Angreifer ein "gültiges" Zertifikat für einen Host erstellen lassen.


Hier kommt DANE ins Spiel! DANE definiert einen TLSA-Record, der den Hash des öffentlichen Schlüssels einer Domain oder eines Dienstes enthält.


Vorteile von DANE

  • DANE ermöglicht die Validierung des öffentlichen Schlüssels und erhöht die Vertrauenswürdigkeit der TLS-Verbindung
  • DANE verhindert bei Verwendung von STARTTLS Downgrade-Angriffe
  • DANE macht CAA-Records im DNS überflüssig
  • DANE verringert die Angriffsfläche, da man sich vorinstallierte Root-Zertifikate der CAs spart
  • DANE kann außerdem von Domaininhabern dazu genutzt werden, eigene Zertifikate auszustellen, ohne auf eine bestehende Zertifizierungsstelle (CA) zurückgreifen zu müssen. DANE bietet somit eine vom Zertifikatsvertrauen unabhängige Überprüfung der Authentizität des Servers.

Um Manipulationen des TLSA-RR durch beispielsweise einem MitM-Angriff zu vermeiden, wird DNSSEC vorausgesetzt. Mittels Signaturen garantiert DNSSEC, dass DNS-Informationen zu einer Domain authentisch sind und während der Übertragung nicht gefälscht wurden.


DNSSEC

Das Domain Name System Security Extension (DNSSEC) erweitert das Domain Name System hinsichtlich der Transportsicherheit und dient als Grundlage weiterer Sicherheitsanwendungen. Konzipiert wurde DNSSEC zum einen, um eine Datenintegrität bezüglich der im DNS übertragenen Resource Records zu gewährleisten. Zum anderen soll eine Authentizität der Datenherkunft der übertragenen Resource Records sichergestellt sein.


DNS Hierarchie
Fig.1: DNS-Hierarchie in Form einer Baumstruktur

DNSSEC Chain of Trust

Figure 2 zeigt die Vertrauenskette für die autoritative Zone dnssec-uni-potsdam.de. Der autoritative Nameserver für dnssec-uni-potsdam.de enhält als letzte Instanz der Vertrauenskette in der Zonendatei einen Verweis auf mail.dnssec-uni-potsdam.de. Der öffentliche KSK-Teil liegt als Hash in dem DS-RR der übergeordneten Zone DE-NIC für die .de-Zone. Dieser signiert anschließend mit seinem KSK den DS-Eintrag. Nur der ZSK signiert die Zoneneinträge und stellt deren Integrität und Authentizität sicher. Der Schlüssel der übergeordneten Zonen (.de und root) signiert jeweils nur den DS-Eintrag im KSK. Bei einer Änderung des KSK ist eine out-of-band-Kommunikation mit der übergeordenten Zone nötig.

DNSSEC
Fig.2: DNSSEC Chain of Trust

Beispiel eines mit DANE abgesicherten Mailservers

Figure 3 zeigt den TLSA-Record für mail.dnssec-uni-potsdam.de. Der sendende Mailserver erhält aus dem DNS den MX- und den TLSA-Record des empfangenden Mailserver mail.dnssec-uni-potsdam.de. Mit dem TLSA-Record wird dem SMTP-Sender mitgeteilt, dass eine Kommunikation verschlüsselt erfolgen soll und nur einem Mailserver vertraut werden soll, der ein Zertifikat mit dem entsprechenden Fingerprint vorzeigt.

DANE
Fig.3: DANE-Architektur

Weblinks und Tools

DNSSEC und DANE in Praxis: [Slides] [Video]


Grundlagen DNSSEC
  • apnic - DNSSEC mit BIND
  • Doku LRZ - DNSSEC und DANE Dokumentation

Konfiguration DNSSEC

TOOLS

DANE RFCs

DNSSEC RFCs
  • RFC 4033 - Einführung in die DNS-Sicherheit/Anforderungen (2005)
  • RFC 4034 - Resource Records für DNS-Sicherheitserweiterung (2005)
  • RFC 4035 - Protokolländerungen für die DNS-Sicherheitserweiterungen (2005)
  • RFC 4470 - Minimale Abdeckung von NSEC-Datensätzen und DNSSEC-Onlinesignaturen (2006)
  • RFC 4641 - DNSSEC-Betriebsverfahren (2006)
  • RFC 5155 - DNS-Sicherheit (DNSSEC) Hashed Authenticated Denial of Existence (2008)
  • RFC 6014 - Zuweisung von Kennungen für kryptografische Algorithmen für DNSSEC (2010)
  • RFC 4641 - DNSSEC-Betriebsverfahren (2006)
  • RFC 6781 - DNSSEC-Betriebsverfahren Version 2 (2012)
  • RFC 7583 - Überlegungen zum DNSSEC-Schlüssel-Rollover-Timing (2015)

Literatur

Roll, Roll, Roll your Root: A Comprehensive Analysis of the First Ever DNSSEC Root KSK Rollover
M. Müller, W. Hardaker, M. Thomas, T. Chung, R. van Rijswijk-Deij, D. Wessels, W.
2019


The Impact of DNSSEC on the Internet Landscape
Matthäus Wander, Dissertation
Universität Duisburg-Essen
2015


Sicherheit im Domain Name System
Claas Lorenz, Bachelorarbeit
Universität Potsdam
2012

Fast Formal Security Verification in IPv6 Networks

Today, enforcing security is a tough challenge as security policies grow over time and networks become more and more complex. Eventually, rulesets with thousands of rules and large network configurations cannot be checked manually. Meanwhile, new networking approaches like Software Defined Networking (SDN) or Network Function Virtualization (NFV) introduce new possibilities in terms of scalability and flexibility but also increase the heterogenity and complexity of network setups. The same applies for state-of-the-art networking technologies like IPv6 with its extension header chains. Therefore, the goal of our research is to give operators the ability to automatically determine the security status of their network through an online supervision system attached to their regular management systems.


The design of such a security verification process is depicted in Figure 1. At first, the network configurations and topology need to be modeled. Together with the formal security invariant descriptions, these models are processed by a verification engine rendering the security status of the network. Our first approach was to model networks and describe security invariants in terms of general purpose model checkers. Our SAT-based implementation ad6 is approach suitable for a periodic reverification but not for online verification.

verification process
Fig.1: The security verification process

The main idea of our current approach is to leverage domain specific verification engines, like netplumber, that allow very fast invariant checking of large networks. Therefore, we introduce proper modeling abstractions for complex networking elements and implement advanced security invariant checks into the verification engine. Figure 2 shows the architecture of our implementation called FaVe which can be attached to the relevant security and network management systems as well as the network control as found in network operations. FaVe realizes a pipelined architecture which makes it suitable for an online detection of security violations and it is extensible by the implementation of custom modeling engines.

architecture of FaVe
Fig.2: Architecture of the fast verification framework FaVe

This research is performed in close cooperation with the genua GmbH.


Publications

Modeling IPv6 Firewalls for Fast Formal Verification
Claas Lorenz, Sebastian Kiekheben and Bettina Schnor
International Conference on Networked Systems (NetSys)
Göttingen, Germany, March 2017


Anomaly Detection for Distributed IPv6 Firewalls
Claas Lorenz and Bettina Schnor
12th International Conference on Security and Cryptography (SECRYPT)
Colmar, France, July 2015

IPv6 Intrusion Detection System

The transition from the currently used internet protocol version IPv4 to the official successor protocol IPv6 is an important technical requirement for the ongoing development of communication and network infrastructures within the next years. Therefore the security of IPv6 networks is of high social relevance and importance.


The project "IPv6 Intrusion Detection System" is realized in collaboration of "University of Potsdam", "Beuth-Hochschule für Technik", "EANTC" and "Strato AG". It is supported by the German "Federal Ministry of Education and Research".


For further information please visit the project website: www.ipv6-ids.de