Login
Newsletter
Werbung

Thema: Mozilla testet weitere Aspekte von DNS über HTTPS

9 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von Potz Blitz am Do, 1. August 2019 um 09:11 #

Ich wende mich mit dieser Frage mal an die Experten in diesem Forum. Ich habe gehört, DoH schütze die Privatsphäre besser als DNS, weil die abgefragten Domainnamen verschlüsselt werden und deshalb nicht vom Serviceprovider oder Hotspot/WLAN-Inhaber abgegriffen werden können. Das ist doch so korrekt, oder?

Weil sich aber oft verschiedene Domains die gleiche IP-Adresse teilen (was eigentlich gut ist, da der Provider die IP-Adressen ja sowieso mitkriegt), muss https beim Verbindungsaufbau den Domainnamen mitschicken (Server Name Identification). Dieser Schritt soll wohl immer noch unverschlüsselt stattfinden, richtig?

Bringt DoH aus Sicht der Privatsphäre dann überhaupt etwas oder ist es zurzeit noch eine Spielwiese für Entwickler?

  • 0
    Von Josef Hahn am Do, 1. August 2019 um 10:21 #

    Ich habe gehört, DoH schütze die Privatsphäre besser als DNS, [...] Das ist doch so korrekt, oder?

    Unter eurer derzeit gängigen - imho etwas übervereinfachten - Sicht der Dinge, dass es da eine handvoll US Mega-Anbieter in irgendeiner Cloud gibt, die grundsätzlich ungetrübt vertrauenswürdig sind und als neutrale Infrastruktur gesehen werden, der man nicht sinnvollerweise mißtrauen kann: Ja. Dann ist das so.

    0
    Von hjb am Do, 1. August 2019 um 12:49 #

    Bei HTTPS werden sämtliche Daten verschlüsselt, was die HTTP-Header mit einschließt. Deshalb kann ja zu jeder IP-Adresse nur ein Schlüssel verwendet werden (pro Port, aber da das normalerweise 443 ist, nur einer). Also kriegt schon mal niemand auf dem ganzen Übertragungsweg mit, welche Adressen angefragt werden.

    • 0
      Von klopskind am Do, 1. August 2019 um 17:08 #

      Ich kenne mich leider wenig aus, aber wie realistisch ist folgendes Angriffsszenario?

      1. DNS-Klient Alice verwendet DoH via Anbieter Bob. Die Inhalte der Verbindung zwischen Alice und Bob sind zwar verschlüsselt, aber bei der Namensauflösung (Anfrage/Auflösung/Anwort) fallen für einen Angriff nützliche Metadaten an: Wer schickt wann wem wie viele wie große Pakete.
      2. Ist nun öffentlich bekannt, dass der Empfänger der Pakete (Bob) ein DoH-Anbieter ist, so wäre der Verkehr auch leicht von anderen Paketen mit HTTPS-Payload zu unterscheiden. Analoges gilt für etwaige Antworten einer Anfrage.
      3. Angenommen Alice löst bei Bob eine Auflösungsanfrage für den Namen David aus, und Bob löst die Anfrage rekursiv auf, z.B. über Carol (andere Anfragen werden im Allgemeinen nicht über Carol aufgelöst). Bob erhält wenig später eine Antwort, die er in eine verschlüsselte Antwort an Alice umverpackt.
      4. Weitere Annahme: Die Verbindung für die rekursive Namensauflösung zwischen Bob und Carol sei unverschlüsselt.
      5. Angreiferin Eve infiltriert das Intranet von Alice (z.B. freies WLAN) und identifiziert die Verbindung zwischen Alice und Bob, z.B. mittels einer erweiterten Suche nach DNS-Paketen im Verkehr von Alice samt einer Liste mit gängigen DoH-Anbietern, die Bob enthält. Eve lauscht den Metadaten jener identifizierten Verbindung zwischen Alice und Bob.
      6. Außerdem lausche Eve den ausgehenden und eingehenden Paketen von Bobs rekursiven DNS-Anfragen. Das sind mit Ausnahme von lokalen oder gepufferten Auflösungen weitaus mehr als zwischen Alice und Bob, aber Sie sind unverschschlüsselt (siehe Punkt 4).
      7. So könnte Eve die Metadaten der Verbindungen zwischen Alice und Bob, sowie zwischen Bob und (bspw.) Carol in hinreichend sichere Korrelation setzen (z.B. anhand der zeitlichen Abfolge und in der jeweiligen Anzahl/Größe der Pakete).
      8. Zusammen mit Punkt 4 kann Eve die Inhalte von Alice Anfragen an Bob und Bobs Antworten an Alice mit großer Sicherheit extrapolieren.
      9. Eve könnte sogar die betreffenden, unverschlüsselten Pakete zwischen Bob und Carol in ihrem Sinne geeignet modifizieren, um Alice anzugreifen.
      10. Der Angriff würde ökonomischer, falls Carol mit Eve kooperiert, z.B. wenn Eve und Carol der selben Partei angehören oder gar das selbe Subjekt bezeichnen.

      Wie realistisch ist dieses Szenario also, insbesondere die Annahmen in Punkt 3, 4, 6 und 7? Wie lösen die derzeitigen DoH-Anbieter auf und was tun Sie gegen solche Angriffsmöglichkeiten? Weiß da jemand mehr?

      Mir ist klar, dass DoH hier nicht die Ursache für die Angreifbarkeit ist, oder das Angriffspotential vergrößert, sondern - im Gegenteil - die Ökonomie eines Angriffs ggü. Klartext-DNS signifikant zu Gunsten von Alice und zu Lasten von Eve verschiebt.

      In dem Sinne ist dies bitte nicht als blinde Kritik an DoH zu verstehen. Ich möchte lediglich verstehen, wie realistisch dieses Szenario mit DoH (im Vergleich zu Klartext-DNS) ist, um einschätzen zu können, wie sinnvoll der Einsatz von DoH ist.
      Danke!

      0
      Von gtrs am Do, 1. August 2019 um 18:57 #

      Das ist so nicht ganz korrekt.

      Der entsprechende Standard heißt "Server Name Indication" (SNI) und ist eine Erweiterung für TLS. Mittels SNI können hinter einem Socket mehrere Zertifikate/Schlüssel für TLS verwendet werden. Damit der Server weiß, welches Zertifikat er nun verwenden soll, wird der Hostname zu Beginn unverschlüsselt übertragen. SNI ist inzwischen ziemlich weit verbreitet.

      Damit ergibt sich eben auch wieder das Privacy-Problem, dass der TE angesprochen hat.

      Um dieses Problem zu lösen, gibt es seit Kurzem "Encrypted Server Name Indication" (ESNI), bei dem wiederum der Hostname für SNI verschlüsselt übertragen wird. Hier stellt sich aber das Problem, dass der Client wissen muss, mit welchem Schlüssel er den Hostnamen verschlüsseln soll. ESNI schlägt dazu einen Eintrag in DNS vor. Dessen Integrität muss dann aber per DNSSEC gesichert sein, damit niemand sich in die erste Phase des Handshakes als Man-in-the-middle einklinken kann, um den Hostname zu belauschen. Leider ist ESNI noch experimentell und hat daher noch keine Verbreitung gefunden.

      0
      Von Verfluchtnochmal_5987109 am Fr, 2. August 2019 um 22:01 #

      Welch unglaublicher Unsinn aus den MSIE6 Zeiten!

      Mal über SNI schlau machen würde einem selbst ernannten Redakteur gut tun! Und ja es gibt Initiativen auch SNI zu verschlüsseln, aber in der praxis nicht existent

Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung