Hi,
On Friday 19 September 2014 14:44:11 Heiko Schlittermann wrote:
Konrad Rosenbaum konrad@silmor.de (Fr 19 Sep 2014 10:36:19 CEST):
Zugegeben, der RFC, der dieses Flag auf DNSSec einschränkt ist 10 Jahre alt - trotzdem gibt es genug Implementationen, die kein DNSSec können.
Ich meine, der verwendete DNSMASQ ist durchaus jünger.
Das mag ein Grund sein, aber ein Hinderniss ist es auch nicht.
Ich hoffe Du wirst entschuldigen dass ich nicht davon schockiert bin - ich bin es (leider) gewohnt immer wieder mit Software zu arbeiten, die 20 Jahre alte Standards nicht korrekt implementiert...
Offensichtlich kann er entweder kein DNSSec oder ist nicht korrekt konfiguriert (oder buggy).
Er kann kein DNSSEC, nur als „Proxy“, dass heisst, er wird auf die Flags vertrauen, die ihm jemand anders schickt. Je nach verwendeter Infrastruktur mag das ok sein.
Aber ich möchte nicht belogen werden! Denn der andere hatte ihm definitiv kein AD geschickt!
Wie gesagt, die alte Interpretation von AD ist: es wurde irgendwie verifiziert - nicht zwingend kryptographisch.
Ich halte das AD Flag für reichlich zweifelhaft - genausogut kann man sich auch darauf verlassen dass gefälschte DNS-RRs das Evil-Bit gesetzt haben.
Ansonsten gilt: wer auf Flags eines Programms am anderen Ende einer Socket vertraut ist selbst schuld.
Ja, jedoch würde ich bei einer Verbindung zu 127.0.0.1 erstmal von etwas mehr Vertrauenswürdigkeit ausgehen … (Ja, ich weiss, wenn ich 100% sicher sein möchte, dann muss ich selbst validieren. Aber das war nicht der Punkt.)
Nur wenn das System am anderen Ende auch das gewünschte Feature (DNSSec) beherrscht. Da das nicht der Fall ist, kann man sich nicht auf AD verlassen.
Der Punkt war: Wie gefährlich ist dieses Verhalten des DNSMASQ? Ist das ein GRAVE Sicherheitsproblem? Oder MINOR? Oder nichts von beidem?
MINOR/SUSPICOUS: setzt ein Flag welches es nicht versteht. Eigentlich müsste es konsequent das AD-Flag löschen, weil es die Grundlagen dahinter nicht versteht und damit das Flag auch nicht verifizieren kann.
Konrad