Verbesserung des Datenschutzes mit neuen Protokollen und Edge-Infrastruktur

Heutzutage verlangen alle, dass Kryptografie zur Sicherung der Kommunikation und zur Verbesserung der Privatsphäre eingesetzt wird. Einen neuen Web-Service ohne HTTPS zu starten ist mittlerweile undenkbar. Es ist auch üblich geworden, Direktnachrichten mit einer internetbasierten End-to-End-Verschlüsselung zu versenden, um dem Missbrauch durch Spionage und Phishing bei herkömmlichen SMS, E-Mails und Sprachanrufen entgegenzuwirken. Selbst ein so großes Datenerfassungsprojekt wie die US-Volkszählung setzt bei der Verbesserung des Datenschutzes auf Kryptografie.

Mit der Weiterentwicklung des Datenschutzes haben wir ein besseres Verständnis für die Feinheiten von digitaler Privatsphäre erlangt. So sind beispielsweise nicht immer nur die Daten bei der Übertragung zu schützen, sondern es muss auch die Rolle der Metadaten berücksichtigt werden. 

Schutz der Metadaten

Damit habe ich persönlich Erfahrung gemacht. Nachdem HTTPS an Bedeutung gewonnen hatte, bestand im Internet das Problem, dass HTTPS nur den Inhalt von Web-Transaktionen schützt – nicht aber die für diese Transaktionen erforderlichen Metadaten. Der größte Schwachpunkt war DNS, das zur Übersetzung der in URLs angewendeten Hostnamen in IP-Adressen verwendet wird, mit denen eine Verbindung hergestellt werden kann.

Herkömmliche DNS-Anfragen konnten ausspioniert werden und Angreifer die echten Antworten durch ihre eigenen ersetzen. Ein Nutzer konnte einen DNS-Server wählen – möglicherweise einen vertrauten Server –, aber Angreifer im Kommunikationsnetz leiteten die Anfrage oft an einen beliebigen Server weiter. Der Nutzer hätte den Unterschied nicht bemerkt, selbst wenn die Daten des Kunden zur Unterstützung eines Datenbroker-Geschäftsmodells verwendet worden wären.

Sicherung des DNS-Traffics

Aus diesem Grund habe ich eine Spezifikation für DNS über HTTPS (auch bekannt als DoH RFC 8484) mitverfasst, die inzwischen eine gängige Methode zur Absicherung des DNS-Traffics durch einen Client geworden ist. Clients, die DoH verwenden, können sich darauf verlassen, dass ihre Kommunikation mit einem DNS-Server nur auf den Client und den Server beschränkt ist. Dies stellt einen bedeutenden Fortschritt gegenüber dem traditionellen ungesicherten DNS dar. Es gibt nach wie vor ein Metadaten-Problem mit der Server Name Indication innerhalb von HTTPS selbst, das durch eine unabhängige Initiative der IETF namens Encrypted Client Hello gelöst wird.

Aber selbst angesichts dieser beiden technologischen Fortschritte ist die Situation noch nicht perfekt. Eine sichere Kommunikation zwischen zwei Parteien mag ideal für eine Konversation wie z. B. eine Textnachricht sein, bei der beide Parteien einander, möglicherweise aber nicht dem Netzwerk vertrauen, das sie miteinander verbindet. Bei einem DNS-Server ist die Situation nicht ganz die gleiche – ein Client vertraut dem Netzwerk, das ihn mit dem Server verbindet, möglicherweise nicht vollständig, aber auch dem Server gegenüber ist er vielleicht misstrauisch. DoH kann dann vor Angreifern aus dem Netzwerk schützen, und HTTPS oder DNSSec kann verhindern, dass der Server falsche Antworten liefert. Allerdings hindert nichts im Protokoll den Server selbst daran, nachzuverfolgen, wer welche DNS-Anfrage gestellt hat.

Der nächste Schritt: Oblivious DNS

Das nächste Entwicklungsstadium im DNS lautet Oblivious DNS (auch bekannt als ODoH). Ich habe im Rahmen von RFC 9230 an seiner Veröffentlichung mitgewirkt. ODoH wendet IP-Blinding-Techniken auf DoH an und verwendet eine doppelte Verschlüsselung und ein einzelnes Relay, um den Inhalt der DNS-Anfrage von der Identität des Clients zu trennen. Vereinfacht gesagt, wird ein Relay vom Client verwendet, um die IP-Adresse des Clients vor dem DoH-Server zu verbergen. Auf diese Weise sieht das Relay aufgrund der doppelten Verschlüsselung nur die Identität, während dem DoH-Server nur die DNS-Daten bekannt sind, da er nicht direkt mit dem Client kommuniziert.

IP-Blinding liegt bei datenschutzbewussten Netzwerken im Trend. Die Technologie wurde erstmals durch ToR bekannt und wird seit Kurzem auch vom Private Relay Service verwendet. Beide Beispiele wenden IP-Blinding auf den Transport-Layer an (Ströme beliebiger Internetdaten), während ODoH speziell für DNS gilt und auf dem Anwendungs-Layer arbeitet. Anwendungsspezifische Protokolle lassen sich in großem Maßstab leichter verwalten als generische Transportprotokolle, sodass es aus architektonischer Sicht sinnvoll ist, mehrere Ansätze zur Bekämpfung des Problems zur Verfügung zu haben.

In Arbeit: Oblivious HTTP

Oblivious HTTP (auch bekannt als OHTTP) stellt einen dritten Ansatz zur Verbesserung des Datenschutzes dar. Derzeit ist OHTTP ein noch nicht standardisierter Entwurf der IETF, allerdings verspricht er, ODoH so zu verallgemeinern, dass beliebige HTTP-Austausche auf eine Art und Weise durchgeführt werden können, die dem Server die Identität des Clients verbirgt, während der Inhalt weiterhin durch die Relays verborgen wird. OHTTP benötigt vier Knoten für eine einzige Transaktion – einen Client, ein Relay, ein Gateway und den Server. Damit ist dieses Protokoll etwas ressourcenintensiver als ODoH, aber flexibler hinsichtlich seiner Möglichkeiten.

Edge-Cloud-Plattformen wie Fastly spielen eine Schlüsselrolle bei der Bereitstellung der Infrastruktur für das moderne, datenschutzbewusste Netzwerk. Wir arbeiten täglich mit mehr Partnern zusammen, um noch mehr Möglichkeiten zu erkunden, wie unsere Edge Cloud mit den Anforderungen dieser anspruchsvollen Anwendungen zusammenpasst. Unser programmierbares Netzwerk ist im Grunde eine unendlich skalierbare, verteilte Anwendungsplattform, die ideal für dieses Paradigma ist. Es bietet Lösungen für CPU, Bandbreite und niedrige Latenzzeiten, die weltweit verfügbar sind. Und was noch besser ist: Die Edge-Cloud-Plattform ist als HTTP-Bereitstellungsplattform optimiert und bietet bereits fortschrittliches TLS-, Routing- und Verbindungsmanagement, was für eine hochleistungsfähige Infrastruktur unerlässlich ist.

Dieser Blogpost erscheint unter der Rubrik „Privacy Week“. Hier veröffentlicht Fastly Wissenswertes über Möglichkeiten der praktischen Integration neuer Technologien zum Datenschutz in das komplexe Gebilde des Internets.