[solved] DNSSEC im Browser, wie validieren

[ingo2]

Bis vor ca. ein paar Wochen funktionierte das AddOn "DNSSEC/TLSA-Validator 2.2.0.4" von CZ.NIC im Browser (Firefox-esr 52.9 und PaleMoon) einwandfrei. Eine schöne Testsite dafür ist z.B. bund.de. Jetzt sehe ich nur noch rot(te Icons) in der URL-Zeile. Ich bin sicher, dass der Fehler auch schon vor dem Roll-over des DNS-Root-Zertifikats am 11.01.2018 aufgetreten ist.

Ich nutze im Heimnetz einen TRR (trusted recursive resolver) auf einem APU2-Board mit unbound. Der dort hinterlegte root.key und root.hints sind aktuell. Das kann man testen mit

Code: Alles auswählen

unbound-anchor -v
/var/lib/unbound/root.key has content
success: the anchor is ok

und mit dig erscheint das Flag "ad", also auch ok.

Code: Alles auswählen

dig @localhost dnssec.works
;; flags: qr rd ra ad; QUERY .... -> ok.

Ob allerdings auch eine Validierung der DNS-Antworten erfolgt, kann ich nicht mehr prüfen. Es gibt zwar eine Web-site https://dnssec.vs.uni-due.de/, deren Test besagt "Yes, your DNS resolver validates DNSSEC signatures.", wie sie das feststellt, ist mir nicht klar.

Habe mir dann noch auf dem PC {deb]ldnsutils[/deb] installiert und unter Stretch den aktuellen root.key von sid vom 30.01.2018 mit dns-root-data installiert. Damit kann ich unabhängig von meinem unbound verifizieren, z.B. mit

Code: Alles auswählen

drill -DT -k /usr/share/dns/root.key bund.de

erhalte ich die Info, dass die Domain signiert ist und auch vertrauenswürdig wie der root.key, also verifiziert wird. Ohne explizite Angabe des root.key's kann Stretch das nicht verifizieren, sagt nur "signiert" (wie das ad-Flag mit dig).
Wie gesagt, vorher hat der DNSSEC/TLSA-Validator das korrekt gemacht, nur seit ein paar Wochen nicht mehr.
Ich vermute also, das das AddOn noch den alten root.key enthält. Wird aber nicht mehr gepflefgt und ist mit FF >v57 nicht kompatibel.

Ich finde die Validierung wirklich wichtig, zumal Mozilla mit DoH ja plant, die DNS-Auflösung des Systems zu umgehen/überlisten. Hat da jemand noch Ideen, wie man das im Browser noch sinnvoll überprüfen kann?

Dem einzigen, dem ich momentan noch trauen kann, ist mein TRR mit unbound - solange der alles richtig macht.

Beste Grüße,
Ingo

[BenutzerGa4gooPh]

Ich nehme mal an, du weißt, wie du deinen eigenen Forwarder/Resolver und DNSSEC per Terminal testest, also für Mitleser:

Code: Alles auswählen

service networking restart (lokalen DNS-Cache leeren)
dig +dnssec +multi google.com
dig +dnssec +multi debian.org

Nur letztes Kommando zeigt eine Authority und eine Additional Section. Ohne explizite Angabe eines DNS-Servers im dig-Kommando wird der im OS konfigurierte benutzt, oft der per DHCP publizierte. Ich nutze pfSense mit unbound (Resolver).

DNSSEC-fähige und "unfähige" öffentliche DNS-Server: https://wiki.ipfire.org/dns/public-servers
Vergleichen/testen (obige Kommandos für eigenen DNS):

Code: Alles auswählen

service networking restart
dig @8.26.56.26 +dnssec +multi google.com
dig @8.26.56.26 +dnssec +multi debian.org
service networking restart
dig @89.233.43.71 +dnssec +multi google.com
dig @89.233.43.71 +dnssec +multi debian.org

89.233.43.71 lt. Link validierend, 8.26.56.26 nicht.

Als Ersatz für das genannte FF-Plugin hab ich nichts gefunden, evtl. dnssec-trigger (ungetestet), wenn es funktioniert (obige Tests), dann wahrscheinlich nicht nur für FF - und vmtl. nur für FF ohne DNS over HTTPS als Bypass.

Dnssec-trigger reconfigures the local unbound DNS server. This unbound DNS server performs DNSSEC validation, but dnssec-trigger will signal it to use the DHCP obtained forwarders if possible, and fallback to doing its own AUTH queries if that fails, and if that fails prompt the user via dnssec-trigger-applet the option to go with insecure DNS only.

https://packages.debian.org/stretch/dnssec-trigger
https://wiki.debian.org/DNSSEC#dnssec-trigger (unbound erfordert auch etwas Konfiguration)

Testplan erstellt. Da ich pfSense mit unbound nutze, würde mir dnssec-trigger derzeit unerwünscht noch einen lokalen unbound auf dem Lappi installieren.

Edit: Abfrage für nachfolgenden Test-Host ist wohl für einen "Reaktionstest" bei "broken dnssec" ungeeeignet, auch von einem nicht validierenden DNS kommt keine Answer Section:

Code: Alles auswählen

dig @8.26.56.26 +dnssec +multi www.dnssec-failed.org

; <<>> DiG 9.10.3-P4-Debian <<>> @8.26.56.26 +dnssec +multi www.dnssec-failed.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 20306
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.dnssec-failed.org.	IN A

;; Query time: 827 msec
;; SERVER: 8.26.56.26#53(8.26.56.26)
;; WHEN: Mon Oct 15 12:56:08 CEST 2018
;; MSG SIZE  rcvd: 50

https://docs.menandmice.com/display/MM/ ... validation
Hhmm, wünschenswert für einen "Reaktionstest" eines lokalen Tools wäre m. E. ein A-Record von einem nichtvalidierenden DNS-Server bei "broken dnssec". Ob google.com geeignet ist? Mit welchen Broken-DNSEC-Websites (eher Hostnamen) hast du früher das FF-Plugin verifiziert bzw. wo hat das Plugin "gemeckert"?

[ingo2]

Hi Jana,

Danke für deine ausführliche Info. Habe inzwischen auch weitere Möglichkeiten gefunden, um meinen unbound-resolver zu testen:
https://en.internet.nl/connection/
http://www.dnssec-or-not.org/
http://dnssec.vs.uni-due.de/
https://docs.menandmice.com/display/MM/ ... validation
Alle Tests sagen ok., aber mir ist absolut nicht klar, wie die feststellen wollen, wie ich meine DNS-Auflösung gemacht habe?

Ok, aber auch auf der Komandozeile mit dig und drill sieht alles gut aus.
Mindestens genau so wichtig ist natürlich das Verhalten von unbound und beim Browser bei fehlerhafter Signatur.
unbound verhält sich da korrekt und antwortet:

Code: Alles auswählen

dig www.dnssec-failed.org
...
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 21263
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

und liefert keine IP-Adresse aus.
Auch in PaleMoon kann man die Site aufrufen und erhält ein "Server nicht gefunden" - korrekt!
Gegenprobe mit dem DNS-Server in meiner FritzBox (da hängt z.B. ein Tablett dran) erscheint die Comcast-Site!

So, aber jetzt das Größte:
mein AddOn DNSSEC/TLSA-Validator lebt wieder!

Es war tatsächlich der ungültige root.key und es gibt dazu sogar einen Bug-Report:
https://gitlab.labs.nic.cz/labs/dnssec- ... /issues/77

Ich habe dann "the dirty way" einfach die binären C-Bibliotheken

Code: Alles auswählen

libDNSSECcore-Linux-x86_64.so
libDANEcore-Linux-x86_64.so

in einen Hex-Editor geladen, den alten Key (in Wirklichkeit nur dessen Hash) gesucht und durch den neuen Hash ersetzt.
Die Hashes findet man auch im dns-root-data in der root.ds.

Und siehe da, mein DNSSEC-Validator-AddOn tut wieder brav seinen Dienst.
Hier für Interessierte noch die root.key Hashes:

Code: Alles auswählen

old key
. IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
new key:
. IN DS 20326 8 2 E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D

Wenn Jemand die gepatchten Lib's für amd64 haben möchte, ich sende sie gerne per PM zu. Ist zwar nicht der saubere Debian-way aus den Sourcen, aber ist eh' ein Fremdpaket

Ingo

[BenutzerGa4gooPh]

Hallo Ingo, mojn neigierdsche Mitleser!

Danke für deine ausführliche Info. Habe inzwischen auch weitere Möglichkeiten gefunden, um meinen Debianunbound-resolver zu testen:
https://en.internet.nl/connection/
http://www.dnssec-or-not.org/
http://dnssec.vs.uni-due.de/
https://docs.menandmice.com/display/MM/ ... validation
Alle Tests sagen ok., aber mir ist absolut nicht klar, wie die feststellen wollen, wie ich meine DNS-Auflösung gemacht habe?

Einige Seiten geben gar keine Auskunft darüber - aber eine doch:

IPv4 connection (via DNS) close
Verdict:

You are able to reach computers via DNS on their IPv4 address.
Test explanation:

We check if your device through its current internet connection is able to connect to our webserver via IPv4. For this test we provide a domain name and we expect your resolver to resolve the domain name to the appropriate IPv4 address.

Requirement level: Optional
Technical details:
IPv4 address Reverse name Internet provider
XXX.XXX.XXX.XXX XXXXXXX XXXXXXXXXXX

DNSSEC validation close
Verdict:

You are protected by DNSSEC signature validation.
Test explanation:

We check if the resolvers that you use validate the DNSSEC signatures of our domain name. Resolvers are usually provided by your internet provider. Alternatively you can configure resolvers from another DNS provider. You can even use your own locally installed resolver. Although validation is done in the resolver, the communication from the resolver back to your device (referred to as ‘last mile’) could still be tampered with by an attacker. Thus the most secure way is to validate close to the end user device (e.g. by using a locally installed resolver), or make sure that the channel between your resolver and your end user device is secured/trusted.
Technical details:
DNS provider
<Mein Provider>

https://en.internet.nl/connection/
Bei den "XXX" werden Angaben zu dem Netz meines Providers angezeigt. Vmtl. wird davon ausgegangen, dass der DNSSEC-Tester den DNS-Server seines ISP benutzt. Und den können externe Leute durchaus testen, nachdem sie meine öffentliche Quelladresse (nach NAT, also eine mir zugeteilte öffentl. IP des Providers) "sehen". Oder die Websites machen so was wie dein FF-Addon? Jedenfalls habe ich kein Vertrauen zu Testmethoden, die nicht genannt werden. Die obige Testmethode wäre nämlich für den A* - sobald Leute nicht den DNS des ISP nutzen.

Gerade gefunden:

Code: Alles auswählen

www.dnssec-failed.org

Die rekursive Namensauflösung kann man hier sehen: https://dnslookup.org/www.dnssec-failed ... delegation
Ein A-Record ist vorhanden, also m. E. für Test des DNSSEC-Wachhundes und Resolver/unbound geeignet. Zumindest einige öffentl. DNS liefern von sich aus dafür schon keinen A-Record aus, selbst der nachfolgende (oben getestete) nicht:

Code: Alles auswählen

dig @8.26.56.26 +dnssec +multi www.dnssec-failed.org

Unser unbound (als validierender, rekursiver Resolver) auch nicht:

Code: Alles auswählen

ping www.dnssec-failed.org
ping: www.dnssec-failed.org: Temporärer Fehler bei der Namensauflösung
ausführlich:
dig  +dnssec +multi www.dnssec-failed.org

Und siehe da, mein DNSSEC-Validator-AddOn tut wieder brav seinen Dienst.

Das ist schön für dich, vielleicht hilft deine Methode auch anderen.

Aber mit den unbound-Tests stellt sich die Frage nach dem Sinn eines 2. Wachhundes, kommt offenbar eh kein A-Record bei broken dnssec. Leute mit DNS-Forwardern sollten einen validierenden öffentlichen DNS-Server und DNS over TLS dorthin nutzen. Wirkt dann systemweit und nicht nur im FF. Oder den des ISP auf mal auf DNSSEC testen, da ist der Weg nicht so lang für Fälschungen von DNS-AWs ohne Verschlüsselung auf der Last Mile. DNSSEC-Antworten an Clients sind da wohl auch nicht sooo wichtig, DNSSEC-Validierung des Servers selber und Weglassen des A-Records in DNS-AWs schon. Also wie unser unbound tut.

Was macht eigentlich dein Addon bei Treffern von uBlockOrigin (= veränderte DNS-Antwort)? Wohl nichts. Dann stellt stellt sich die Frage, wo so ein DNSSEC-Addon ansetzt. Schadsoftware könnte an der gleichen Stelle wie uBlock Origin im FF ansetzen.

Hier wird auch dnssec-trigger empfohlen: http://dnssec.vs.uni-due.de/
Ein dafür lokal installierter unbound stört nicht, den kann man auch als Forwarder auf den lokalen, zentralen DNS konfigurieren.
Validierung von DNSSEC trotzdem möglich. Systemweite Wirkung. Alles theoretisch, ungetestet.

Zuletzt spricht dein notwendiger "Würgdrumherum" nicht gerade für aktives Qualitätsmanagement der Entwickler einer Sicherheitssoftware: Der Schlüsselwechsel wurde medial doch etwas "breitgetreten" - vor allem aber laaange bekannt. Na ja, FF-Addons ... weniger = mehr.

Mir persönlich genügt die Validierung des zentralen unbound und bei broken dnssec Weglassen des A-Records. Wie oben getestet.

[ingo2]

Update

Ich habe den Entwickler des AddOns angeschrieben und um ein Update gebeten - und das gibt's inzwischen wirklich, aber nur als inoffiziellen Build und für Linux nur in der amd64-Version:
https://secure.nic.cz/files/dnssec-vali ... x86_64.xpi

Der Vollständigkeit halber die komplette Info dazu:

Hello Ingo,

I am sorry but the add-on is no longer actively developed and supported.
We released last packages for several browser last week where problem
with root key was solved. Here is link for latest packages
https://secure.nic.cz/files/dnssec-validator/2.2.0.5/

More info about add-on support is available on the web page
https://www.dnssec-validator.cz/.

If you want to build the extension for Linux itself, here is a
description, how to compile it:
https://gitlab.labs.nic.cz/labs/dnssec- ... ompilation

Best regards

Martin Straka

Übrigens: bei der Gelegenheit wurde auch die integrierte OpenSSL-Version von 1.0.2k -> 1.0.2p upgedatet.
s. https://gitlab.labs.nic.cz/labs/dnssec- ... its/master

Der Buid läßt sich auch in Firefox 52.9 (Debian Buster) installieren, wenn man das Überprüfen der "Mozilla-Signatur" abschaltet (die fehlt natürlich dem Build):

Code: Alles auswählen

about:config
ipinstall.signatures.required   true -> false

PaleMoon hat das per default deaktiviert.

Das mit dem "dirty way" habe ich daraufhin wieder aus dem Titel entfernt

NACHTRAG:
Ich selbst benutze einen lokalen validierenden Resolver und das AddOn nur zur Kontrolle, welche Websites DNSSEC unterstützen. Aber für User ohne einen solchen ist das doch ein nützliches Sicherheits-Tool (nutzt übrigens intern auch unbound für DNSSEC