DANE für unseren Mail-Server: Difference between revisions
(Softwareunterstützung) |
|||
| (3 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
=Motivation= |
=Motivation= |
||
===Bekannt aus den Nachrichten=== |
===Bekannt aus den Nachrichten=== |
||
In den letzten Jahren haben sich vermehrt die Probleme einer |
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 |
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''' |
'''siehe auch''' |
||
| Line 11: | Line 11: | ||
===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 |
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 33: | Line 33: | ||
===Funktionsweise DANE=== |
===Funktionsweise DANE=== |
||
DANE besteht im |
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 123: | Line 123: | ||
in diesem Fall lässt sich der Fingerprint mit folgendem Kommando erzeugen: |
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> |
<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/> |
|||
=Weiterführende Informationen und Quellen= |
=Weiterführende Informationen und Quellen= |
||
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)
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/>