keweonDNS – Infos, Fakten und warum keweon mehr ist als [AD BLOCKER] und [BROWSER PRIVACY]

  • 347 Antworten
  • Letztes Antwortdatum
So, mal wieder ein kleines technisches Update und ich hoffe, Google liest hier mit. 😈

Es geht um die Webseite „html-load.com“, das inzwischen mehr und mehr auf Webseiten eingebaut wird. Damit kommt Werbung und wenn die Seite geblockt wird, erfolgt eine Löschung des CSS Ordners und die Seite zerreißt es. (Siehe gutefrage.net)

Wie passiert das?
Die Webseite greift auf ein JavaScript zu und wenn das nicht erreichbar ist (html-load.com geblockt) kommt das löschen.
Das ist jetzt eigentlich nix problematisches, aber, trotzdem wird die Werbung von mir geblockt.

Warum?

1. HTML-Load.com gehört inzwischen Google und mein Verhältnis zu Google muss ich glaub ich niemand mehr weiter erklären.

2. Das JavaScript von der Seite html-load.com ist bereits vorbereitet, Malware zu verteilen. Wenn man sowas nicht vorhat, es soll ja noch Menschen geben die glauben Google sind die Guten, programmiert sowas keiner rein.

3. Durch das JavaScript erfolgt eine Netzwerk Analyse. Ergo, wenn ein Unternehmen oder User als Admin arbeitet, kann das komplette Netzwerk ausgelesen werden. Und ja, auch somit das komplette ActiveDirectory. Und nur am Rande, wer bei sowas mit lokalen Adminrechten arbeitet, nicht direkt, aber indirekt, lassen sich so problemlos Passwörter auslesen.

Deswegen arbeite ich gerade daran, diesem Dreck zu blockieren. Das ist soweit auch schon erledigt, allerdings gestaltet sich der „Multi User Mode“ etwas schwieriger als gedacht.

Das bedeutet:
Für mich als einzelner User kann ich die Seite problemlos sauber halten, ohne dass das mit dem CSS löschen erfolgt. Sobald das mehr als 1 User ist, funktioniert das Ganze nicht mehr. Da ich inzwischen dahinter gekommen bin, was die machen, was die noch weiter machen können und wie die darauf reagieren werden, wie auch die Tatsache, dass da inzwischen Google dahinter steckt, bin ich gerade dabei einen „Responder“, also Antwort Server zu entwickeln, der das ganze aushebelt.

Zum einen verstehe ich beim besten Willen nicht, wie man als Webseitenbetreiber diesen gefährlichen Dreck einbinden kann. Zum anderen, ich hab mir selbst mal geschworen, egal was Google macht:

Let‘s make the things that Break the things they made.

Es wird also noch ein bischen dauern, aber das Zeug kommt weg. Da ich allerdings Google kenne, werden die darauf reagieren und - na ratet mal.

Klar, am Browser gibt es immer irgendwelche Plugins die den Mist wegmachen, aber mir gehts dabei um Handy, Xbox und Co. wie auch SmartTV, wo die nicht installiert werden. Allerdings, selbst die großen Adblocker haben so die Probleme das hinzubekommen.

Und nur vorab als Info, wenn das fertig ist, sieht das so aus:

IMG_1544.png
IMG_1551.png

Tja, geht doch. Wesentlich sicherer und sieht auch so viel besser aus, oder?
 
Zuletzt bearbeitet:
  • Danke
Reaktionen: chester1987 und DwainZwerg
Probleme?
 
@Grossmeister_T danke für die Nachricht, aber außer deiner habe ich keine weiteren Meldungen erhalten :confused2:
 
  • Danke
Reaktionen: Grossmeister_T
War ein paar Minuten keine Verbindung mehr möglich. Vielleicht doch nur mein Handy... Danke
 
  • Danke
Reaktionen: MrT69
Technisches Update:

Eure ständige Frage – „Was passiert, wenn der Trust-Anchor kompromittiert wird?“ – hat ein seit 25 Jahren ungelöstes PKI-Problem offengelegt.


Worum es geht​

Root-CAs sind self-signed.
Ist der private Schlüssel weg, gibt es keinen technischen Hebel, ihn sauber zu widerrufen.
DigiNotar 2011 zeigt die Folgen: Wochenlang offene Leitungen, hektische Patch-Runden, niemand wirklich vorbereitet.


Die Antwort: RTO-Extension (Root TurnOff)​

Idee in einem Satz:
Die kompromittierte CA schaltet sich selbst ab, bevor sie das Netz mitreißt.

Mechanik
  1. Jede CA trägt eine verschlüsselte Monitoring-URL im Zertifikat.
  2. Ein Wächter pingt alle sechs Stunden die komplette Kette.
  3. Erkennt er Unregelmäßigkeiten, wird eine manuelle Prüfung ausgelöst.
  4. Zwei Prüfer bestätigen → die CA veröffentlicht ihre eigene Sperr-CRL → Ende der Geschichte.
Gesamtdauer: unter zwei Stunden vom Fund bis zur Sperre.
Früher: eher zwei Wochen – wenn es gut lief.


Technisches Papier​

Komplette Spezifikation bei der IETF:
Root CA Emergency Self-Termination Protocol (RTO-Extension)
(Schaut in Acknowledgements ;))


Warum das hier entstanden ist​

  • Ihr fragt nach Worst-Case, nicht nach Marketing-Stories.
  • Ihr akzeptiert kein „geht nicht“.
  • Ihr zerlegt Konzepte bis zum Grundgerüst.
Genau dieser Druck hat den Knoten gelöst.


Wie es weitergeht​

RTO läuft als Proof-of-Concept in keweonDNS.
Ihr habt Szenarien, Angriffsideen oder offene Fragen?
Postet sie. Jedes kritische Feedback härtet das System.
 
  • Danke
Reaktionen: ALPHA-S
Servus,

bin neu hier und war eher stiller Leser und sehr zufriedener Nutzer deines Dienstes.

Habe aber folgendes Problem:
In der Payback App auf IOs — wenn ich dort auf Coupons klicke und dann „suchen“ und dort einen Anbieter anklicke — kommt eine Fehlermeldung „etwas scheint nicht zu funktionieren“ und es klappt nicht. Ohne deinen DNS klappt es - natürlich getestet. ;)

Denke da wird vielleicht etwas falsch geblockt. Für eine Prüfung danke ich vorab.

LG und weiter so!
 
  • Danke
Reaktionen: MrT69
Zurück
Oben Unten