Ein Artikel auf Golem erweckt den Eindruck, dass DANE ein Luftschloss sei und schon vor dem Start gescheitert wäre. Der Autor bezieht sich dabei auf die verschiedenen Einschränkungen beim Einsatz zwischen Browser und WebServer im Rahmen einer HTTPS-Verbindung. Diese Probleme sind zwar nachvollziehbar aber nur ein Teilaspekt von DANE. DANE ist ein sicherer Weg, mit dem der Initiator einer Verbindung zu einer Gegenstelle sicherstellen kann, dass er wirklich das gewünschte Ziel mit dem korrekt ausgewiesenen Zertifikat erreicht hat. Sehr interessant ist der Einsatz
von DANE dabei bei Verbindungen zwischen Maschinen, die nicht mit den Einschränkungen und Einflüssen eines Browsers, Clients oder Anwenders umgehen müssen. So kommunizieren beim „Internet der Dinge“ in den seltensten Fällen Menschen mit Maschinen. Am Beispiel der Mailübertragung per SMTP lässt sich der Vorteil von DANE sehr einfach erläutern.
Seit vielen Jahren können Mailserver Nachrichten per TLS auf dem Transport verschlüsseln. Die meisten Mailserver wie z.B. Exchange oder NoSpamProxy richten zu diesem Zweck während der Installation sogar ein selbst erzeugtes Zertifikat ein. Beim Versand einer E-Mail bietet der empfangende Server „STARTTLS“ an und der sendende Server kann die Verbindung verschlüsseln. Selbst ein nicht vertrauenswürdiges oder gar abgelaufenes Zertifikat beim Empfänger ist immer noch besser als ein Versand per Klartext. Die meisten Mailserver verfahren dabei genau so. Aber dieses Verhalten schützt nicht gegen „Man in the Middle“-Attacken, in denen ein Angreifer den „STARTTLS“-Befehl entweder komplett unterdrückt oder ein eigenes Zertifikat einschmuggelt. Hier kommt DANE ins Spiel. Der Administrator des empfangenden E-Mail-Servers veröffentlicht über entsprechende DNS-Einträge die Information, dass er nicht nur ein Zertifikat hat, sondern auch welches Zertifikat. Dazu wird der Fingerprint des PublicKeys verwendet, den der einliefernde Server zu erwarten hat. Damit diese Informationen unverfälscht bereitgestellt werden können, ist DNSSEC zwingend erforderlich. Zudem muss der absendende Mailserver natürlich einen eigenen DNSSEC-Resolver unterstützen. Das ist aber bei Mailservern ein überschaubarer Aufwand und nicht mit den Millionen PCs mit Anwendern und Browsern zu verwechseln.
So kann ein entsprechend ausgerüsteter Mailserver sicherstellen, bei einer Verbindung zu seinem Partner zum einen den richtigen Partner erreicht zu haben und zusätzlich eine verschlüsselte Verbindung erstellen zu können.
So wie absendende Server heute schon einen SPF-Record eintragen, ist es mit DNSSEC und DANE nur ein paar Klicks mehr um das verwendete Zertifikat bekannt zu machen. Das Zertifikat muss nicht einmal von einer „Trusted CA.“ ausgestellt sein, die in der Vergangenheit auch immer mal Zertifikate zu Unrecht ausgestellt habe. Der Empfänger muss nur ein eigenes Zertifikat installieren, per DNS veröffentlichen und bei ausgehenden Verbindungen das Zertifikat der Gegenseite überprüfen.
NoSpamProxy wird diese Technologie noch in diesem Jahr voll umfänglich unterstützen. Die Domäne nospamproxy.de ist heute schon mit DANE abgesichert, wie man dem folgenden Screenshot entnehmen kann:
