ob die Verbindung zu eine Website „sicher“ ist kann man in Firefox an dem kleine Schloss links neben der URL erkennen.
Darüber hinaus gab es für Firefox mal ein Addon um DNSSEC zu nutzen. Das Addon finde ich nicht mehr. Gibt es die Technik noch? Gibt es dazu auch noch Addons oder ist das jetzt schon ein Teil von Firefox? Wenn ja, fließt das dann schon in die Bewertung von dem Schloss Symbol ein?
Das habe ich auch gesehen, aber das war nicht das Addon, das ich beim letzten Mal verwendet hatte. Dieses hier wurde auch zuletzt vor 6 Jahren aktualisiert.
Seit sich https für Webseiten durchgesetzt hat, ist da DNSSEC nicht sooo wichtig, denn die Identität wird auch über das Zertifikat der Webseite geprüft. Anders ist das z.B. bei Mail oder Key-Management, da sind Indirektionen dabei die nur mit DNSSEC sicher sind.
@Daniel Du meinst wahrscheinlich das Add-on „DNSSEC/TLSA Validator“ https://dnssec-validator.cz/ um die TLS Zertifikate via DANE Record aus dem DNS zu validieren. DNSSEC ist Bestandteil von DANE/TLSA
ich würde eher sagen, DNSSEC ist Voraussetzung für DANE/TLSA, und weil sich DNSSEC zu wenig durchgesetzt hat, wird DANE/TLSA auch selten eingesetzt (meine Wahrnehmung nur bei Email und da auch von zu wenigen).
Du meinst abe nicht das frühere grüne Schloss für verschlüsselte Verbindung und vertrauenswürdiges Zertifikat? 99,9% der Anwender wussten nicht was das bedeutet… hat nix mit DNSSEC zu tun.
Oder in einem speziellen Anzeigebereich eines Plugins?
Es gibt im Internet zwei Vertrauensanker: die üblicherweise vertrauenswürdigen Zertifikate (u.a. auch Letsencrypt) und eben DNSSEC.
Je nach Anwendung ist mal das eine, mal das andere dominierend, manchmal beides wichtig.
Die Firmen/Organisationen dahinter überlappen sich meines Wissens und die USA dominieren beides (bei DNS m.W. stärker als bei den Zertifikaten, zumal die EU da ja gerade wieder aktiv war, und eher zum Nachteil der Bürger).
Frage ist halt immer was will man erreichen und wem vertraut man.
Es stellt sich erst mal die Frage, was „echt“ überhaupt bedeuten soll. „Echt“ ist jede Website, sonst könntest du sie nicht aufrufen.
Was macht denn überhaupt DNSSEC? Mit DNSSEC werden DNS-Antworten signiert, sodass sie nicht verfälscht werden können. Wenn du also www.kuketz-forum.de aufrufst, stellt dein System erst mal eine DNS-Anfrage und bekommt die IP-Adresse 45.9.61.217 zurück. Ein böswilliger Mensch könnte die Antwort auf dem Weg vom DNS-Server zu dir verfälschen und dich so umleiten. Dann rufst du eine Webseite auf, die du nicht aufrufen wolltest.
Wenn der für www.kuketz-forum.de zuständige DNS-Server die Antworten signiert, kann das nicht passieren - sofern dein System die Signatur prüft.
Hat allerdings ein böswilliger Mensch eine Webseite unter dem Namen www.kukez-forum.de (beachte das fehlende t im Namen), und du klickst auf einen entsprechenden Link, hilft DNSSEC nicht weiter. Denn auch kukez-forum.de kann eine gültige Signatur tragen und du erhältst genau die Webseite, die du per Link aufgerufen hast. Dagegen hilft keine Technik, sondern nur menschliche Aufmerksamkeit.
Möglicherweise verstehst du jetzt, was ich mit meiner Eingangsfrage sagen wollte.
Abschließend noch die Frage: Was wahrscheinlicher? Du fällst einem falschen Link zum Opfer (z. B. in einer sehr gut gemachten Phishing Mail) oder jemand manipuliert DNS-Antworten auf dem Weg zu dir. Letzteres ist ein sehr gezielter Angriff, für den man schon einige Hürden überwinden muss. Der erste Angriff findet täglich millionenfach statt und scheint immer noch eine gewissen Erfolgsquote zu haben.
Zum Addon: Das kenne ich nicht. Aber die Technik, DNSSEC, gibt es durchaus noch, ist aber nach meinem Überblick nur wenig verbreitet. Das Schloss symbolisiert nur, dass die Webseite, die du aufgerufen hast, ein gültiges Zertifikat hat. Du hast also den Server erreicht, den Du aufgerufen hast. Die Daten werden verschlüsselt übertragen und sind vor Manipulation geschützt. Mehr sagt das Schloss nicht aus, und genau das ist mit „sicher“ gemeint. Aber auch betrügerische Webseiten können ein Zertifikat haben. Schließlich ist das Zertifikat allenfalls ein Ausweis. Damit weist du nach, dass du der aufgerufenen Kommunikationspartner bist. Eine Prüfung auf kriminelle Machenschaften ist nicht die Aufgabe von Zertifizierungsstellen. So etwas kann sich ja auch während der Zertifikatslaufzeit jederzeit ändern. Wenn also jemand z. B. unter dem Namen amazzon.de auf Beutezug geht, bekommt er problemlos ein Zertifikat. Denn er kann problemlos nachweisen, dass er der Administrator von amazzon.de de. Auch markenrechtlliche Aspekte spielen keine Rolle bei der Ausstellung von Zertifikaten.
DNS dient auch für andere Informationen als Nachschlagewerk, Fingerprints zu (TLS,SSH), unterstützten Protokollen HTTPS zum Beispiel , theoretisch auch PGP und SMIME Zertifikaten und vieles andere wie auch Schlüsselmaterial für EncryptedClientHello.
Wenn da keiner manipulieren kann und diese Daten ausfiltern, werden sie deutlich nützlicher.
Ich sehe nicht, wo DNSSEC bei E-Mail Vorteile haben könnte. Die Mails werden per TLS gesichert zwischen Client und Mailserver ausgetauscht. Natürlich findet hier auch eine Zertifikatsprüfung statt. Ob du jetzt für Mail IMAP, POP3 bzw. SMTP über TLS versendest, oder aber HTTP über TLS, ist aus Sicht der Kryptografie kein Unterschied.
Anhand eines anderen Kommentars habe ich eine gewissen Vorstellung, was du mit „Key Management“ meinst. Sofern du dich auf ESNI bzw. ECH beziehst: DNSSEC ist hier nicht sonderlich hilfreich, weil DNSSEC die DNS-Anfrage im Klartext übermittelt. Die Vertraulichkeit, die du mit ESNI oder ECH erreichen möchtest, konterkarierst du mit DNSSEC. Hier müssen dann DNS over TLS (vorzugsweise) oder DNS over HTTP her. Damit hast du Verschlüsselung und auch gleich die Integrität gesichert.
Damit sich kein Man-in-the-Middle zwischen Client und Mailserver einschleichen kann, veröffentlicht der gute Mailprovider die Fingerprints seiner gültigen Zertifikate als DANE/TLSA Records im DNS, was wiederum via DNSSEC abgesichert werden muss.
Nachdem ihr hier lang und breit über den (für einige fragwürdigen) Sinn von DNSSEC diskutiert habt, könnten wir langsam mal zu Thema des Thread Openers kommen und über DANE/TLSA diskutieren? Das ist es nämlich, was das Add-on validiert hat, nach dem der TO gefragt hat.
Ich kenne keinen Ersatz für das Add-on, aber da die EU mit der eIDAS-Verordnung plant, die Browserhersteller zu zwingen, verodnete CAs der EU zwingend zu akzeptieren und zu diesen EU-CAs mit Utimaco auch ein Hersteller von Überwachungstechnik gehört, wird die Validierung der TLS Zertifikate wieder wichtiger.
Auf die CAs als sogenannte „Vertrauensanker“ können wir uns in Zukunft noch weniger verlassen als als heute. Und die EFF hatte schon 2009 geschrieben, dass staatliche Überwacher TLS Zertifikate mit einer gültiger CA faken können, wenn sich sich als Man-in-the-Middle einschleichen wollen. Wir müssen Zertifikate besser validieren, einfach nur „TLS verschlüsselt ist Ok“ gilt nicht mehr.
Wenn du DANE meinst: Ja, theoretisch. Die Verbreitung von DANE ist allerdings eher homoöpatisch, wenn ich das richtig im Überblick habe. Aber klar, DANE ohne DNSSEC ist witzlos. Einige Maildienste und Mailserver-Implementierungen unterstützen das, Browser hingegen nicht.
ECH ist bei Verwendung von DNSSEC witzlos. ECH soll die Vertraulichkeit erhöhen, damit der aufgerufene Server nicht erkennbar ist. Wenn man die DNS-Anfrage im Klartext übermittelt, hat man nichts gewonnen. DNSSEC ist jedoch Klartext. ECH muss man mit DNS over TLS oder alternativ mit DNS over HTTPS kombinieren. Nur dann ergibt es Sinn.
reicht halt nicht, weil der MX über das DNS kommt, und ohne DNSSEC kann der MX ausgetauscht werden. Dann nützt das Zertifikat rein gar nichts, zumal es ohne SMTP-DANE nicht validiert wird. Für mich ist DANE (und auch DKIM) daher auch ein Beispiel für Key-Management das DNSSEC voraussetzt oder davon profitiert.
Man kann DNSSEC auch über DoT/DoH verwenden. Richtig ist allerdings, dass ein lokaler rekursiver Resolver wie unbound Privatsphäre verhindert. Wer einen eigenen Mailserver betreibt kommt aber kaum ohne aus, immerhin beim Surfen geht es.
Damit sich eine Person in the Middle zwischen Client und Server einschleichen kann (dabei ist es egal, ob es sich um einen Webserver, einen Mailserver oder irgend etwas anderes handelt), muss die Person in the Middle ein vom Client als gültig erkanntes Zertifikat samt privatem Schlüssel vorweisen können. Das funktioniert nur, wenn der Client der Person in the Middle vertraut, was regelmäßig nicht der Fall ist. Alternativ ist die Person in the Middle ein staatlicher Angreifer. Der staatliche Angreifer, der in der Lage ist ein Zertifikat derart zu fälschen, kann auch das DNS manipulieren. Ich bin der Auffassung, dass gegen staatliche Angreifer kein Kraut gewachsen ist.
Wenn du das original Zertifikat über DNSSec und Certificate Transparency zusätzlich validieren kannst, wird es schwieriger unendeckt zu bleiben.
Mehr Kanäle die du ändern müsstest.
Ich kann auch als Dienst Betreiber die Transparenz Logs prüfen und die DNS Anfrage zu meiner Seite und du kannst bei DNSSEC nicht eine Information nur für eine Person manipulieren. Die ganze Zone muss manipuliert werden und wenn das Ziel einen anderen Resolver nutzt muss sie auch dort sabotiert ankommen.
Damit steigt der Aufwand und das Risiko von jemand dabei ertappt zu werden.
Wir haben DNSSEC um vertrauenswürdige Antworten zu kommen.
DOT&DOH&CO um diese vertrauenswürdigen Antworten vor Aussenstehenden zu verbergen.
Du willst beides. DNSSec schützt vor den Resolvern und vor Leuten die zwischen Resolvern & Quelle sitzen. Die Kette ist noch nicht komplett verschlüsselt.
