Tag Archives: Cloudflare

Systemd: resolved verkauft User u.U. an Google und Cloudflare

Posted on by

Was so alles ans Licht kommt, wenn man Mailinglisten verfolgt. Quasi in einem Nebensatz hat Herr Pöttering kurz mal erklärt, daß systemd gegen die DSGVO verstößt.

Systemd: resolved verkauft User u.U. an Google und Cloudflare

Die DSGVO legt fest, daß alle Systeme die zum Einsatz kommen, in einer datenschutzfreundlichen Voreinstellung daher kommen müssen. Merkt Euch das mal für später.

Hier erstmal ein Auszug aus dem Posting von Herrn Pöttering:

„Also, people would react very allergic if we’d start sending all DNS traffic to google or so. I mean, you can’t believe how pissed people are that we have a fallback in place that if no DNS servers have been configured at all or acquired via DHCP we fall back to Cloudflare + Google DNS servers. Downstream distros (Debian…) tend to patch that fallback out even…“ (Fedora ML, 29.9. 10:19)

Meint auf deutsch:

„Außerdem würden Menschen sehr allergisch reagieren, wenn wir anfangen würden, alle DNS Verkehr zu googlen oder so. Ich meine, Sie werden es nicht glauben, wie sauer die Leute sind, dass wir einen Fallback haben, der, wenn überhaupt keine DNS-Server konfiguriert sind oder über DHCP erworben werden, greifen wir auf Cloudflare + Google DNS-Server zurück. Downstream-Distributionen (Debian…) neigen dazu, das sogar raus zupatchen …“

Oh, ja, da reagieren wir Menschen allergisch drauf, weil das einen Verstoß gegen den Datenschutz darstellt. Die Debinaleute sehen das ganz richtig. Man kann nicht einfach heimlich am Benutzerwunsch oder Adminunvermögen hinweg Daten an Google oder Cloudflare schicken. Wenn das in einer Firma, einem Verein oder einer Behörde passieren würde, dann wäre das ein DSGVO Verstoß der bestraft würde! Scheinbar hat hier jemand die Jahre 2016-2019 verschlafen, als die EU Gerichte mit so etwas aufgeräumt haben. Zur Erinnerung: US Privacy Shield .. zusammengebrochen, Facebook droht mit Rückzug aus der EU, Google & MS verlegen Ressourcen in die EU, damit sie weiter im Spiel bleiben können und dann kommt ein Systemd daher, der die DSGVO unterminiert.

Man stelle sich mal vor, eine größere Firma in der auch Linux als Desktop zum Einsatz kommt und dann steht in irgendsoeiner hart gecodeten .so drin, sie soll Google kontaktieren. Für alle die nicht wissen, was Datenschutz in Firmen heutzutage bedeutet:

  1. Zuerst muß man mal ermitteln wohin was für Daten abfließenund wen das genau betrifft
  2. Dann muß man eine Datenschutzfolgeabschätzung dafür machen
  3. Dann muß man geeignete Schutzmaßnahmen ergreifen.
  4. Das muß als Vorgang mit laufender Nummer in die Datenschutzmappe eingetragen werden.

Jetzt habe ich als Admin also einen DNS Cache für die Firma hingestellt und per DHCP teile ich dieses DNSCache allen PCs mit. Die PCs fragen also meinen DNS Cache und der fragt dann wen auch immer.Das DNS Cache wird also schon eine Reihe von meinen Abfragen so beantworten können, was den Datenschutzvorteil hat, daß der DNS, den das Cache wiederum fragt, nur einen Bruchteil davon sieht und so kein vollständiges Profil erstellen kann. Den DNS Cache ( z.b. nscd ) kann man auch per Round-Robin mehrere andere Server fragen lassen um die Profilbildung weiter zu erschweren.

Der Problemfall

Jetzt funktioniert der lokale DNS aber nicht, weil es ein Update gab, oder die VM abgestürzt ist. Systemd würde jetzt keine gültigen DNS bekommen und Google+Cloudflare fragen. Damit wäre meine komplette Datenschutzabschätzung fürn Arsch. Schlimmer noch ist der Umstand, daß diese Art Datenfluß als Vorgang überhaupt gar nicht in meiner Datenschutzmappe vorkommt. Zum Glück ist das ein minder schwerer Fall, den der Datenschutzbeauftragte selbst regeln kann, indem er den Vorfall in die Mappe einträgt und Maßnahmen ergriffen werden, dies zukünftig zu verhindern.

Sollte aber ein Datenschutzaudit ergeben, daß es diesen Abfluß gibt ohne das das intern gefunden wurde, sieht die Sache schon anders aus. Je nach Umfang könnte die Datenschutzbehörde ein Bußgeld verhängen und das nur weil einer, den keiner in der Firma kennt, meinte schlauer sein zu müssen, als alle anderen. Na danke!

Jetzt kommt der nächste Oberschlaue mit dem Hinweis, daß bei DSL ja eh alle die gleiche IP von der Firma haben und individuelle Profile gar nicht erstellt werden können und außerdem wären das ja keine privaten Domainanfragen. Das fällt bei größeren Firmennetzen seit IPv6 unter „Es war einmal..“ . Wenn ich einen Businesszugang mit einem reinen IPv6 Netz bekommen, habe ich einen ganzen Block zur Verfügung. Dies Netz kann ich direkt an alle Pcs durchreichen, denn dann habe ich kein NAT Problem mehr. Per Firewall kann ich den Direktzugang zu den Pcs sperren, kein Problem und wenn doch mal jemand von außen drauf muß, wären individuelle Freigaben möglich. Das muß man als Admin natürlich auch mit IPv6 nicht so machen, aber es wurde mal so vermarktet, als für IPv6 geworben wurde.

Das die meisten am Arbeitsplatz auch privat surfen, braucht man wohl kaum noch erwähnen.

Die Technisch -Organisatorischen Maßnahmen zum Datenschutz einer Firma ( TOM ) beinhalten alle Maßnahmen die man so als Firma macht und wenn da steht, wir leiten DNS über ein Cache zum minimieren von Profilbildungen, dann kann man da schlecht ein Linux betreiben, daß sich da nicht dran hält, oder seht Ihr das anders? Linux muß also auch in der Datenschutz freundlichen Einstellung daher kommen, was damit einen Einsatz von systemd-resolved ausschließt, da man sich da ja nicht drauf verlassen kann wie man oben sieht.

Update

Ein Leserbrief erreichte mich vorhin. Hier ist der Link, in dem das Fallbackfeature bei Systemd besprochen wird: https://github.com/systemd/systemd/pull/11666

Und gleich noch die Diskussion, wieso CloudFlare DNS besser wären: https://github.com/systemd/systemd/issues/8899

So richtig viel Gegenwind gabs aus der Peergruppe anscheinend nicht.

Wieso DoH nicht gut für die Privatsphäre des User ist.

Posted on by

Mozilla will ja ab sofort in den USA DoH als Testballon starten. Der Rest der Welt soll später folgen. Ziel der Aktion ist es, daß DNS Anfragen nicht mehr von DNS-Servern wie Bind beantwortet werden, sondern, daß Webserver die DNS Informationen für den anfragenden Clienten per HTTPS beantworten. Bleibt die Frage, was und woher tunnelt er die Daten?

„Wäre es nicht die Wirklichkeit, es wäre ein Bestseller“

Ganz kurz umrissen, wird Firefox per HTTPS  die Cloudflare DoH-Webserver fragen, die holen sich DNS Antworten dann vom Cloudflare DNS-Servern und der von den korrekten  DNS-Servern. In der Endstufe war geplant, daß die besuchten Webserver die DNS Anfragen selbst beantworten, so daß wieder eine dezentrale Struktur entsteht.

Mozilla möchte damit erreichen, daß DNS Anfragen nicht mehr im Klartext durchs Netz gehen, weil ein Angreifer die bisherige DNS Information mit einer MITM-Attacke angreifen kann ( Man-in-the-Middle ). Nobel, aber sollte DNSSEC nicht genau das Problem lösen?

Und wer sagt uns, daß Cloudflare die Daten nicht manipuliert? Millionen von DNS-Webanfragen  würden bei Cloudflare durchgehen und wären so leichteste Beute für einen, der nicht will, daß Domain X erreichbar ist, oder Inhalt Y hat.

Wer schützt uns vor Zensur?

Das DNS System, denn es gibt Millionen DNS Server und Caches aus denen ich mir die Informationen zu einer Domain ziehen kann, inklusive der Autoritären-DNS des Domaininhabers.

Wie jetzt, Eurer Provider blockt externe DNS und erlaubt Euch nur seine eigenen DNS-Caches zu benutzen?

Lest das hier: UDP Traffic per SSH tunneln

Und wie sieht es mit dem Datenschutz aus?

Firefox sendet jetzt private Informationen in einem Ausmaß an ein amerikanisches Unternehmen, daß daraus leicht Profile bilden kann, und der Datenschutz sieht zu? Glaube ich kaum.

Was wollte Mozilla doch gleich mit DoH schützen?

Die Privatsphäre, ach ja, kommen wir mal dazu. Korrekt ist, daß ein DNS Betreiber in den Logfiles, so er denn welche erstellt, nachsehen kann, welche IP welche Domain hat auflösen wollen. Cloudflare kann das auch, niemand hindert sie daran. D.b. für die Privatsphäre ist es mit Cloudflare als derzeit einzigem DoH Betreiber, noch schlechter bestellt, als jetzt.

Derzeit kann ich mir aussuchen, welchen der vielen DNS Server ich frage, oder ob ich mir vielleicht gleich selbst einen eigenen DNS Cache hinstelle, der nur für mich arbeitet. Mit DoH geht das nicht mehr, außer ich betreibe einen DoH Server. Mangels Masse, eher unrealistisch derzeit.

Wie man seine eigenen DNS Anfragen auf möglichst viele DNS Server verteilt um bei keinem der DNS Betreiber ein sinnvolles Profil zu hinterlassen, findet Ihr in diesem früheren Beitrag von mir : Linux – DNS-DeTracking mit nscd

Fazit

DoH ist derzeit die leibhaftige Vision einen dystopische Zukunft, in der alle User bei einem einzigen Anbieter sind, so wie in den Terranauten, alle beim Energiekonzern Energie beziehen, vom Lebensmittelkonzern ernährt werden und auch ansonsten von Monopolen beherrscht werden. DoH ist im jetzigen Zustand nur eins: nicht akzeptabel.

Eine (von vielen) Alternative

DNS-Anfragen per TLS manipulationssicher zu machen, ist ok. Aber, wozu eigentlich der HTTP Overhead? Reicht es nicht, wenn Bind einen TLS Port bereitstellen würde und der zuerst gefragt wird? Das hätte zur Folge, daß der Server durch den SNI im TLS auch domainbasierte Zertifikate benutzen kann, also auch beweisen könnte, daß er er ist und nicht ein MITM-Angreifer.

Zugegeben, der Overhead dabei wäre aufgrund der möglichen Schlüssellängen ziemlich heftig, aber dafür könnte man z.b. kleinere, mit dem Zertifikat des Domaininhabers signierte, DNS Zertifikate einsetzen. Lets Encrypt könnte das z.B. gleich mit erzeugen und ausliefern, wenn das Hauptzertifikat erzeugt wird.

DNS-Caches könnte man dann gleich daran erkennen, daß sie ein Zert anbieten, daß nicht zum Domainnamen paßt. Anhand der bekannten Root–Zertifikate könnte man auch gleich die Ketten verifizieren. Es ist etablierte Technik, es gibt etablierte Bibliotheken, systemische Schwachstellen sind bekannt, und durch die kürzeren Zerts wäre der Performanceeinbruch nicht so stark. Würde man zudem mehrere DNS Anfragen in einer TCP Sesssion durchführen, so denn sinnvoll möglich, würde der Overhead weiter sinken.

Es gibt also Methoden, die eine derzeit zentrale Instanz wie Cloudflare nicht benötigen, warum also  dann DoH durchziehen?  In einer dystopischen Zukunft wären die Gründe wie immer: Machtgeilheit, Geldgier und, daß eine Gruppe von wackeren Helden den Schurken in einem effektvollen Kampf schlagen kann.

In dem Sinn: „Avengers, Assemble!“