ravenhorst - Browser

NoScript und DNT

nospam@example.com (Kai Raven) — Mon, 03 Jan 2011 06:49:48 +0100

Gerade kam ein Update von NoScript für die "Do Not Track" (DNT) Opt-out Header Funktion, die seit 2.0.9 enthalten ist - sprich Browser sendet an jede Website zusätzlichen Tracking Opt-out Header.

Lt. X-Do-Not-Track support in NoScript:

"From now on, a web browser with NoScript installed warns every HTTP server it contacts that its user does not want to be tracked, i.e. that his data must not be collected for profiling and persistent identification purposes. I believe this is a safe assumption about the feelings of most if not all NoScript users."

Richtig.

"As stupid as it may sound (why parties who are interested in tracking you would comply?),"

Eben. Stupid.

"a mean to clearly express your will of not being tracked is going to be useful, especially when backed by law or industry self-regulation, as explained here."

Nicht "besonders", sondern ausschließlich dann, wenn oder sobald die Auswertung und Beachtung von DNT gesetzlich vorgeschrieben ist. Selbstregulierung ist keine Option, sondern nur eine Taktik von Unternehmen und der Politik, einer gesetzlichen Regulierung im Interesse von Internetnutzern, Bürgern und Kunden zu entgehen.

"Therefore it seems in the interest of NoScript users and privacy-concerned netizens in general to participate in this effort."

Nein. Solange die obige Bedingung nicht erfüllt ist, trägt der Header nur zum Browser Fingerprint bei und identifiziert die User, die Anti-Tracking Erweiterungen installiert haben. Der DNT Header wird damit selbst zum Tracking Opt-in Header. Außerdem ist es wenig sinnvoll, wenn Erweiterungen anfangen, schlecht dokumentierte oder von Browseranwendern nicht beachtete bzw. nicht zu ändernde Header Manipulationen durchzuführen.

In diesem Sinne rate ich dazu, noscript.doNotTrack.enabled auf false zu setzen.

Wer Privoxy einsetzt - in die Filterdatei einsetzen:

CLIENT-HEADER-FILTER: kill-optout-header Header filter to remove Do-Not-Track headers.
s@^X-(?:Behavioral-Ad-Opt-Out|Do-Not-Track):.*@@i

In eine Actiondatei (z. B. match-all.action) einsetzen:

+client-header-filter{kill-optout-header} \

bewirkt dann global das:

Re-Filter: filtering 'X-Behavioral-Ad-Opt-Out: 1' (size 26) with 'kill-optout-header' ...
Header: Transforming "X-Behavioral-Ad-Opt-Out: 1" to ""
Re-Filter: ... produced 1 hits (new size 0).
Header: Removing empty header
Re-Filter: filtering 'X-Do-Not-Track: 1' (size 17) with 'kill-optout-header' ...
Header: Transforming "X-Do-Not-Track: 1" to ""
Re-Filter: ... produced 1 hits (new size 0).
Header: Removing empty header

Scroogle - Google - Tor

nospam@example.com (Kai Raven) — Tue, 11 May 2010 18:37:47 +0200

Der beliebte und bekannte Scroogle Proxy Dienst hat aktuell Probleme mit Google, wie zu lesen ist, wenn man Scroogle aufruft bzw. eine Suchanfrage absetzt:

We regret to announce that our Google scraper may have to be permanently retired, thanks to a change at Google. It depends on whether Google is willing to restore the simple interface that we've been scraping since Scroogle started five years ago. Actually, we've been using that interface for scraping since Google-Watch.org began in 2002.

This interface (here's a sample from years ago) was remarkably stable all that time. During those eight years there were only about five changes that required some programming adjustments. Also, this interface was available at every Google data center in exactly the same form, which allowed us to use 700 IP addresses for Google.

That interface was at www.google.com/ie but on May 10, 2010 they took it down and inserted a redirect to /toolbar/ie8/sidebar.html. It used to have a search box, and the results it showed were generic during that entire time. It didn't show the snippets unless you moused-over the links it produced (they were there for our program, so that was okay), and it has never had any ads. Our impression was that these results were from Google's basic algorithms, and that extra features and ads were added on top of these generic results. Three years ago Google launched "Universal Search," which meant that they added results from other Google services on their pages. But this simple interface we were using was not affected at all.

usw.

Da Scroogle immer ganz praktisch bei der Nutzung von Tor war, um den lästigen "We're sorry" Meldungen und Captcha Anfragen zu entgehen, muss schnell ein temporärer Ersatz her: Entweder man nimmt Ixquick oder man sucht sich bei Mycroft einen anderen Ersatz und kann dann dort direkt das passende Search Engine Plugin in Firefox installieren.

Mit zwei Anonymouse oder auch dem "Ninja" Plugin klappt das ganz gut. Und da eh alle Suchanfragen bei mir per Privoxy und Tor gefiltert und anonymisiert an den Suchdienst rausgehen... Aber mir wäre lieber, wenn das Scroogle wieder geregelt bekommt Nur wenn man einen Suchdienst erwischt, den Google selbst als "Gefährder" einstuft oder der Suchdienst die IP des Tor Exit Node an Google weiterreicht, kann man wieder schlechte Karten bei Google haben.

Update: Mal wieder viel Geschrei um nix, laut Scroogle scrapes back to life kann wieder gescroogelt werden

Siehe auch:
Heise - EU-Datenschützer fordern echte Anonymisierung von Suchanfragen (27.05.2010)

Panopticlick Experimente gegen Web-Tracking

nospam@example.com (Kai Raven) — Wed, 27 Jan 2010 15:29:34 +0100

Die Electronic Frontier Foundation (EFF) bietet mit Panopticlick ein nettes Spielchen (oder Experiment) mit ernstem Hintergrund für alle Internetuser an, die sich für die Anonymisierung ihrer Browser- bzw. WWW-Nutzung interessieren oder anders gesagt, wie ihr Webbrowser konfiguriert ist und deshalb welche Informationen ausspuckt, die er mit einer Teilmenge der Browser anderer Nutzer in einer gegebenen Gesamtmenge gemeinsam hat oder auch nicht. Noch einfacher: "Zeig mir, welchen Browser und wie Du ihn nutzt und ich sage Dir, wer Du bist und wo Du bist". Die meisten Internetnutzer dürfte es nicht interessieren

Den ernsten Hintergrund bildet die Identifizierung und Wiedererkennung von Webbrowsernutzern - das Optimum wäre: stets ein und desselben Nutzers, Verfolgung der Nutzung oder des Konsums von Webseiteninhalten über Webseiten und Websites hinweg und seine Geolokalisierung, an der sich Nutznießer und Auftraggeber der Werbeindustrie, manche Internet-Zugangsprovider, Dienste- und Inhalteanbieter oder auch Geheimdienste versuchen.

Ähnlich wie beim Anontest vom JonDonym Anonymisierungsdienst oder bei browserspy.dk wertet Panopticlick den charakteristischen User-Agent und HTTP_ACCEPT Header aus und sofern Javascript aktiviert ist (was bereits ein Kriterium an sich ist), installierte Browser Plugins, Zeitzone, Bildschirmauflösung, Farbtiefe, Systemschriften, ob Cookies und "Supercookies" per Flash LSOs und DOM-Storage möglich sind.

Bei EFFs Panopticlick werden die Daten aber nicht nur für jeden einzelnen User ausgewertet, angezeigt und wieder verworfen, sondern anonymisiert in einer Datenbank gespeichert und mit den Datensätzen aller anderen User abgeglichen, um zur besagten Aussage zu kommen, wie einzigartig und identifizierbar man in der Gesamtmenge ist. Also die gleiche Aussage, an der auch die angesprochenen Kreise interessiert sind. Je mehr und länger User mit ihren verschiedenen Betribessystemen, Browsern und Konfigurationen mitmachen, desto aussagekräftiger wird der Scorewert, den man nach dem Panoption Test erhält und desto aussagekräftiger die Antwort, die man sich von dem Panopticlick Experiment seitens der EFF erhofft: Wie gut lassen sich mit "Web-Tracking" Methoden digitale Fingerabdrücke für Browsernutzer erstellen und wie effektiv sind sie?

Einschränkend muss man sagen, dass man eigentlich umso besser in der Menge aller Browsernutzer verschwinden müsste, je mehr man den eigenen Browser genauso nutzt wie die Mehrheit oder zumindest der Durchschnitt aller Internetnutzer - wie ich annehme: mit veralteten Versionen, mit allen nur denkbaren Plugins und Erweiterungen vollgeknallt bis zum Anschlag, Javascript und Flash schön aufgedreht, Cookies immer dabei und natürlich ohne Anonymisierung

Kleiner Tipp zur neuesten Firefox-Version am Rande: Die finden ja nicht nur diese überflüssigen Minimalthemes names "Personas" ganz toll, sondern auch die Geo-Lokalisierung per Google Lokalisierungsdienste, die man aber laut Anleitung einfach und generell deaktivieren kann. Wird aber auch nur eine Teilmenge der Teilmenge abschalten, wie ich die feature-geilen Internetuser kenne.

Siehe auch:
EFF - Web Browsers Leave 'Fingerprints' Behind as You Surf the Net (17.05.2010)

RequestPolicy gegen CSRF für Mozilla Browser

nospam@example.com (Kai Raven) — Wed, 21 Jan 2009 11:16:44 +0100

Ich möchte Euch noch eine Erweiterung für Mozilla Browser vorstellen, mit der man eine weitere "Sicherheitsschicht" um die Browser legen kann.

Sie betrifft alle Anfragen und Verbindungen, die der Browser von einer Webpage einer Website, die aktuell aufgerufen wurde, zu einer anderen Website startet, um von der anderen Website Bilder, Skripte, eingebetten Frames usw. nachzuladen, die dann als Objekte der aktuell aufgerufenen Webpage angezeigt werden oder um Funktionen einer aktuellen oder fremden Webanwendung auszuführen und zu verändern, wobei beide Websites unterschiedliche Server betreffen können. Wurde die aufgerufene oder die andere Webpage/Website manipuliert oder dem Nutzer eine URL zu- und untergeschoben (z. B. über die beliebten Spam- und Phishing Mails), die manipulierte Websites aufrufen, kann das u. a. für die Cross-Site Request Forgery Angriffe (XSRF/CSRF & Co.) ausgenutzt werden.

Bei verschiedenen Angriffen spielen deshalb immer Anfragen eine große Rolle, die vom Nutzer unbemerkt im Hintergrund abgewickelt werden, wenn er sich eine Webpage "anschaut" und dortige Webanwendungen nutzt. Klar, könnte man auch ständig alle Anfragen selbst beobachten, überwachen und nachprüfen, aber das wäre beim alltäglichen Surfen kaum zu praktizieren. Hier setzt die RequestPolicy Erweiterung an, die ähnlich wie bei NoScript, RefControl und anderen Erweiterungen alle Anfragen gegen White- und Blacklist prüft. Nur das im Fokus der RequestPolicy Erweiterung die oben geschilderten Anfragen zu Domains fremder Websites stehen, während zum Beispiel mit NoScript das Verbeiten und Zulassen von Javascript, Plugins, iFrames usw. im Mittelpunkt steht, wobei auch NoScript mittlerweile verschiedene Schutzfunktionen gegen Cross-Site Anfragen und Scripting integriert hat, weshalb der Autor der RequestPolicy seine Erweiterung auch als Ergänzung zu NoScript sieht.

Zu RequestPolicy ein Beispiel von der Installation bis zur Anwendung anhand des letzten Beitrags im Weblog:

Nach der Installation zeigt RequestPolicy eine Auswahl von Standard-Whitelists an, die man aktivieren kann, um den Whitelists bereits vor dem Start Regelsätze hinzuzufügen, die Anfragen zu einem Zielrechner, von einem Ursprungsrechner oder zwischen einem Ursprungsrechner und einem fremden Zielrechner zulassen, weil sie als "sicher" gelten. Zum Beispiel enthält die "Europa und Russland" Whitelist die erlaubte Anfrage von der Domain (Quelle) "amazon.de" zu " images-amazon.com" (Ziel, von der für die Website von http://www.amazon.de/ Bilder geladen werden). Allerdings sind in den Whitelists nur die Hauptdomain und keine Subdomains erfasst. Wer zuerst generell alle Anfragen verbieten will, um sich selbst Whitelists aufzubauen, aktiviert keine Whitelist. Wer sich später entscheidet, doch eine der Whitelists zu nutzen, kann das später nachhholen.

In den Einstellungen kann man die grobe Überprüfung ("Base domain") weiter bis zur Überprüfung des Protokolls, der vollständigen Domain und des Ports verschärfen, um erlaubte Anfragen einzugrenzen. Für eine Whitelist Regel würde das zum Beispiel bedeuten, dass bei der ersten Stufe für Bilderanfragen von blog.kairaven.de zu hp.kairaven.de über http/https/ftp die Regel gelten würde: kairaven.de -> kairaven.de erlaubt, bei der letzten Stufe nur http://blog.kairaven.de/ -> https://hp.kairaven.de:80 erlaubt.

Das Bild (es könnte auch ein Javascript, ein CSS oder sonst was sein) wurde blockiert, weil es nicht von http://blog.kairaven.de, sondern von https://hp.kairaven.de stammt. Bei Bilddateien, die über Anfragen zu einer anderen Domain geladen werden, zeigt RequestPolicy einen Rahmen und beim Darüberfahren mit der Maus die Adresse der Zieldomain an.

Über das Kontextmenü des RequestPolicy Icons in der Statuszeile wird angezeigt, zu welchen fremden Domains/Adressen Anfragen ergehen sollen, die deshalb aufgrund der 3. Stufe zur Überprüfung blockiert wurden. Über das Kontextmenü und das Untermenü zu einer blockierten Anfrage kann man dann ähnlich wie bei NoScript die Anfragen von einer Quelle, zu einem Ziel oder zwischen Quelle und Ziel permanent oder temporär erlauben.

Die Entscheidung, die über das Kontextmenü getroffen wurde als Regel in der "Quelle-zu-Ziel" Whitelist.

Den größtmöglichen Sicherheitslevel für die Funktionen, die RequestPolicy bietet, der aber auch mit maximalem Einrichtungsaufwand einhergeht, erreicht man also, wenn keine vorkonfigurierte Whitelist und die höchste "Strictness" Überprüfung aktiviert, aber nur die "Quelle-zu-Ziel" Whitelist verwendet wird.

Die RequestPolicy Erweiterung kann über die Homepage der Erweiterung oder, da sie noch im Experimentalstadium ist, nach Login über die Firefox Add-ons Seite installiert werden. Wie man auf der Seite zu aktuellen und geplanten Features von PolicyRequest nachlesen kann, hat der Autor mit PolicyRequest viel vor. Wie gesagt ist sie noch experimentell. Andererseits besteht die Möglichkeit, dass Erweiterungen wie NoScript und AdBlock Funktionen von PolicyRequest übernehmen. Zu erwähnen ist auch, dass es neben PolicyRequest auf Firefox Add-ons eine Reihe anderer Erweiterungen gibt, die sich ebenfalls CSRF und XSS annehmen. Zu begrüßen wäre es, wenn in zukünftigen Mozilla Browsern die Funktionen einer Reihe von Sicherheits-Erweiterungen fest integriert würden, die sich als nützlich und absichernd erwiesen haben, denn die Liste der Erweiterungen, mit denen man seinen Browser zusätzlich absichern muss, wird immer länger.

Da es sich anbietet, hier mal wieder das beliebte Spiel "Zeigst Du mir Deine Erweiterungen, zeig ich Dir meine". Aktuell installierte Erweiterungen, dir direkt oder indirekt der Sicherheit, dem Datenschutz und Anonymisierung dienen:

Via:
ha.ckers Blog - RequestPolicy Firefox Extension

Ein FlashGot-Wget "Download-Manager" für Firefox

nospam@example.com (Kai Raven) — Tue, 20 Jan 2009 11:30:06 +0100

Bisher nutzte ich unter Windows für Downloads mit Firefox immer die FlashGot Erweiterung (vom Programmierer stammt auch NoScript) mit dem Free Download Manager, der Feedreader brachte auch noch seinen eigenen Download-Manager für Podcasts, Movies usw. mit. Mal direkt oder über Tor, I2P und JonDonym für anonymisierte Downloads. Die beiden Download-Manager hatten die meiste Zeit nichts zu tun und so etwas gefällt mir nicht. Auch wenn ich mir bei den niedrigen Speicherpreisen jetzt den Arbeitsspeicher aufgerüstet habe, um demnächst etwas mit Virtualisierung herumzuspielen.

Da ich Wget in der Konsole ebenso gerne für Downloads nutze und es zu dessen Einbindung in FlashGot auf der Features Seite ein Beispiel gab (was mir nicht ausreichte), habe ich mir mit ein paar Batchdateien, der Wget Portierung des GnuWin32 Projekts und ein paar weiteren Sachen einen minimalen Wget "Download-Manager" gebastelt, der dann im FlashGot Kontextmenü von Firefox so aussieht:

Die "NoProxy" Menüeinträge rufen, wie der Name schon sagt, Wget für den Download ohne Proxy und Weiterleitung an Tor, I2P oder JonDonym auf, bei den "Proxy" Menüeinträgen werden Downloads über den Privoxy Proxy und ggf. einen Anondienst abgewickelt, für FTP Downloads statt Privoxy über JonDonym, da Privoxy kein FTP unterstützt.

"NoSSLcheck" ist für SSL/TLS verschlüsselte Downloads von Servern da, die nur selbst signierte Zertifikate anbieten und deshalb nicht gegen die CA-Zertifikate geprüft werden können bzw. bei CA-Zertifikaten, die man noch nicht einer Datei mit einem Paket aller CA-Zertifikate hinzugefügt hatte, aber wo man trotzdem etwas herunterladen möchte.

Aufruf mit "Wget-Proxy", Download über Privoxy und Tor. Erfolgreicher Download, da Wget das Server-Zertifikat nach Prüfung gegen das CA-Zertifikat anerkannt hat.

Aufruf mit "Wget-Proxy", Download über Privoxy und Tor. Abbruch des Downloads, da der Server nur ein selbst signiertes Server-Zertifikat anbietet, das nicht gegen ein CA-Zertifikat geprüft werden kann.

Aufruf mit "Wget-Proxy-NoSSLcheck", Download über Privoxy und Tor. Kein Abbruch des Downloads, da Wget angewiesen wurde, das Server-Zertifikat nicht zu überprüfen.

Bei Menüeinträgen ohne "NoSSLcheck" werden immer Server-Zertifikate gegen die CA-Zertifikate geprüft und deshalb ein Download abgebrochen, wenn etwas nicht mit den Host- und Zertifikatangaben stimmt. Was aufgrund von Angriffsmöglichkeiten und Schlampereien bei den CAs auch nicht unbedingt eine Garantie bietet, wie man immer wieder erfahren muss.

Natürlich kann man die Liste beliebig für weitere Zwecke und Funktionen von Wget erweitern.

Für die Datei mit dem Paket aller CA-Zertifikate habe ich mich der Zertifikatespeicher der Browser und OpenSSL bedient. Man kann natürlich auch selbst alle CA Sites absurfen und sich die Zertifikate selbst besorgen und "behandeln". Weitere Methoden werden in der readme Datei genannt.

Falls es jemanden interessiert oder für diejenigen, für die das Ganze nützlich sein könnte, habe ich die Batchdateien und eine eingerichtete wgetrc Datei in ein Archiv gepackt. In der readme Datei steht auch alles Weitere ausführlich erklärt. Verbesserungsvorschläge und Tipps sind wie immer willkommen.

Vermutlich kommen ein paar Leser angerannt, die mir sagen wollen, das sei alles zu kompliziert und Download-Manager XY viel besser, schöner, bunter und mächtiger. Aber genau die wollte ich eben nicht. Was die Wget Geschichte nicht kann – wie zum Beispiel der Free Download Manger, ist die automatische Konvertierung von Filmchen, die man bei YouTube herunterlädt. Aber dafür gibt es dann auch wieder einfache Tools.

Siehe auch:
WackGet

Mit SSL Blacklist Erweiterung nach MD5 signierten Zertifikaten Ausschau halten

nospam@example.com (Kai Raven) — Fri, 02 Jan 2009 11:17:37 +0100

Erster Test mit der SSL Blacklist Erweiterung für Firefox, die neben den schwachen Schlüsseln des OpenSSL Bugs jetzt auch die mit MD5 signierten Zertifikate als Warnung auswerfen soll:

In der Infobar des Adresseingabefelds erscheinen zusätzliche Icons – ein Zertifikaticon oder ein Warnsymbol.

Angesurft habe ich bis jetzt daneben nur mein Kreditinstitut, die Arge, die Fireox Add-ons Site und meinen Provider. Zur Ergänzung auch ganz nett ist die Cert Viewer Plus Erweiterung, die aber nichts mit den obigen Schwachstellen zu tun hat. Die Informationen in der Zertifikatsansicht:

CAcert has switched from MD5 to SHA-1 for certificate-issueing a few years ago, when the first research results were made public that indicated that such an attack will become feasible. CAcert is currently still using an intermediate CA that was issued with an MD5 based signature 3 years ago. We are currently working to phase out this intermediate CA.

CAcert NEWS Blog - Happy new attack!

Hintergründe:
25C3 - MD5 considered harmful today - Creating a rogue CA Certificate (BitTorrent)
Alexander Sotirov, Marc Stevens, Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, Benne de Weger - MD5 considered harmful today - Creating a rogue CA certificate
Heise - 25C3: Erfolgreicher Angriff auf das SSL-Zertifikatsystem

Siehe auch:
Fefe - Ich habe gerade mal einen Bug gegen Firefox gefiled (ja, auch "nett" )
eWeek - SSL Certificate Vendor Sells Mozilla.com Cert to Some Guy