DNSSEC und Zertifikate: Symbiose oder Widerspruch

Kommentieren Drucken

Was haben die Domain Name System Security Extensions und IPv6 gemeinsam: sie sind „uralt“ und kommen nur langsam in Fahrt. Aber noch etwas anderes haben sie gemeinsam: für die Zukunft des Internets sind beide von enormer Bedeutung.

Das Grundproblem der Zertifikate ist, dass jede CA jede Domain zertifizieren kann. Nimmt man nun hinzu, dass das DNS unter multiplen Schwachstellen leidet, ist es durch eine Kombination beider Verfahren möglich einen Man-in-the-Middle-Angriff zu generieren, indem man mittels gefaktem DNS-Eintrag auf einen Server mit falschem Zertifikat verweist.
Zugegeben, das ist nichts für die Script-Kiddis, aber für staatliche Spionage bspw. ist es vergleichsweise einfach.

Hier verspricht eine Kombination aus DNSSEC und Zertifikaten Abhilfe zu schaffen, genannt DNS-based Authentication of Named Entities (DANE). Im Folgenden werden die dafür notwendigen Verfahren vorgestellt und auf ihre Alltagstauglichkeit bewertet.

Schwachstellen von Zertifikaten

Das „Vertrauen“ im Internet basiert auf Zertifikaten. Gemäß dem Wiki von Mozilla vertraut der Firefox von Hause aus z. Zt. 174 Zertifikaten, die von 87 unterschiedlichen Organisationen ausgegeben werden. Zu diesen Organisationen gehören einige wenige Staaten wie „Staat der Nederlanden“, die meisten sind jedoch privatwirtschaftliche Unternehmen. So vertraut der Firefox bspw. „Unizeto Sp. z o.o.“, ich habe keinen Schimmer, wer das überhaupt ist, aber ich vertraue denen.

Von diesen „Root Zertifikaten“, die Programme wie Browser oder Email-Clients von Hause aus mitbringen, werden die Zertifikate abgeleitet, die unsere Internetkommunikation absichern sollen. Seien es Zugriffe auf Webseiten oder die Verschlüsselung von Emails. Wenn ich beispielsweise meine Homepage per HTTPS absichern möchte, so gehe ich wie folgt vor:

  1. Ich generiere ein asymmetrisches Schlüsselpaar.
  2. Den öffentlichen Schlüssel benutze ich, um daraus einen Certificate Signing Request (CSR) zu erstellen.
  3. Mit dem CSR wende ich mich an eine Certificate Authority (CA), die diesen CSR dann mit ihrem privaten Schlüssel signiert.

Die „Güte“ eines Zertifikates hängt dann davon ab, was die CA bei der Signierung meines Schlüssels alles überprüft. Im einfachsten Fall wird nur überprüft, ob das Zertifikat von einem Server eingereicht wird, der zu der Domäne gehört, für die das Zertifikat ausgestellt werden soll. Die höchste Stufe der Zertifizierung ist die persönliche Vorstellung bei der CA zum Nachweis der Identität. Je nach Güte wird mal nur das „https“ im Browser grün oder es wird auffällig hervorgehoben, um zu zeigen, dass bei der Erstellung eines Zertifikates einer Seite besonders viel Sorgfalt angewendet wurde. Bild 1 zeigt je ein Beispiel für ein besonders „gutes“ Zertifikat und eines mit sehr geringer Güte.

Außer den eigentlichen Root CAs gibt es auch noch Zertifizierungsstellen, die von einer Root ein Zertifikat bekommen haben, mit dem sie wiederum andere Domains zertifizieren können. Prominentes Beispiel ist die Initiative „Let’s Encrypt“ (https://letsencrypt.org/) von der Internet Security Research Group (ISRG), die es sich zum Ziel gesetzt hat, die Verschlüsselung im Internet weiter zu verbreiten, indem der aufwendige Zertifizierungsprozess vereinfacht und automatisiert wird. Das Zertifikat dieser Initiative ist von der CA IdenTrust ausgestellt.

Zertifikate können korrumpiert werden, indem es bspw. einem Angreifer gelingt, an den privaten Schlüssel zu kommen. Aber auch bei bekannten Sicherheitsunternehmen wie „Symantec’s Thawte-branded CA“ kommt es zu Fehlern respektive zu Fehlverhalten (vgl. https://security.googleblog.com/2015/09/improved-digital-certificate-security.html). Es gibt eine ganze Reihe von prominenten Beispielen, wo Zertifikate von Root CAs fehlerhaft ausgestellt wurden. Einige Beispiele sind:

  • 2011 wird bei Comodo eingebrochen und für eine Reihe prominenter Internetfirmen werden daraufhin falsche Zertifikate ausgestellt (google, yahoo…)
  • 2011 wird die Root-CA DigiNotar gehackt und es werden falsche Zertifikate für gmail und facebook ausgestellt.
  • 2015 wird bekannt / vermutet, dass die chinesische CA CCNIC ebenfalls gefälschte Zertifikate signiert.
  • 2015 stellt Comodo dem Inhaber der Email-Adresse hostmaster@live.fi ein SSL Zertifikat für den Inhaber Microsoft aus

Insgesamt kennt der RFC 5280 neun Gründe, aus denen ein Zertifikat zurückgezogen werden kann, zzgl. des Grundes „unspecified“. Das ungültige Zertifikat wird dann auf eine Sperrliste (Revocation List“) gesetzt und/oder mittels des moderneren „Online Certificate Status Protocol“ (OCSP) zurückgezogen.

Schwachstellen im DNS

Nicht nur das aktuelle Zertifizierungsverfahren hat Schwächen. Dasselbe gilt auch für das DNS. Das DNS kann an verschiedenen Punkte angegriffen werden. Einige sind recht einfach, haben jedoch nur geringe Auswirkungen, da sie auf ein LAN begrenzt sind, andere greifen die Server selbst an. Diese sind ungleich schwieriger, aber – wenn sie gelingen – auch ungleich effektiver.

Beispiele für Angriffsverfahren sind:

  • DNS Pakete abfangen
    Pakete abzufangen und somit abzuhören oder gar gefälschte Antworten zu geben, ist kein DNS-spezifisches Problem. Jedoch macht gerade das DNS es Angreifern sehr einfach, da die Kommunikation zwischen Client und Server meist nur aus einem Paket mit der Frage und einem weiteren mit der Antwort besteht. Das „klassische“ DNS kennt dabei keinen Mechanismus, den Absender zu verifizieren oder die Integrität des Inhaltes gegen Änderungen zu schützen. Dasselbe gilt auch für die Server-Server-Kommunikation.

    Sicherheitsfunktionen anderer Ebenen wie dem IP in Form von IPsec sind samt und sonders überdimensioniert für das DNS. Der Verwaltungsaufwand und Overhead dieser Protokolle würde gerade die zentralen DNS-Server wie Root-Server, TLD-Server oder rekursive Server großer Provider schnell an ihre Grenzen bringen und anfällig gegen DoS-Angriffe machen. Zudem würde ein solches Modell nur eine Hop-by-Hop-Sicherung zulassen. D.h. der Enduser könnte nicht überprüfen, ob bei der Antwort, die er von seinem rekursiven DNS-Server bekommt, die Kette der Anfragen immer durch IPsec gesichert gewesen ist.

  • ID raten und Fragen vorhersehen
    Da zwischen Fragendem und Gefragten (Client-Server, Server-Server) kein Verbindungsaufbau stattfindet und die Fragesteller meist viele Fragen offen haben, wird jede Frage mit einer ID versehen, die der Antwortende wiederholt. So kann der anfragende Resolver eine Antwort einer offenen Frage zuordnen und diese dann als beantwortet abhaken.

    Die Idee des ID Guessing ist es diese IDs vorherzusehen. Das alleine bringt einen Angreifer nicht weiter, denn er muss ja auch die Frage kennen, die zu einer ID gehört, denn ansonsten passt seine Antwort nicht zu der Frage und diese wird in den Antworten ebenso wiederholt wie die ID.

    Im Alltagsgeschäft ist es also fast unmöglich vorherzusagen, welche DNS Frage ein Client stellen wird und welche ID dazu gehört. Jedoch gibt es Situationen, bei denen das einfacher ist, als man vielleicht zunächst denkt, dazu gehört bspw. der Neustart eines Systems. Dieser folgt einem vorgegebenen Ritual beginnend mit DHCP – oder PPPoE, wenn man mit Port-Security arbeitet, und arbeitet sich anschließend einmal quer durch die AD-Landschaft (Controler, Kerberos-Server). Bei Telefonen ist es noch schlimmer, die suchen oft ihren Konfigurationsserver.

    Betrachtet man das Beispiel mit dem Telefon, wird klar, welchen Schindluder ein Angreifer mit einem gefälschten DNS-Paket anrichten kann: jubelt er dem Telefon den falschen Konfigurationsserver unter und wird die Konfiguration über das ungesicherte TFTP übertragen, so ist es ein Leichtes Gespräche abzuhören.

    Wo ist der Unterschied dieses eher aufwendigen Verfahrens (richtiges Raten von IDs und Fragen) verglichen mit dem ersten Angriffsmodel, dem Abfangen der Pakete? Dieses Verfahren funktioniert auch remote, d.h. wenn man sich nicht irgendwo in die Transferstrecke der DNS-Antworten einklicken kann. Ein Resolver wird die erste DNS-Antwort akzeptieren, die er bekommt und die Frage danach vergessen. Bekommt er später die Antwort vom richtigen DNS-Server, kann er sie bereits nicht mehr zuordnen und wird sie entsprechend verwerfen.

  • Name Chaining / DNS Spoofing / Cache Poisoning
    Unter Name Chaining werden vom RFC 3833 verschiedene Formen von Attacken auf das DNS zusammen gefasst, denen allen gemein ist, dass sie darauf beruhen DNS-Servern mittels Domain-Namen in DNS-Antworten falsche Informationen unterzujubeln.

    Das bekannteste Beispiel ist wohl der von Eugene Kashpureff aus dem Jahr 1997, als es ihm gelang eine Reihe großer Cache Server zu „vergiften“, indem er einen bereits bekannten Bug des BIND ausnutze.

    Das Vorgehen dabei ist typisch für Name Chaining Angriffe: ein Cache Server fragt einen anderen, korrumpierten DNS-Server. Zusätzlich zu der eigentlichen Antwort erhält er weitere Informationen. Beispiel: gefragt wird nach www.comconsult-akademie.de. Zusätzlich zur korrekten IP dieser Domain bekommt der Server in den Additional Records noch eine falsche IP Adresse www.comconsult-study.tv genannt. Diese speichert er. Sucht nun jemand nach www.comconsult-study.tv landet er auf der falschen Seite, da der Server die falsche Adresse in seinem Cache gespeichert hat und bei den Nameservern von comconsult-study.tv gar nicht erst nachfragt.

    Dieses einfache Vorgehen ist natürlich schon seit rund 20 Jahren nicht mehr möglich, aber seitdem gibt es viele Variationen davon. Die meisten davon beruhen darauf, auf falsche Namen zu verweisen, beispielweise per CNAME Einträgen, daher der Name „Name Chaining“.

    Auch wenn der RFC, der diese Angriffsvariante beschreibt, in die Jahre gekommen ist (von 2004), ist er bis heute aktuell. So gibt Microsoft beispielsweise an, dass im Zeitraum von Mai 2012 bis Juni 2013 17 ihrer registrierten Länderdomains zeitweilig korrumpiert waren (vgl. https://blogs.microsoft.com/microsoftsecure/2014/02/04/threats-in-the-cloud-part-1-dns-attacks/)

Ablauf von DNSSEC

Das Grundprinzip von DNSSEC ist – wenig überraschend – identisch mit dem von Zertifikaten: es gibt eine Root, deren öffentlicher Schlüssel wohl bekannt ist. Mit dem dazu passenden, geheimen Schlüssel können DNS Einträge signiert werden. Anders als bei Zertifikaten gibt es im DNS jedoch so etwas wie eine „natürliche Ordnung“, da das DNS hierarchisch ist. Statt unzähliger Root-CAs gibt es im DNS genau eine Root: „.“. Zwar gibt es unzählige Root-Server, deren Informationen sind jedoch identisch.

Diese Root bestätigt die Echtheit der so genannten Top Level Domains (TLD), also .org, .de, .info usw. Diese wiederum können dann ihrerseits die Echtheit der Second Level Domains bestätigen, wie bspw. tagesschaub.de, welche ihrerseits damit ihren eigenen Namespace signieren können.

Schauen wir uns im Folgenden das Verfahren etwas detaillierter an:

Am Anfang ist die Root. Für deren Inhalte (nicht Betrieb) ist das Internet Corporation for Assigned Names and Numbers (ICANN) verantwortlich. Dieses hat in einer „Zeremonie“ 2010 das asymmetrische Schlüsselpaar für die Root generiert. Die nächste Zeremonie findet 2017 statt.

Dabei wurde der so genannte Key Signing Key (KSK) erzeugt. Der KSK hat nur eine Aufgabe: andere Schlüssel zu signieren (vgl. Bild 2). Davon zu unterscheiden sind die Zone Signing Keys (ZSK). Mit diesen Schlüsseln werden alle anderen Resource Records (RR) einer Zone unterschrieben (vgl. Bild 3).

Mit diesem Root-KSK werden die Schlüssel der TLDs nun signiert, ebenso wie der ZSK der Root-Zone selbst. Aktuell sind nicht alle TLD-Zonen signiert, also nicht alle sind bereits auf DNSSEC umgestiegen. Für die de-Zone ist das jedoch der Fall. Wenn ich also meine Domaine ebenfalls auf DNSSEC umstellen möchte, so kann ich ein asymmetrisches Schlüsselpaar erzeugen und den öffentlichen Schlüssel vom DENIC unterschreiben lassen. Damit habe ich einen KSK für meine Domain.

Dann geriere ich ein weiteres Schlüsselpaar, das ZSK. Dessen öffentlichen Schlüssel unterschreibe ich dann mit dem geheimen Schlüssel meines KSK.

Die öffentlichen Schlüssel werden in der Zonendatei mit dem neuen Record-Typen DNSKEY hinterlegt. (siehe Bild 4)

Der KSK ist der Schlüssel mit der 257, der ZSK mit der 256. Das mag sich eines Tages noch ändern, da diese Zahlen durch das Setzen resp. Nicht-Setzen eines bestimmten einzelnen Bits zustande kommen. Die 3 und die 7 geben die Verfahren für Verschlüsselung und das Hashing an.

Warum nun diese Trennung von KSK und ZSK?
Grundsätzlich ist es sinnvoll, den geheimen Schlüssel, mit dem die Zoneneinträge signiert werden, nicht auf dem System zu hinterlegen, auf dem auch die Zonendatei selbst liegt. Jedoch gibt es Situationen, bei denen es technisch nicht anders geht oder es unsinnig ist, diesen im Tresor zu lagern. Ein Beispiel dafür ist das dynamische DNS (DDNS). Jedes Mal, wenn ein Client seinen Eintrag ändert oder neu anlegt, muss dieser neu signiert werden, dafür benötigt der Server den ZSK. DDNS ist somit ein Beispiel dafür, dass es sinnvoll ist, zwischen dem KSK und ZSK zu unterscheiden. Denn den „wichtigeren“ ZSK kann man im Tresor belassen und nur hervorholen, wenn ein neuer ZSK erzeugt wurde. Wird nämlich der geheime ZSK korrumpiert, weil auf meinen DNS-Server eingebrochen wurde, kann ich den Schlüssel einfach austauschen, ohne die Peinlichkeit das auch noch beim DENIC angeben zu müssen.

Ein weiterer Grund für die Trennung liegt darin, dass die Sicherheitsprinzipien eines Unternehmens sich von denen des NIC oder gar der Root unterscheiden. Will ein Unternehmen bspw. die Schlüssel jährlich austauschen, so ist das mit dem ZSK einfach möglich, ohne dass eine erneute Signierung durch das NIC notwendig wäre.

Um das System weiter abzusichern, wird nicht nur der KSK von der übergeordneten Domain unterschrieben, sondern bei der übergeordneten Domain wird auch ein Fingerabdruck dieses Schlüssels hinterlegt. Auf diese Weise kann ein noch gültiger Schlüssel zurückgezogen werden. Beispiel:

Ich wechsle meinen DNS Provider. Der alte kennt meinen geheimen KSK, da er für mich die gesamte Verwaltung der Zone übernommen hat. Der neue Provider generiert nun ein neues KSK Pärchen und lässt den öffentlichen Schlüssel vom DENIC unterschrieben. Nun existieren zwei gültige Schlüssel. Zwar haben die Schlüssel eine bestimmte Gültigkeitsspanne (von-bis), die fällt aber wahrscheinlich nicht mit meinem Providerwechsel zusammen. Damit sind die Unterschriften des DENIC unter dem alten und unter dem neuen Schlüssel für einen gewissen Zeitraum beide gültig.

Dier Fingerprint des aktuell gültigen KSK wird als DS-Record hinterlegt.

Das Besondere dieses RR ist, dass hierfür die althergebrachten Regeln des DNS geändert werden mussten: für gewöhnlich liegen alle Inhalte einer Zone in einer Zonendatei bei den zuständigen DNS-Servern. Das gilt nicht für den DS Record. Damit das System funktioniert, liegt er ausschließlich bei der übergeordneten Instanz. Im Falle von tagesschaub.de also beim DENIC.

Was mit diesen bisher beschriebenen Maßnahmen erreicht wurde, ist, dass es eine „Chain of Trust“, eine Vertrauenskette, gibt: wenn ich der Root vertraue und diese dem DENIC, dann vertraue ich auch dem DENIC. Da das DENIC wiederum der Domain tagesschaub.de vertraut, vertraue ich auch dieser Domain, usw.

Was noch fehlt, ist die Signatur der eigentlichen Inhalte. Denn was wirklich interessiert, ist ja, dass ich nachher eine IP Adresse oder einen Mailserver dieser Domain genannt bekomme und darauf vertrauen kann, dass diese spezifische Information korrekt ist. Dafür wird ein weiterer Typ eingeführt der RRSIG (Ressource Record Signature).

Das Beispiel zeigt: fordert man neben der eigentlichen Information – hier der IPv6 Adresse – auch noch die dazugehörigen DNSSEC Daten, so bekommt man zusätzlich zum AAAA Record noch den dazugehörigen RRSIG zurück geliefert.

Der RRSIG enthält neben der Unterschrift, das ist der Hash am Ende, noch weitere Informationen:

  • Das genutzte Unterschriftsverfahren
    Im Beispiel ist das eine Kombination aus RSA und SHA, gekennzeichnet durch die 7 hinter AAAA.
  • Anzahl der Namenskomponenten
    Hier 3: www, tagesschaub, de
  • Das originale TTL
    Hier 3600. Da bei der Signatur ein Hash über den Eintrag gebildet wird, muss derjenige, der den Hash überprüfen will, alle Angaben kennen. Das TTL, das er genannt bekommt, kann jedoch von dem originalen abweichen, da ein Cache-Server das TTL herunter zählt, solange der Eintrag in seinem Cache liegt.
  • Die Gültigkeitsperiode der Unterschrift
    Diese Signatur ist gültig bis 20161004100018 und zwar seit 20160904100018. Also vom 04. September bis 04. Oktober 2016.
  • Ein Tag zur Schlüsselidentifizierung (Key Tag)
    Wird bspw. der Schlüssel vor Ablauf seiner Gültigkeit geändert, so können durch das Caching von DNS Einträgen noch alte Signaturen im Umlauf sein. Die Gültigkeitsperioden des neuen und des alten Schlüssels sollten sich somit um mindestens die Dauer des längsten TTL einer Zone überschneiden. Damit ein Client den „richtigen“ Schlüssel wählt, kann er den mittels Key Tag identifizieren, wenn mehr als einer im Umlauf ist.
    Ungültige/Abgelaufene Schlüssel müssen natürlich verworfen werden.
  • Der Besitzer (Owner)
    Der Owner ist der Besitzer des Schlüssels, also die Zone. In diesem Fall ist das tagesschaub.de.
    Interessant wird es bei Einträgen wie www.test.tagesschaub.de, denn dann könnte der Owner test.tagesschaub.de sein, aber auch tagesschaub.de, je nachdem, ob eine Delegation stattgefunden hat oder nicht.

Bleibt noch ein Problem zu lösen: wie kann man gesichert sagen, dass es einen gesuchten Eintrag nicht gibt? Einen allgemeingültigen Eintrag zu generieren, der schlicht „nein“ sagt, geht nicht, da dieser beispielsweise durch Replay Attacken einfach zu einem Denial of Service genutzt werden könnte. On-the-Fly eine Signatur zu generieren ist aufwendig und würde einfache Denial-of-Service Angriffe gegen einen DNS-Server ermöglichen, indem man diesen überlastet. Der gewählte Lösungsansatz sieht wie folgt aus:

  • Die Zone wird zunächst sortiert (canonical order)
  • Zu jedem Eintrag wird ein weiterer Eintrag erzeugt, der angibt, wer der nächste in der Liste ist. Das ist der NSEC-Record
  • Wird ein nicht existenter Name gesucht, bekommt man den NSEC-Record des vorhergehenden Eintrags genannt.

Beispiel: es gibt a.tagesschaub.de und c.tagesschaub.de. Sucht nun jemand nach b.tagesschaub.de bekommt er als Antwort, dass der Nachfolger von a c ist. Damit ist dem Suchenden klar, dass es b nicht gibt.

Dieser Ansatz löst zwar das Problem, wirft aber ein neues auf: mittels der Suche nach nicht existenten Domainnamen ist es einfach sehr schnell alle Domain Namen zu finden, die es in der Domain gibt. Das ist häufig aber nicht gewollt.

Darum wurde der ursprüngliche NSEC Record durch den neuen NSEC3 Record abgelöst.

Dabei bleibt das Grundprinzip erhalten: wird b gesucht, dann bekommt man als Antwort, dass der Nachfolger von A C ist, nur wird das nicht mehr so klar ausgesprochen. Statt A und C im Klartext zu nennen werden die Namen als „gesalzener“ Hash zurückgegeben. Somit kann der Anfragende nicht herausfinden, welche Namen sich hinter den Hashes wirklich verbergen.

Auch die NSEC3 Records werden signiert, sprich es wird ein dazugehöriger RRIG Record erzeugt.

Natürlich nützt es nichts, wenn die Einträge im DNS signiert werden und niemand nach den Signaturen fragt. Es reicht also nicht, dass nur die Server DNSSEC unterstützen, auch die Resolver müssen es machen und irgendwie muss die genutzte Software das Ergebnis an den Enduser übermitteln.

Die Standards sehen zwei Varianten vor. Zum einen den security-aware Resolver. Dieser kann die Signaturen selbst überprüfen. D.h. er kennt den Root-Schlüssel und kann die Chain of Trust selbst nachbilden. Dazu muss er über kryptographische Fähigkeiten verfügen und häufig mehr als eine Anfrage stellen, um die notwendigen DNSKEY und DS Einträge abzufragen. Dabei können ihm irgendwelche Middleboxen in die Quere kommen. Gemeint sind Firewalls, IDS oder rekursive Nameserver, die entsprechende Anfragen blockieren. In diesen Fällen überlasst es der Standard lokalen Sicherheitsrichtlinien, wie ein Resolver respektive eine Software zu reagieren hat.

Neben dem security-aware Resolver gibt es noch den security-aware Stub-Resolver. Stub-Resolver sind die Regel bei Clients. Sie lösen die Namen nicht selbst auf, sondern wenden sich an einen rekursiven Nameserver, der die Arbeit für sie übernimmt und sich bei Bedarf durch den DNS-Baum bis zur gewünschten Antwort hangelt. Dieses Prinzip wird für den security-aware Stub-Resovler beibehalten und um die notwendigen Sicherheitsprüfungen ergänzt. Der Resolver signalisiert dem Server dazu, dass er eine Sicherheitsüberprüfung wünscht, dazu setzt er ein Bit, das DO Bit (DNSSEC OK) im erweiterten DNS Header. Der Server setzt in seiner Antwort das Authenticated Data (AD) Bit, wenn die Authentifizierung gelungen ist, wenn sie fehlschlug oder nicht möglich war, setzt der Server das entsprechende Bit nicht. Einen Grund, warum die Sicherheitsüberprüfung fehlschlug, nennt er jedoch nicht.

Sinn macht das mit den security-aware Stub-Resolvern natürlich nur, wenn die Verbindung zwischen Resolver und rekursivem Nameserver sicher ist. Wie das geschehen kann, lässt der Standard offen. Ob sie nun nach guter alter Manier davon ausgehen, dass ihr LAN sicher ist, IPsec verwenden oder auf DNS-eigene Mittel wie TSIG und dessen Derivate vertrauen, bleibt dem Betreiber überlassen.

Bleibt noch die Frage: wie merkt der User eigentlich, ob eine Domain mittels DNSSEC gesichert wurde und wenn ja, ob die Überprüfung funktioniert hat?

Genau das ist zur Zeit der wohl größte Schwachpunkt. Anders als bei Zertifikatsüberprüfungen bringen Browser oder andere Software wie Email-Server und -Clients diese Fähigkeit von Hause aus nur in Ausnahmefällen mal mit. Bei den Mailservern wäre hier Postfix zu nennen. Für die Browser sieht es mau aus. Es gibt Plug-Ins für Firefox und Chrome. Aktuell funktioniert das für Chrome allerdings nicht. Eine erfolgreiche DNSSEC Überprüfung beim Firefox ist in Bild 8 dargestellt.

Bewertung von DNSSEC

Der Clou ist, dass man für jede Instanz nur Instanzen signieren darf, die im DNS-Baum unter ihr aufgehängt sind. Das DENIC darf also comconsult-akademie.de signieren, nicht aber comconsult-study.tv, dafür wäre die TLD-Autorität von .tv notwendig. Auf diese Weise ist es technisch nicht mehr nötig einer unüberschaubaren Anzahl von Organisationen vertrauen zu müssen, sondern es reicht, der Root zu vertrauen, um die Chain of Trust vollständig überprüfen zu können. Wesentlich ist das Wort „technisch“, denn ob man jedem Unternehmen, das eine TLD verwaltet und jedem Staat mit Länderkennung vertraut, bleibt natürlich dem User weiterhin überlassen. Aber anders als bei Zertifikaten kann es nur noch eine Instanz geben und damit auch nur eine gültige Signatur. UK kann comconsult-akademie.de eben nicht signieren, wohingegen jede Organisation, die über ein Root Zertifikat verfügt, es kann.

Bliebe die Frage, ob man der Root vertraut. Da hat man nur zwei Varianten: entweder man traut ihr oder man faltet sich einen Aluhut. Denn wenn die Root des DNS kompromittiert ist, dann war es das mit dem DNS ohnehin. In diesem Fall können Sie in Ihren Browser eintippen, was sie wollen, nicht mal mehr Ihrer Lieblingsverschwörungstheoriewebseite können Sie dann noch trauen.

Die eigentliche Frage ist aber gar nicht, ob man der Root traut oder nicht, sondern was DNSSEC eigentlich bringt.

Selbst in Deutschland lässt sich da feststellen: erstmal ziemlich wenig.

Bei DNSSEC wird mittels einer „Chain of Trust“ garantiert, dass eine Information zu einer DNS-Domain authentisch ist und während der Übertragung nicht gefälscht wurde. Was DNSSEC nicht garantiert, ist, dass die Domain selbst vertrauenswürdig ist und auch nicht, dass die Inhaberdaten korrekt sind. Zur Erinnerung nochmal das Beispiel www.tagesschaub.de (vgl. Bild 9).

Die Chain of Trust kann in diesem Fall komplett überprüft werden. Damit ist garantiert, dass www.tagesschaub.de die IP Adresse 2001:41d0:52:300::9b8 hat. Wer jedoch dieser ominöse Tagesschaub ist, wissen Sie nicht. Das können Sie zwar beim DENIC nachschlagen, aber dort „Müll“ zu hinterlegen ist einfach: mit dem DENIC hatte ich selbst nie Kontakt, nur mit meinem DNS Provider und der prüft nur seine Kontoauszüge, nicht meine Identität.

Weltweit wird das noch unglaubwürdiger: können Sie sich sicher sein, dass www.microsoft.info wirklich die Firma Microsoft aus Redmond ist und nicht irgendein Spaßvogel?

Fassen wir zusammen:

  • Zertifikate garantieren die Authentizität des Seitenbetreibers und ermöglichen die Verschlüsselung der Übertragung. Allerdings gibt es viele, die „glaubwürdige“ Zertifikate ausstellen können und der Seitenbetreiber hat keine Möglichkeit einem User mitzuteilen, welches Zertifikat wirklich echt ist.
  • DNESSEC garantiert die Authentizität und Integrität von DNS Informationen aller Art. Mehr aber auch nicht.
    Wenn man beides kombiniert, indem man die Echtheit eines Zertifikates mittels DNS sicherstellt, kommt man einen Schritt weiter. Das ist der Ansatz von DANE.

DANE

Die Idee hinter DNS-based Authentication of Named Entities kurz DANE ist es, dem User mittels DNS mitzuteilen, welche Bedingungen ein Zertifikat erfüllen muss, damit es echt ist.

Dafür stehen mehrere Möglichkeiten zur Verfügung, aus denen man die für seine Situation passende auswählen kann:

  1. Der Betreiber der Webseite gibt dem User mittels DNS an, welche CA er gewählt hat. Diese CA muss dem User bekannt sein, oder zumindest muss sie von einer ihm bekannten Root CA signiert sein.
    Stellt nun eine andere CA ein Zertifikat für diese Webseite aus, würde das Zertifikat von einem Client, der DANE nutzt, nicht akzeptiert werden.
  2. Das Server-Zertifikat wird spezifiziert und der Client wird angewiesen, zu prüfen, ob dieses Zertifikat auch von einer ihm bekannten CA unterschrieben wurde.
  3. Es wird auf eine CA verwiesen, die das Zertifikat unterschrieben hat. Der Client prüft zwar die Unterschrift der CA, jedoch ist es egal, ob er die CA selbst kennt oder nicht.
  4. Das Server-Zertifikat selbst wird spezifiziert, eine CA wird nicht genannt.

Betrachten wir kurz vier Anwendungsfälle, dann werden diese Varianten deutlicher:

Fall 1: Automatischer Zertifikatsaustausch
Momentan versuchen Cisco, Mozilla, OVH und einige andere große Unternehmen, die irgendwie mit dem Internet zu tun haben, Verschlüsselung von Webseiten so weit zu vereinfachen wie möglich. Das Projekt heißt Let’s Encrypt. Wer daran teilnimmt bekommt Tools an die Hand gegeben, die mehr oder weniger automatisch ein Webserverzertifikat erstellen, einpflegen und regelmäßig austauschen. Im regelmäßigen Austausch liegt nun das Problem: ändert sich das Zertifikat, bekommt der User entweder nichts davon mit oder zu spät. D.h. würde man einen Fingerprint des Server-Zertifikates im DNS hinterlegen, hätte man ein Problem. Hier bietet es sich an die erste oder dritte Option zu wählen, da sich die CA hoffentlich nicht ändert. Allerdings muss man auch in diesem Fall prüfen, ob sich das CA-Zertifikat geändert hat. Das dürfte deutlich seltener der Fall sein.

De facto wählen in diesem Fall die meisten die dritte Option, denn diese Variante ist etwas für private User. Diese prüfen nicht regelmäßig, ob die CA noch in allen Browsern vorhanden ist oder nicht.

Fall 2: Selbst erzeugte Zertifikate
Gerade in Unternehmen wird intern mit lokalen Zertifikaten gearbeitet, die von keiner CA unterschrieben wurden und denen trotzdem vertraut werden soll. Dann kann man zwar ein eigenes Root Zertifikat auf allen Systemen ausrollen, das macht aber unter Umständen wenig Spaß oder ist schlicht nicht möglich.

In diesem Fall bietet sich Option 4 an: im DNS wird ein Fingerprint des Server-Zertifikates hinterlegt und der Client wird informiert, dass es völlig egal ist, ob und wer dieses Zertifikat unterschrieben hat.

Fall 3: Öffentlicher Unternehmenswebserver
Für (viel) Geld hat man ein Zertifikat bei einer CA signieren lassen, dass die kommenden N Jahre gültig ist. Da dieser Prozess nicht automatisch ist, weiß man, wann das Zertifikat ausgetauscht wird.
Damit ist Option 2 perfekt: man nennt dem Client den Fingerprint des eigenen Zertifikates und weist ihn an, auch den gesamten Pfad inkl. der CA zu prüfen. Das ist die höchste Stufe der Sicherheit, aber auch die am wenigsten flexible.

DANE kennt noch zwei weitere Parameter:

  1. Was wurde gehashed
    Der Standard sieht dafür zwei Möglichkeiten vor:
    • Gesamtes Zertifikat
      Die Daten des gesamten Zertifikates
      werden genutzt.
    • Public Key + Algorithmus
      Es wird nur ein Hash über den Public Key und den Algorithmus gebildet.
  2. Das Hashing Verfahren
    Hier gibt es bislang drei Varianten
    • Es wird gar nicht gehashed, stattdessen wird das gesamte Zertifikat per DNS übermittelt.
      Dieses Verfahren wird nicht empfohlen und ist eigentlich auch unsinnig, da das Zertifikat ohnehin über andere Protokolle übertragen wird (bspw. TLS). Bei DANE geht es schließlich nur darum, sicher zu stellen, dass das Zertifikat echt ist, nicht um einen Zertifikatstausch.
    • SHA-256
    • SHA-512

Um das DANE Verfahren nun noch in das DNS zu integrieren bedarf es eines neuen Ressource Records. Das ist der TLSA Record (vgl. Abbildung 10). TLSA steht übrigens nicht für TLS Authenticator oder Ähnliches, es steht für gar nichts. Es ist ein Akronym, das keines ist.

Als Beispiel musste bislang die Absicherung von Webseiten herhalten. DANE ist aber nicht darauf beschränkt. Vielmehr kann man es für jede Zertifikats-basierte und an DNS-Namen gebundene Kommunikation nutzen, also bspw. auch für Mail. In der Tat sind es gerade einige Mail-Provider, die DANE aktiv im Einsatz haben, wie Posteo, mail.de oder mailbox.org und einige mehr.

Da für verschiedene Dienste durchaus verschiedene Zertifikate genutzt werden können und auf einem Server mehrere Dienste parallel laufen können, benötigt man für DANE noch eine Dienstunterscheidung. Dafür werden Port und Protokoll genutzt. Der TLSA-Eintrag ähnelt somit einem SRV Ressource Record, da dem eigentlichen Namen noch diese beiden Informationen vorangestellt werden. Vollständig sieht das Ganze dann wie Bild 10 aus.

Wie schon bei DNSSEC macht DANE nur dann wirklich Sinn, wenn Erfolg oder Misserfolg für den User transparent gemacht wird. Dasselbe Firefox Plug-In, das DNSSEC überprüft, kann auch DANE validieren. Bild 11 zeigt die erfolgreiche Verifikation eines Zertifikates. Das Plug-In gibt auch an, was geprüft wurde, im Beispiel wurde die der Fingerprint des CA-Zertifikates angegeben und der gesamte Zertifikatspfad geprüft.

Bewertung

Diejenigen, die mit diesem Verfahren das Ende der CAs kommen sehen, beziehen sich ausschließlich auf den 4. Fall der DANE-Prüfverfahren, bei dem nur ein Fingerprint des Zertifikates im DNS hinterlegt wird und eine Überprüfung der Zertifikatskette unterlassen werden soll. Damit ist es in der Tat möglich, ein selbst erstelltes Zertifikat zu nutzen und im DNS für gültig zu erklären. Die Sicherheitsstufe, die damit erreicht wird, entspricht derjenigen, wie sie bspw. von Let’s Encrypt erreicht wird: der Nutzer kann sich sicher sein, dass das Zertifikat zu der Domain gehört, mit der er redet (DANE) und dass auch die IP Adresse zu genau dieser Domain gehört (DNSSEC). Mehr aber auch nicht. Wie bereits geschrieben, das DENIC hat meine Identität nie geprüft.

Für viele Webseiten wäre das wahrscheinlich auch völlig ausreichend, wenn es nur darum geht, sicher zu stellen, dass mein Passwort für irgendein x beliebiges Forum sicher übertragen wird, reicht mir das. Für Online-Banking ist das sicherlich nicht zufriedenstellend. Für höhere Sicherheitsansprüche werden Zertifikate weiterhin unerlässlich sein. Aber wenn eben diese gesteigerten Sicherheitsansprüche erfüllt werden sollen, bieten DNSSEC und DANE eine ausgezeichnete – und kostenfreie – Ergänzung zur bestehenden Zertifikatsinfrastruktur.
Das große Manko von DNSSEC – und somit auch von DANE – ist die geringe Verbreitung. Das umfasst alle betroffen Ebenen:

  • Nicht alle TLDs nehmen bereits daran teil.
  • Serversoftware bspw. Email-Server sind nur zu einem geringen Anteil DNSSEC fähig.
  • Die ausgerollten Resolver sind nicht mal security-aware Stub-Resolver.
  • Middleboxen blockieren in Unternehmen DNSSEC Fragen und Antworten, da sie den DNS-Typ nicht kennen.
  • Kaum Clientsoftware signalisiert den Status von DNSSEC.

Letzteres ist traurig, denn zum einen zeigt das Firefox Plug-In, wie das elegant gemacht werden kann und zum anderen würde die Anzeige den Druck auf alle anderen Beteiligten erhöhen, DNSSEC flächendeckend.

zugeordnete Kategorien: Archiv, Klassiker
zugeordnete Tags:

Sie fanden diesen Beitrag interessant? Sie können



Anmerkungen, Fragen, Kommentare, Lob und Kritik:

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

.