DANE für unseren Mail-Server: Difference between revisions
| 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''' |
||
Revision as of 08:08, 8 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 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.
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=//'