DANE für unseren Mail-Server - Revision history

Doepmanc: Softwareunterstützung

2014-10-09T09:22:13Z

Softwareunterstützung

@@ Line 123: / Line 123: @@
 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>
 =Weiterführende Informationen und Quellen=

Wolfm: /* Funktionsweise DANE */

2014-10-08T08:12:11Z

Funktionsweise DANE

← Older revision		Revision as of 08:12, 8 October 2014
Line 33:		Line 33:

	===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

Wolfm: /* Bisherige Ansätze */

2014-10-08T08:10:44Z

Bisherige Ansätze

← Older revision		Revision as of 08:10, 8 October 2014
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 ~~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.

Wolfm: /* Bekannt aus den Nachrichten */

2014-10-08T08:08:16Z

Bekannt aus den Nachrichten

← Older revision		Revision as of 08:08, 8 October 2014
Line 1:		Line 1:
	=Motivation=		=Motivation=
	===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.

	'''siehe auch'''		'''siehe auch'''

Sven: /* Motivation */

2014-10-06T13:16:21Z

Motivation

← Older revision		Revision as of 13:16, 6 October 2014
Line 5:		Line 5:
	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.

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

Sven at 13:15, 6 October 2014

2014-10-06T13:15:10Z

← Older revision		Revision as of 13:15, 6 October 2014
Line 1:		Line 1:
	==Motivation==		=Motivation=
	===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ömlichen PK-Infrastruktur gezeigt, wie sie für die Sicherung der Kommunikation mittels TLS und x509 Zertifikaten genutzt wird.
Line 20:		Line 20:
	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).

	==Technische Details==		=Technische Details=
	===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.
Line 57:		Line 57:
	2 sha512</pre>		2 sha512</pre>

	==Umsetzung (HowTo)==		=Umsetzung (HowTo)=
	[[File:Versuchsaufbau.png]]		[[File:Versuchsaufbau.png]]
	===named/BIND einrichten (DNS)===		===named/BIND einrichten (DNS)===
Line 124:		Line 124:
	<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>

	==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

Sven at 13:13, 6 October 2014

2014-10-06T13:13:48Z

← Older revision		Revision as of 13:13, 6 October 2014
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ömlichen 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 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.

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:

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 124:		Line 124:
	<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>

	==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

Sven: /* 3 Umsetzung (HowTo) */

2014-10-06T13:03:21Z

3 Umsetzung (HowTo)

← Older revision		Revision as of 13:03, 6 October 2014
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>

	==4 Weiterführende Informationen und Quellen==		==4 Weiterführende Informationen und Quellen==

Sven: /* 3 Umsetzung (HowTo) */

2014-10-06T12:52:24Z

3 Umsetzung (HowTo)

@@ Line 58: / Line 58: @@
 ==3 Umsetzung (HowTo)==
 ==4 Weiterführende Informationen und Quellen==
 *RFC 6698

Sven at 12:28, 6 October 2014

2014-10-06T12:28:34Z

← Older revision		Revision as of 12:28, 6 October 2014
Line 34:		Line 34:
	===2.4 Funktionsweise DANE===		===2.4 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

			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>

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