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.
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/ -> http://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 http://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
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
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
|