DANE für unseren Mail-Server: Difference between revisions

From
Jump to navigation Jump to search
(Softwareunterstützung)
 
(7 intermediate revisions by 2 users not shown)
Line 1: Line 1:
==1 Motivation==
=Motivation=
===1.1 Bekannt aus den Nachrichten===
===Bekannt aus den Nachrichten===
In den letzten Jahren haben sich vermehrt die Probleme einer herkömlichen PK-Infrastruktur gezeigt, wie sie für die Sicherung der Kommunikation mittels TLS und x509 Zertifikaten genutzt wird.
In den letzten Jahren haben sich vermehrt die Probleme einer herkömmlichen PK-Infrastruktur gezeigt, wie sie für die Sicherung der Kommunikation mittels TLS und x509-Zertifikaten genutzt wird.


Dabei wurden CAs immer wieder dazu gebracht Zertifikate für unberechtigte auszustellen. Dies geschah oft durch mangelnde Einhaltung ihrer eigenen (vertrauensgebenden) Richtlinien (Policies) oder auch auf Betreiben Krimineller, die sich unberechtigt Zugang verschafften.
Dabei wurden CAs immer wieder dazu gebracht Zertifikate für Unberechtigte auszustellen. Dies geschah oft durch mangelnde Einhaltung ihrer eigenen (vertrauensgebenden) Richtlinien (Policies) oder auch auf Betreiben Krimineller, die sich unberechtigt Zugang verschafften.


====1.1.1 siehe auch:====
'''siehe auch'''
*http://heise.de/-1336603
*http://heise.de/-1336603
*http://heise.de/-2255992
*http://heise.de/-2255992
*http://heise.de/-1776879
*http://heise.de/-1776879


===1.2 Bisherige Ansätze===
===Bisherige Ansätze===
In der großen weiten Internet-Welt sind verschiedene Konzepte üblich, um Kommunikation mit verschiedenen Sicherheitsbedürfnissen zu realisieren. Ein häufig anzutreffender Ansatz besteht darin, die Kommunikation gänzlich unverschlüsselt durchzuführen. Beispiele hierfür sind unter anderem die ersten Whatsapp-Versionen, Email-Dienste und sehr häufig das Web im Allgemeinen (http). In der Post-Snowden-Ära versteht sich von selbst, dass sich die Sicherheitsbedürfnisse der Endanwender geändert haben. Die gänzlich ungesicherte Kommunikation ist heute oftmals nicht mehr erwünscht. Diverse kommerzielle Anbieter haben die bestehende Verunsicherung der Nutzer genutzt um prestigeträchtige Kampagnen zur Datensicherheit der Kunden zu starten. Ein Beispiel stellt die "Email made in Germany" Initiative dar, deren Mitglieder sich zum verschlüsselten Email-transfer untereinander verpflichtet haben, dabei wird jedoch nicht auf offene Standards gesetzt, sondern auf proprietäre nicht öffentlich verifizierbare Verfahren. Des weiteren ist die Mitgliedschaft in dieser Initiative mit nicht unerheblichen finanziellen Verpflichtungen verbunden, so dass eine flächendeckende Verbreitung weder möglich (insbesondere für kleine non-profit Unternehmen), noch erstrebenswert ist.
In der großen weiten Internet-Welt sind verschiedene Konzepte üblich, um Kommunikation mit verschiedenen Sicherheitsbedürfnissen zu realisieren. Ein häufig anzutreffender Ansatz besteht darin, die Kommunikation gänzlich unverschlüsselt durchzuführen. Beispiele hierfür sind unter anderem die ersten Whatsapp-Versionen, Email-Dienste und sehr häufig das Web im Allgemeinen (http). In der Post-Snowden-Ära versteht sich von selbst, dass sich die Sicherheitsbedürfnisse der Endanwender geändert haben. Die gänzlich ungesicherte Kommunikation ist heute oftmals nicht mehr erwünscht. Diverse kommerzielle Anbieter haben die bestehende Verunsicherung der Nutzer genutzt um prestigeträchtige Kampagnen zur Datensicherheit der Kunden zu starten. Ein Beispiel stellt die "Email made in Germany" Initiative dar, deren Mitglieder sich zum verschlüsselten Emailtransfer untereinander verpflichtet haben, dabei wird jedoch nicht auf offene Standards gesetzt, sondern auf proprietäre nicht öffentlich verifizierbare Verfahren. Des Weiteren ist die Mitgliedschaft in dieser Initiative mit nicht unerheblichen finanziellen Verpflichtungen verbunden, so dass eine flächendeckende Verbreitung weder möglich (insbesondere für kleine non-profit Unternehmen), noch erstrebenswert ist.


Wenn eine gesicherte Verbindung gewünscht ist, dann wird oft auf ein PKI-gestützes Vertrauensmodell zurückgegriffen. Dazu wird in allen gängigen Endanwendungen eine Liste mit vertrauenswürdigen CAs, schon bei der Installation, hinterlegt. Die Beziehung zwischen dem im Zertifikat angegebenen Common Name und dem angefragten Host wird über das Domain Name System hergestellt. Dieses weit verbreitete Verfahren birgt jedoch einige Schwachstellen, auf die im weiteren Verlauf eingegangen wird.
Wenn eine gesicherte Verbindung gewünscht ist, dann wird oft auf ein PKI-gestützes Vertrauensmodell zurückgegriffen. Dazu wird in allen gängigen Endanwendungen eine Liste mit vertrauenswürdigen CAs, schon bei der Installation, hinterlegt. Die Beziehung zwischen dem im Zertifikat angegebenen Common Name und dem angefragten Host wird über das Domain Name System hergestellt. Dieses weit verbreitete Verfahren birgt jedoch einige Schwachstellen, auf die im weiteren Verlauf eingegangen wird.
Line 17: Line 17:
Gerade für die Absicherung des Email-Backends könnte man bekannte öffentliche Schlüssel von Remoteservern fest im Mailserver hinterlegen. Dieses Verfahren hat jedoch den gleichen großen Nachteil, wie auch die "Email made in Germany" Initiative: die Skalierbarkeit ist durch den vergleichsweise hohen administrativen Aufwand beschränkt.
Gerade für die Absicherung des Email-Backends könnte man bekannte öffentliche Schlüssel von Remoteservern fest im Mailserver hinterlegen. Dieses Verfahren hat jedoch den gleichen großen Nachteil, wie auch die "Email made in Germany" Initiative: die Skalierbarkeit ist durch den vergleichsweise hohen administrativen Aufwand beschränkt.


===1.3 Probleme===
===Probleme===
Ein zentrales Problem in der praktischen Anwendung der heutigen CA-basierten PKI ist das uneingeschränkte Apriori-Vertrauen in jede einzelne der potentiell zahlreichen CAs. So kann jede CA, mangels eines Zuständigkeitskonzepts, für jede beliebige Domain Zertifikate ausstellen, was die Ausnutzbarkeit der zuvor erwähnten Sicherheitsbedenken drastisch erhöht. Das Vertrausmodell mit großen vorgefertigten CA-Listen ist aufgrund seiner opt-out Eigenschaft (allen default CAs wird vertraut, solange ihnen das Vertrauen nicht entzogen wird) potentiell angreifbar (siehe 1.1).
Ein zentrales Problem in der praktischen Anwendung der heutigen CA-basierten PKI ist das uneingeschränkte Apriori-Vertrauen in jede einzelne der potentiell zahlreichen CAs. So kann jede CA, mangels eines Zuständigkeitskonzepts, für jede beliebige Domain Zertifikate ausstellen, was die Ausnutzbarkeit der zuvor erwähnten Sicherheitsbedenken drastisch erhöht. Das Vertrausmodell mit großen vorgefertigten CA-Listen ist aufgrund seiner opt-out Eigenschaft (allen default CAs wird vertraut, solange ihnen das Vertrauen nicht entzogen wird) potentiell angreifbar (siehe 1.1).


==2 Technische Details==
=Technische Details=
===2.1 Was ist DANE?===
===Was ist DANE?===
DNS-based authentication of named entities (DANE) ist ein Verfahren zur Absicherung öffentlicher Schlüssel eines Zielservers zum geschützten Datenaustausch mittels TLS. Dazu werden Informationen über den öffentlichen Schlüssel im DNS veröffentlicht. Da DNS Daten nicht authentisch verteilen kann, wird für DANE die DNS-Erweiterung DNSSEC benötigt. Durch die Nutzung von DNSSEC lassen sich kryptographisch verifizierbare Aussagen über die Authentizität der abgefragten Daten treffen.
DNS-based authentication of named entities (DANE) ist ein Verfahren zur Absicherung öffentlicher Schlüssel eines Zielservers zum geschützten Datenaustausch mittels TLS. Dazu werden Informationen über den öffentlichen Schlüssel im DNS veröffentlicht. Da DNS Daten nicht authentisch verteilen kann, wird für DANE die DNS-Erweiterung DNSSEC benötigt. Durch die Nutzung von DNSSEC lassen sich kryptographisch verifizierbare Aussagen über die Authentizität der abgefragten Daten treffen.


===2.2 Funktionsweise DNSSEC===
===Funktionsweise DNSSEC===
Wie bei anderen PKIs basiert das Vertrauen bei DNSSEC auf dem hierarchischen Aufbau. Bei DNSSEC gibt es jedoch nur einen einzelnen Vertrauensanker, der eine klare Zuständigkeit vorgibt. Es handelt sich dabei um den Schlüssel mit dem die Rootzone signiert wurde (15.07.2010 Rootzone signiert (http://heise.de/-1039401)). Dieser wird von der ICANN in Zusammenarbeit mit VeriSign verwaltet und ist allgemein bekannt.
Wie bei anderen PKIs basiert das Vertrauen bei DNSSEC auf dem hierarchischen Aufbau. Bei DNSSEC gibt es jedoch nur einen einzelnen Vertrauensanker, der eine klare Zuständigkeit vorgibt. Es handelt sich dabei um den Schlüssel mit dem die Rootzone signiert wurde (15.07.2010 Rootzone signiert (http://heise.de/-1039401)). Dieser wird von der ICANN in Zusammenarbeit mit VeriSign verwaltet und ist allgemein bekannt.


===2.3 Zugewinn durch DNSSEC===
===Zugewinn durch DNSSEC===
Durch die Nutzung von DNSSEC erhält man die Validierbarkeit der Auflösung/Zuordnung von Name auf im DNS abgelegte Daten. Dies gilt jedoch nur unter der Annahme, dass die ICANN/VeriSign, sowie die Zwischenzonen vertrauenswürdig sind.
Durch die Nutzung von DNSSEC erhält man die Validierbarkeit der Auflösung/Zuordnung von Name auf im DNS abgelegte Daten. Dies gilt jedoch nur unter der Annahme, dass die ICANN/VeriSign, sowie die Zwischenzonen vertrauenswürdig sind.


Seit Mai 2011 ist die .de - Zone signiert (http://denic.de/domains/dnssec.html)
Seit Mai 2011 ist die .de - Zone signiert (http://denic.de/domains/dnssec.html)


===2.4 Funktionsweise DANE===
===Funktionsweise DANE===
DANE besteht im wesentlichen aus einem neu definierten Resource Record für das DNS. Dabei handelt es sich um den sogenannten TLSA Record. Dieser ist wie folgt aufgebaut:
DANE besteht im Wesentlichen aus einem neu definierten Resource Record für das DNS. Dabei handelt es sich um den sogenannten TLSA Record. Dieser ist wie folgt aufgebaut:


<pre>_PORT._PROTO. domain . t l d . TLSA x y z WERT
<pre>_PORT._PROTO. domain . t l d . TLSA x y z WERT
Line 57: Line 57:
2 sha512</pre>
2 sha512</pre>


==3 Umsetzung (HowTo)==
=Umsetzung (HowTo)=
[[File:Versuchsaufbau.png]]
[[File:Versuchsaufbau.png]]
===named/BIND einrichten (DNS)===
===named/BIND einrichten (DNS)===
Line 97: Line 97:


dnssec-signzone -o itsec. -t db.itsec_root</pre>
dnssec-signzone -o itsec. -t db.itsec_root</pre>
===DANE einrichten (TLSA RR)===
<pre>_PORT._PROTO. domain . t l d . TLSA x y z WERT

x Usage Field
y Selector Field
z Matching-Type Field
WERT sha256 || sha512 || x509

Usage Field
0 einschränken auf CA (PKIX)
1 einschränken auf Zertifikat (PKIX)
2 Vertrauensanker verwenden
3 Zertifikat nutzen

Selector Field
0 ganzes Zertifikat
1 öffentlicher Schlüssel

Matching-Type Field
0 ungehashter Selector
1 sha256
2 sha512</pre>
Beispiel:
<pre>_25._tcp.mail.itsec. IN TLSA 3 0 1 8107bd7ccc81a57cecfafa1ff1c2a107b49b5a32308f70dfe1c9ce53f9732dc2</pre>
in diesem Fall lässt sich der Fingerprint mit folgendem Kommando erzeugen:
<pre>openssl x509 -in servercert.pem -noout -fingerprint -sha256 | tr -d ":" | sed 's/SHA256 Fingerprint=//'</pre>

=Softwareunterstützung=
===Endanwendungen===
Die Unterstützugng von DANE und DNSSEC seitens nutzbarer Endanwendungen ist leider nach wie vor gering. So kann beispielsweise kein aktueller '''Browser''' (Stand September 2014) von Hause aus eine DNSSEC-Prüfung vornehmen, geschweige denn TLSA-Records beim TLS-Verbindungsaufbau abgleichen. Es existieren zum Beispiel für Firefox und Chrome entsprechende Plugins, die diese Aufgabe übernehmen können, doch von einer weitreichenden, nutzerfreundlichen Anwendbarkeit kann keine Rede sein. Dasselbe gilt auch für E-Mail-Clienten wie Thunderbird u.ä..

Auf Server-Seite ist die Situation ein wenig besser, wenn auch nicht gravierend. Ein Beispiel dafür sind '''Mailserver'''. Während Postfix seit Version 2.11 aus dem Januar 2014 DANE unterstützt, ist dies beispielsweise bei sendmail bislang nicht der Fall. Somit scheidet eine aktive Verwendung von DANE auf dem Instituts-Mailserver momentan aus. Es ist jedoch anzumerken, dass DANE deshalb nicht vollkommen unbenutzbar ist: Schließlich werden die TLSA-Records im DNS(SEC) und damit erst einmal losgelöst von der Serversoftware gespeichert. Nimmt man diese Einträge vor, so lassen sich zumindest eingehende Verbindungen von Clienten und anderen Mailservern absichern, lediglich die aktive Überprüfung beim Verbinden auf andere Mailserver kann dann nicht durchgeführt werden.

===Entwickler===
Auch die Unterstützung in Entwicklertools ist immer noch problematisch. So können '''Analyse-Tools''' wie ''dig'' zwar prinzipiell mit DNSSEC umgehen (Option "+sigchase"), doch sind sie für die Standard-Pakete oft ohne DNSSEC-Unterstützung kompiliert worden, sodass man sie für diesen Zweck erst neukompilieren muss. Interessanterweise galt das auch für das ''danetool'' aus dem gnutls-Entwicklerpaket. Das bloße Vorhandensein des Programms änderte nichts an der Tatsache, dass jeder Aufruf mit dem Hinweis auf fehlende DANE-Unterstützung quittiert wurde. Da diese beiden Tools zum Testen von DNSSEC und DANE beinahe unverzichtbar sind, kommt man um selbstkompilierte Versionen kaum herum. ''openssl'' unterstützt DNSSEC und DANE noch nicht.

Anders sieht es für Software-Entwickler in Sachen '''Libraries''' aus. Es existiert eine Vielzahl an Bibliotheken, mit denen sich DNSSEC- und DANE-Unterstützung in eigenen Applikationen realisieren lässt <ref>http://www.internetsociety.org/deploy360/resources/dnssec-developer-libraries/</ref> <ref>http://www.gnutls.org/manual/html_node/Verifying-a-certificate-using-DANE.html#Verifying-a-certificate-using-DANE</ref>. Diese führen dann die DNSSEC-Verifikation bis zur Root-Zone durch und geben so Aufschluss über die Authentizität einer DNS-Antwort. Ein anderer Weg besteht darin, einem kompletten Resolver wie ''bind''/''named'' oder ''unbound'' diese Überprüfung zu überlassen. Der Resolver setzt in der Antwort dann ein Flag, das das Ergebnis der Überprüfung angibt. Diese Methode ist offenbar nur praktikabel, wenn sowohl der Nameserver als auch der Kommunikationsweg zu ihm vertrauenswürdig sind, also beispielsweise, wenn der Nameserver auf dem lokalen Rechner läuft. Die DANE-Überprüfung ist dann jedoch trotzdem noch zu erledigen.

=Einzelnachweise=
<references/>


==4 Weiterführende Informationen und Quellen==
=Weiterführende Informationen und Quellen=
*RFC 6698
*RFC 6698
*http://www.denic.de/domains/dnssec.html
*http://www.denic.de/domains/dnssec.html

Latest revision as of 09:22, 9 October 2014

Motivation

Bekannt aus den Nachrichten

In den letzten Jahren haben sich vermehrt die Probleme einer herkömmlichen PK-Infrastruktur gezeigt, wie sie für die Sicherung der Kommunikation mittels TLS und x509-Zertifikaten genutzt wird.

Dabei wurden CAs immer wieder dazu gebracht Zertifikate für Unberechtigte auszustellen. Dies geschah oft durch mangelnde Einhaltung ihrer eigenen (vertrauensgebenden) Richtlinien (Policies) oder auch auf Betreiben Krimineller, die sich unberechtigt Zugang verschafften.

siehe auch

Bisherige Ansätze

In der großen weiten Internet-Welt sind verschiedene Konzepte üblich, um Kommunikation mit verschiedenen Sicherheitsbedürfnissen zu realisieren. Ein häufig anzutreffender Ansatz besteht darin, die Kommunikation gänzlich unverschlüsselt durchzuführen. Beispiele hierfür sind unter anderem die ersten Whatsapp-Versionen, Email-Dienste und sehr häufig das Web im Allgemeinen (http). In der Post-Snowden-Ära versteht sich von selbst, dass sich die Sicherheitsbedürfnisse der Endanwender geändert haben. Die gänzlich ungesicherte Kommunikation ist heute oftmals nicht mehr erwünscht. Diverse kommerzielle Anbieter haben die bestehende Verunsicherung der Nutzer genutzt um prestigeträchtige Kampagnen zur Datensicherheit der Kunden zu starten. Ein Beispiel stellt die "Email made in Germany" Initiative dar, deren Mitglieder sich zum verschlüsselten Emailtransfer untereinander verpflichtet haben, dabei wird jedoch nicht auf offene Standards gesetzt, sondern auf proprietäre nicht öffentlich verifizierbare Verfahren. Des Weiteren ist die Mitgliedschaft in dieser Initiative mit nicht unerheblichen finanziellen Verpflichtungen verbunden, so dass eine flächendeckende Verbreitung weder möglich (insbesondere für kleine non-profit Unternehmen), noch erstrebenswert ist.

Wenn eine gesicherte Verbindung gewünscht ist, dann wird oft auf ein PKI-gestützes Vertrauensmodell zurückgegriffen. Dazu wird in allen gängigen Endanwendungen eine Liste mit vertrauenswürdigen CAs, schon bei der Installation, hinterlegt. Die Beziehung zwischen dem im Zertifikat angegebenen Common Name und dem angefragten Host wird über das Domain Name System hergestellt. Dieses weit verbreitete Verfahren birgt jedoch einige Schwachstellen, auf die im weiteren Verlauf eingegangen wird.

Gerade für die Absicherung des Email-Backends könnte man bekannte öffentliche Schlüssel von Remoteservern fest im Mailserver hinterlegen. Dieses Verfahren hat jedoch den gleichen großen Nachteil, wie auch die "Email made in Germany" Initiative: die Skalierbarkeit ist durch den vergleichsweise hohen administrativen Aufwand beschränkt.

Probleme

Ein zentrales Problem in der praktischen Anwendung der heutigen CA-basierten PKI ist das uneingeschränkte Apriori-Vertrauen in jede einzelne der potentiell zahlreichen CAs. So kann jede CA, mangels eines Zuständigkeitskonzepts, für jede beliebige Domain Zertifikate ausstellen, was die Ausnutzbarkeit der zuvor erwähnten Sicherheitsbedenken drastisch erhöht. Das Vertrausmodell mit großen vorgefertigten CA-Listen ist aufgrund seiner opt-out Eigenschaft (allen default CAs wird vertraut, solange ihnen das Vertrauen nicht entzogen wird) potentiell angreifbar (siehe 1.1).

Technische Details

Was ist DANE?

DNS-based authentication of named entities (DANE) ist ein Verfahren zur Absicherung öffentlicher Schlüssel eines Zielservers zum geschützten Datenaustausch mittels TLS. Dazu werden Informationen über den öffentlichen Schlüssel im DNS veröffentlicht. Da DNS Daten nicht authentisch verteilen kann, wird für DANE die DNS-Erweiterung DNSSEC benötigt. Durch die Nutzung von DNSSEC lassen sich kryptographisch verifizierbare Aussagen über die Authentizität der abgefragten Daten treffen.

Funktionsweise DNSSEC

Wie bei anderen PKIs basiert das Vertrauen bei DNSSEC auf dem hierarchischen Aufbau. Bei DNSSEC gibt es jedoch nur einen einzelnen Vertrauensanker, der eine klare Zuständigkeit vorgibt. Es handelt sich dabei um den Schlüssel mit dem die Rootzone signiert wurde (15.07.2010 Rootzone signiert (http://heise.de/-1039401)). Dieser wird von der ICANN in Zusammenarbeit mit VeriSign verwaltet und ist allgemein bekannt.

Zugewinn durch DNSSEC

Durch die Nutzung von DNSSEC erhält man die Validierbarkeit der Auflösung/Zuordnung von Name auf im DNS abgelegte Daten. Dies gilt jedoch nur unter der Annahme, dass die ICANN/VeriSign, sowie die Zwischenzonen vertrauenswürdig sind.

Seit Mai 2011 ist die .de - Zone signiert (http://denic.de/domains/dnssec.html)

Funktionsweise DANE

DANE besteht im Wesentlichen aus einem neu definierten Resource Record für das DNS. Dabei handelt es sich um den sogenannten TLSA Record. Dieser ist wie folgt aufgebaut: 

_PORT._PROTO. domain . t l d . TLSA x y z WERT

x Usage Field
y Selector Field
z Matching-Type Field
WERT sha256 || sha512 || x509

Usage Field
0 einschränken auf CA (PKIX)
1 einschränken auf Zertifikat (PKIX)
2 Vertrauensanker verwenden
3 Zertifikat nutzen

Selector Field
0 ganzes Zertifikat
1 öffentlicher Schlüssel

Matching-Type Field
0 ungehashter Selector
1 sha256
2 sha512

Umsetzung (HowTo)

Versuchsaufbau.png

named/BIND einrichten (DNS)

Rootzone anlegen

. IN SOA prak1. prak1. ( 
                                2014080605 ; serial
                                10800      ; refresh (3 hours)
                                3600       ; retry (1 hour)
                                1209600    ; expire (2 weeks)
                                7200       ; minimum (2 hours)
                                )
.                               NS      prak1.
prak1.                          A       141.20.20.130
itsec.                          NS      itsec.nic.
itsec.nic.                      A       141.20.20.131

Subzone anlegen

itsec. IN SOA itsec.nic. itsec.nic. ( 
                                2014080601 ; serial
                                10800      ; refresh (3 hours)
                                3600       ; retry (1 hour)
                                1209600    ; expire (2 weeks)
                                7200       ; minimum (2 hours)
                                )
itsec.                          NS      itsec.nic.
mail.itsec.                     A       141.20.20.131

DNSSEC einrichten

Schlüssel generieren

dnssec-keygen -a <CIPHERSUITE> -b <BITS> [-f KSK] -n ZONE <ZONENAME>

dnssec-keygen -a RSASHA1 -b 1024 -n ZONE itsec.
dnssec-keygen -a RSASHA1 -b 1024 -f KSK -n ZONE itsec.

Zonen delegieren

dnssec-dsfromkey <KEYFILE>

dnssec-dsfromkey Kitsec.+005+59794.key

Zonen signieren

dnssec-signzone -o <ZONENAME> -t <ZONEFILE>

dnssec-signzone -o itsec. -t db.itsec_root

DANE einrichten (TLSA RR)

_PORT._PROTO. domain . t l d . TLSA x y z WERT

x Usage Field
y Selector Field
z Matching-Type Field
WERT sha256 || sha512 || x509

Usage Field
0 einschränken auf CA (PKIX)
1 einschränken auf Zertifikat (PKIX)
2 Vertrauensanker verwenden
3 Zertifikat nutzen

Selector Field
0 ganzes Zertifikat
1 öffentlicher Schlüssel

Matching-Type Field
0 ungehashter Selector
1 sha256
2 sha512

Beispiel: 

_25._tcp.mail.itsec. IN TLSA 3 0 1 8107bd7ccc81a57cecfafa1ff1c2a107b49b5a32308f70dfe1c9ce53f9732dc2

in diesem Fall lässt sich der Fingerprint mit folgendem Kommando erzeugen: 

openssl x509 -in servercert.pem -noout -fingerprint -sha256 | tr -d ":" | sed 's/SHA256 Fingerprint=//'

Softwareunterstützung

Endanwendungen

Die Unterstützugng von DANE und DNSSEC seitens nutzbarer Endanwendungen ist leider nach wie vor gering. So kann beispielsweise kein aktueller Browser (Stand September 2014) von Hause aus eine DNSSEC-Prüfung vornehmen, geschweige denn TLSA-Records beim TLS-Verbindungsaufbau abgleichen. Es existieren zum Beispiel für Firefox und Chrome entsprechende Plugins, die diese Aufgabe übernehmen können, doch von einer weitreichenden, nutzerfreundlichen Anwendbarkeit kann keine Rede sein. Dasselbe gilt auch für E-Mail-Clienten wie Thunderbird u.ä..

Auf Server-Seite ist die Situation ein wenig besser, wenn auch nicht gravierend. Ein Beispiel dafür sind Mailserver. Während Postfix seit Version 2.11 aus dem Januar 2014 DANE unterstützt, ist dies beispielsweise bei sendmail bislang nicht der Fall. Somit scheidet eine aktive Verwendung von DANE auf dem Instituts-Mailserver momentan aus. Es ist jedoch anzumerken, dass DANE deshalb nicht vollkommen unbenutzbar ist: Schließlich werden die TLSA-Records im DNS(SEC) und damit erst einmal losgelöst von der Serversoftware gespeichert. Nimmt man diese Einträge vor, so lassen sich zumindest eingehende Verbindungen von Clienten und anderen Mailservern absichern, lediglich die aktive Überprüfung beim Verbinden auf andere Mailserver kann dann nicht durchgeführt werden.

Entwickler

Auch die Unterstützung in Entwicklertools ist immer noch problematisch. So können Analyse-Tools wie dig zwar prinzipiell mit DNSSEC umgehen (Option "+sigchase"), doch sind sie für die Standard-Pakete oft ohne DNSSEC-Unterstützung kompiliert worden, sodass man sie für diesen Zweck erst neukompilieren muss. Interessanterweise galt das auch für das danetool aus dem gnutls-Entwicklerpaket. Das bloße Vorhandensein des Programms änderte nichts an der Tatsache, dass jeder Aufruf mit dem Hinweis auf fehlende DANE-Unterstützung quittiert wurde. Da diese beiden Tools zum Testen von DNSSEC und DANE beinahe unverzichtbar sind, kommt man um selbstkompilierte Versionen kaum herum. openssl unterstützt DNSSEC und DANE noch nicht.

Anders sieht es für Software-Entwickler in Sachen Libraries aus. Es existiert eine Vielzahl an Bibliotheken, mit denen sich DNSSEC- und DANE-Unterstützung in eigenen Applikationen realisieren lässt <ref>http://www.internetsociety.org/deploy360/resources/dnssec-developer-libraries/</ref> <ref>http://www.gnutls.org/manual/html_node/Verifying-a-certificate-using-DANE.html#Verifying-a-certificate-using-DANE</ref>. Diese führen dann die DNSSEC-Verifikation bis zur Root-Zone durch und geben so Aufschluss über die Authentizität einer DNS-Antwort. Ein anderer Weg besteht darin, einem kompletten Resolver wie bind/named oder unbound diese Überprüfung zu überlassen. Der Resolver setzt in der Antwort dann ein Flag, das das Ergebnis der Überprüfung angibt. Diese Methode ist offenbar nur praktikabel, wenn sowohl der Nameserver als auch der Kommunikationsweg zu ihm vertrauenswürdig sind, also beispielsweise, wenn der Nameserver auf dem lokalen Rechner läuft. Die DANE-Überprüfung ist dann jedoch trotzdem noch zu erledigen.

Einzelnachweise

<references/>

Weiterführende Informationen und Quellen

Retrieved from "https://sarwiki.informatik.hu-berlin.de/index.php?title=DANE_für_unseren_Mail-Server&oldid=11622"