Als die Firefox-Extension „Firesheep“ vorgestern veröffentlicht wurde, war der überwiegende Kommentar in der Hacker-Zunft ein lapidares „Ach, hat das jetzt also auch endlich mal jemand gemacht…“, denn was Firesheep nun jedem Firefox-Nutzer als Zusatzfunktion bietet, ist seit Jahren möglich (und wohl auch üblich):
Firesheep ermöglicht ohne großen Aufwand das Übernehmen von http-Sessions (also z.B. einer Anmeldung bei Facebook) unter 2 Bedingungen:
1. Der Computer des Angreifers und der des ‚Opfers‘ befinden sich im gleichen, nicht verschlüsselten WLAN.
2. Die Verbindung zur fraglichen Seite wird über normales http und nicht per https / SSL, also unverschlüsselt übertragen.
Wenn diese beiden Bedingungen erfüllt sind (zum Beispiel in einigen jener sprichwörtlichen Berlin-Mitte-Bars beim Zugriff auf Facebook), dann reicht es, Firefox mit der Extension zu starten. Bevor der Latte Macchiato ausgetrunken ist, werden die ersten Accounts der Sitznachbarn zur freien Übernahme angeboten. In den übernommenen Accounts hat man dann alle Rechte eines angemeldeten Benutzers. Das kann das Bloggen auf dem persönlichen Blog, irgendwelche Scherze auf Facebook, oder unser aller Lieblingsbeschäftigung, das Twittern betreffen – kurzum: Jede Seite, auf der das Opfer gerade eingeloggt ist.
Sowohl das Unterhalten eines unverschlüsselten WLANs, als auch das Anbieten des Zugangs zu sicherheitsrelevanten Bereichen ohne https gelten zur Recht seit jeher als absolut-nicht-zu-empfehlen-bist-du-eigentlich-verrrückt. Leider hat sich das Verschlüsseln bei WLANs nach 10 Jahren des Predigens bei Weitem nicht flächendeckend, aber immer noch besser durchgesetzt als bei Webservern. Der Grund dafür ist (vermutlich) dass beim Verschlüsseln ein (heutzutage vernachlässigbarer) zusätzlicher Rechenaufwand für den Server anfällt.
Zwar bieten viele Anbieter ihre Dienste auch verschlüsselt an, so zum Beispiel Facebook, per default erfolgt der Zugriff aber unverschlüsselt, wenn sich der Besucher nicht die Mühe macht, das https:// manuell einzugeben. Die Unsicherheit von http greift aber nicht nur im unverschlüsselten WLAN – dort wird sie nur besonders eklatant, weil unsere Computer ihre TCP-Päcken in alle Richtungen durch den Äther schleudern. Greifen wir auf das Netz per Kabel zu, kann immer noch an potenziell jeder vermittelnden Stelle das gleiche unternommen werden (wenn auch nicht mit einem Firefox-Plugin). Als ich die Anzahl der vermittelnden Stellen gerade einmal probehalber bei Facebook.com per traceroute geprüft habe, waren es 11 an der Zahl.
Was muss also passieren?
Die Forderung ist einfach und seit vielen Jahren die gleiche: Https muss zum Standard beim Zugriff auf jegliche Form von nicht-öffentlichen Daten (Email, Facebook, Admin-Backends bei Content-Management-Systemen, etc.) werden – egal, ob per Kabel oder Luft.
Wer macht das bisher noch nicht?
Die Liste ist lang: Firesheep unterstützt unter anderem Amazon, Dropbox, Evernote, Facebook, Flickr, Windos Live, Tumblr, Twitter, WordPress, Yahoo und sogar GitHub (hab ich jetzt nicht alles geprüft). Im Januar ging Gmail mit gutem Beispiel voran und setzte alle Kommunikation auf https.
Wie kann ich mich schützen?
1. In offene WLANs unbedingt Sicherheitsvorkehrungen (https, VPN) treffen.
2. in WEP-verschlüsselten WLANs ebenso, denn der Aufwand ein Tool mit ähnlicher Funktion wie Firesheep auch für WEP-verschlüsselte Netzwerke zu bauen, wäre nur minimal höher – WEP-Netzwerke lassen sich in Minuten knacken, und der Firesheep-Sniffer müsste nur minimal verändert werden. WPA2 mit Client Isolation ist die einzige akzeptable Sicherung für ein WLAN.
3. Immer brav ans https:// denken. Die meisten Anbieter unterstützen es ja immerhin. Wer seine Bookmarks einmal aktualisiert, hat viel für seine Sicherheit getan. Update mit Dank an Balkonschläfer: Das HTTPS-Everywhere-Plugin von der EFF bemüht sich, möglichst alle Verbindungen über https herzustellen. Update mit Dank an Kirst3n: Force-TLS Addon für Firefox (TLS ≈ SSL).
4. Immer schön ausloggen. Bringt nicht viel, aber loggt bestenfalls den Angreifer mit aus.
5. Wenn möglich in fremden Netzen VPN nutzen, wodurch jeglicher Datenverkehr zumindest bis zum VPN-Anbieter, der eine Institution des uneingeschränkten Vertrauens sein sollte, verschlüsselt wird.
6. und wichtigster Punkt: Anbieter verfluchen, bei denen SSL nicht einfach default ist, und auf eine Verhaltensänderung hinarbeiten.
Dieses Ziel haben sich auch die Entwickler von Firesheep gesetzt: Indem die Sicherheitslücke nicht vorhandene Sicherheit einer großen Zahl von Nutzern demonstriert und zur Hand gereicht wird, soll ein Bewusstsein für die Notwendigkeit der Nutzung von seit Jahren verlangten Techniken geschaffen werden. Deshalb ist Firesheep open-source auf github erhältlich. Als Firefox-Extension läuft es auf allen weiter verbreiteten Betriebsystemen.
Das funktioniert auch in normalen, verkabelten Netzen, wenn z.B. ein Hub mehrere Hotelzimmer verbindet. Selbst in Netzwerken mit Switches ist man nicht sicher, ARP Spoofing und ARP Flooding sind die Stichwörter. Also konsequent HTTPS benutzen!
Das traurige ist aber, dass man, wenn man eine Webseite per https ansurft, teilweise dann wieder auf die unverschlüsselten Seiten weitergeleitet wird. Amazon ist z.B. ein Beispiel: Die Startseite wird per https geladen, wenn man dort aber auf einen Link klickt, so ist dieser dann in der Regel unverschlüsselt…
Ich nutze dieses Firefox-Addon der Electronic Frontier Foundation: Encrypt the Web with the HTTPS Everywhere Firefox Extension https://www.eff.org/deeplinks/2010/06/encrypt-web-https-everywhere-firefox-extension
Ganz nützlich
Warum funktioniert der Angriff eigentlich nicht in einem per WPA(2) gesicherten WLAN?
Ich hatte gedacht, dass in einem ’normalen‘ WPA-WLAN alle Kommunikation mit dem gleichen Schlüssel verschlüsselt werden, soll heissen, dass jeder Client mit dem Server mit dem selben Schlüssel kommuniziert. Falls man den Schlüssel kennt und sich in WLAN eingewählt hat, sollte man doch mit dem allgemeinen Schlüssel in jede andere Verbindung in dem Netz reinschnüffeln können. (Bsp.: Cafe mit verschlüsseltem WLAN, das den Schlüssel an Gäste herausrückt)
Erst mit einem RADIUS-Server sollte jeder Client eine wirklich eigene Route zum Server bekommen oder (Wenn man RADIUS mit WPA2/AES als Chiffre zum laufen bringt)?
Aber, wie gesagt, bin mir da nicht sicher drin – Korrekturen sind geren willkommen :)
also Facebook kann ich zwar mit https aufrufen aber sobald ich IRGENDWAS mach (ein Profil aufrufe oder so), bin ich wieder auf http – oder mach ich was falsch?
Die Frage bzgl. des HTTPS-Everywhere plugins von EFF, die die Tage schonmal aufkam: soweit ich weiß arbeitet das Plugin nur bei direkten requests, leitet also beim direkten Ansteuern von FB auf SSL um, tut dies aber nicht mit den FB Social Plugins, d.h. hier besteht nur scheinbare Sicherheit. Das einfach Besuchen einer Site, die diese Plugins benutzt, würde die Cookies wieder offenlegen.
Btw, Dropbox ist hiervon nicht betroffen, auch wenn’s im Artikel steht.
Zunächst mal dürfte das Tool nicht auf Linux funktionieren, weil zum Mithören des Netzverkehrs Root-Rechte erforderlich sind – allerdings verhindert das prinzipiell den Angriff nicht, sondern erschwert ihn nur für unbedarfte Anwender.
Weiterhin möchte ich mal GMX explizit zur Liste der Bösen Anbieter hinzufügen: Man kann manuell per https zum Login gehen, alle nicht-zahlenden Kunden werden dann aber bei jedem Klick ins http zurückgeschickt (eventuell hilft hier das kürzlich auf heise vorgestellte https-everywhere).
@Chuck: In einem WPA-geschützten Netz (ganz gleich ob Radius oder PSK) wird ein sogenannter „pairwise“ Schlüssel mit jedem Netzteilnehmer ausgehandelt. Somit kann jeglicher Unicast-Traffic nur vom AP und vom „richtigen“ Client mitgelesen werden.
Schützen kann man sich einerseits durch Https-Everywhere oder auch durch Force-TLS, beides sind Firefox-Addons…
@Thomas (7) Naja, das ist ja die Frage. Beim WPA-PSK (Pre-Shared-Key) ist der PMK (Pairwise Master Key) ja gerade der statische Schlüssel, den man auf jedem Gerät für den Zugang eintragen muss, oder (bzw. korrekter: der Schlüssel wird aus Passwort und SSID gebildet)?
@Chuck: Nein, der AP handelt mit jedem Client einen eigenen, individuellen Key aus.
Hey – der Artikel macht zwar auf das Thema aufmerksam. Es gibt allerdings noch genug andere Angriffsmethoden um an die Daten zu gelangen.
In verschlüsselten WLAN Netzwerken kann ich problemlos durch MITM Attacken den Netzwerkverkehr mitlesen, dafür muss ich allerdings dort angemeldet sein.
Aber ein „Profi“ kann auch dies ganz einfach umgehen: Man gibt sich selber als AP aus und *schwupps* verbindet sich der Client mit deinen Rechner ;)
HTTPS Zertifikate kann ich auch faken, wenn ich nicht im Besitz eines gültigen Rootzertifikates bin erscheint zwar eine Sicherheitsmeldung, aber die klicken eh 90% der Anwender weg…
Auch NoScript (IMHO ein Pflicht-Plugin für Firefox) kann HTTPS für eingetragene Seiten erzwingen. Das Ganze ist etwas versteckt in den Optionen unter „Advanced“ und dort „HTTPS“, aber sehr nützlich.
Aber wer Facebook nutzt möchte doch ohnehin ausgespitzelt werden, oder nicht? :-P
@Chuck, Kevin: Wer Kenntnis des PSK hat kann sich allerdings als AP ausgeben und somit alles mitlesen, dann durch eine weitere WLAN-Sitzung an den echten AP weiterleiten.
Außerdem meine ich mich zu erinnern, dass man durch mitschneiden des Handshake und Kenntnis des PSK den pairwise Schlüssel mit nicht allzu hohem Aufwand brute-forcen kann. Hier könnte ich mich auch irren, habe den WPA2 Handshake nicht eingehender studiert.
@Thomas: Wohl wahr, aber das ist dann wohl doch nicht so einfach im Firefox-Plugin zu machen. Für die hier beschriebene Demo sollte WPA(2) erstmal sicher sein.
Trotzdem gibt’s freilich reichlich weitere Angriffsszenarien.
Naja, noch mehr verfluchen sollte man z.B. studivz.net, die nicht mal ein https anbieten, dafür aber stolz mit ihrer Sicherheit werben: „Die VZ-Netzwerke sind das erste soziale Netzwerk, dessen Softwarequalität und Datensicherheit offiziell durch ein Zertifikat des TÜV SÜD bestätigt ist.“
Einfach unglaublich, wie soviel Inkompetenz noch vor sich hergetragen wird.
Aber nicht, daß jetzt alle denken, mit HTTPS sei man nun automatisch auf der sicheren Seite …
Aus diesem Grund ist mein WebServer so eingestellt, dass er immer auf HTTPS umleitet.
Nicht nur bei Sachen mit Logins interessant, auch z.B. bei Google Search / Wikipedia, damit keine mitliest.
Und ich werd mich auch immer dafür einsetzen, dass dies bei Projekten in denen ich arbeite umgesetzt wird.
@Kevin & @Thomas
OK, danke für Aufklärung. Dann ist WPA(2) mit bekanntem Schlüssel doch etwas sicherer gegen Sniffen als ich befürchtet hatte (jedenfalls scheint der Aufwand zum Mitschnüffeln ein wenig grösser zu sein als nur das Wissen des PSK)
Naja, in offenen & fremden verschlüsselten WLANs tunnel ich dann doch weiter zu meinem Router, auf dem ein kleiner PPTP-Server läuft… (bevor Einwände kommen, dass PPTP ein lausiges Protokoll ist: stimmt sicher, aber meine Experimente mit OpenVPN waren immer etwas nerviger/aufwändiger)
Das Problem mit Facebook ist auch, dass wenn man über HTTPS zugreift der Facebook-Chat nicht mehr funktioniert.
@ir: Danke für die Info. Das erklärt so einiges (warum bei mir der Chat z.B. nie da ist)…
@Jupp (15)
StudiVZ erreicht man per https über
https://www.studivz.net/
allerdings ist das Zertifikat auf secure.studivz.net ausgestellt und dort antwortet der Server nicht…
Fuer oeffentliche Cafes die Option „AP Isolation“ einschalten. Das verhindert den groebsten Unsinn, weil ARP und andere Broacasts *nicht* vom AP fuer alle angemeldenten Clients sichtbar wiederholt werden. Und WPA mit Pre-Shared-Key verhindert das AFAICR nicht – es muesste schon WPA-Enterprise (das mit dem Radius) sein.
@Sven-Ola: Sorry, aber dein Kommentar zeugt von leichtem Unverständnis. Es ist ganz egal was an wen gesendet wird, solange die Verbindung unverschlüsselt (oder WEP) ist – dann kann nämlich jeder alles lesen.
Bezüglich der Broadcasts gibt es auch keinen Unterschied zwischen den diversen WPA-Modi. Broadcasts werden immer mit dem „group key“ an alle Clients gesendet.
Die AP Isolation kann bei einem verschlüsselten WPA Netz schon nützlich sein, allerdings gibt es recht wenig Angriffspotential durch das Mitlesen von Broadcasts (abgesehen von ein paar sehr aufwendigen und obskuren ARP Spoofing Angriffen).
Für Google Chrome gibt es https://code.google.com/p/kbsslenforcer/
mfg
Weiß einer eigentlich warum es Verschlüsselung und Zertifizierung bei HTTPS nur im Doppelpack gibt? Eine Verschlüsselung allein ist ja schon ein enormer Sicherheitsgewinn, gegenüber normalem HTTP.
Trotzdem zeigen die meisten Browser bei HTTPS hysterische Fehlermeldungen an, wenn der Zertifikat-Austeller nicht bekannt ist; bei HTTP, wo es ja überhaupt keine Authentifzierung gibt, allerdings nicht.
Ich denke, dass Verhalten trägt auch zur Unbeliebtheit von https bei.
„Der Grund dafür ist (vermutlich) dass beim Verschlüsseln ein (heutzutage vernachlässigbarer) zusätzlicher Rechenaufwand für den Server anfällt.“
Oder bei kleineren Anbietern, das meiner Meinung nach unverschämt teure SSL-Zertifikat.
@26 Kinch
Das ist so, weil der Benutzer des Browser bei der ersten Annahme eines selbst-signierten Zertifikates gar nicht genau wissen kann, ob er wirklich mit der richtigen Website verbunden wird.
@26: Die Authentifizierung ist notwendig, sonst wäre über eine MITM-Attacke wieder das Mithören möglich – trotz https.
Die Unbeliebtheit kommt möglicherweise daher, dass sich eventuelle Warnhinweise nur auf extrem bescheuerte Art und Weise übergehen lassen.
[Warum kommt das Captcha eigentlich beim ersten Abruf nicht?]
So ein Quark, WLAN-Verschlüsselung (wie man es zu Hause hat mit geteiltem Schlüssel) schützt nicht vor anderen WLAN-Teilnehmern, sondern nur vor Leuten, die den WLAN-Key nicht haben.
Der Angriff funktioniert auch in verschlüsselten WLANs, wo alle den selben Schlüssel haben. (Firmen-WLANs mit persönlichen Login-Daten sind was anderes.)
@earl Falsch, siehe die obigen Kommentare dazu.
Also wie der Titel über https schon betont, wollte ich eigentlich keine Diskussion über Funknetzwerke entfachen.
Egal, ob ich mich in einem RADIUS-verwalteten WPA2 befinde und über VPN irgendwo noch einmal ‚raus‘ gehe: Irgendwann kommt der Punkt, wo mein Traffic in den Weiten des Internet herumschwirrt, und (siehe mein kleines Traceroute-Beispiel) x mal weitergeroutet wird.
Und an dieser Stelle hilft mir nur noch https(, SSL, GPG, …). Ebenso an vielen anderen Stellen. Dass Fefe korrekt vor einiger Zeit in seinem Blog und auch im neuen Podcast auf das Problem, dass es wahrscheinlich mehr nicht-vertrauenswürdige „vertrauenswürdige CA’s“ als vertrauenswürdige „nicht-vertrauenswürdige“ Zertifizierer gibt, hinweist, heißt nun wirklich nicht, dass man auf https grundsätzlich verzichten sollte. [ironie] So lang es ohnehin kaum jemand nutzt, brauchen wir uns um das Problem erstmal weniger zu kümmen. Das kommt dann, wenn erstmal alles https ist.[/ironie]
@Chuck (21):
nach dem einloggen wird man da aber wieder auf die normale http-Seite umgeleitet!?
Entschuldige, dass ich die Diskussion dennoch ganz kurz fortsetze:
@earl: Erklär mir mal, wie ich als Teilnehmer eines WPA-Netzes den Traffic anderer Teilnehmer mitlese. Ich denke Kevin und ich haben die Situation oben sehr genau dargelegt – wenn du uns widersprechen willst, dann sei bitte detailierter als „so ein Quatsch“. Die einzige mir bekannte Möglichkeit ist die von mir oben beschriebene „AP in the middle“ Methode, die aber in Praxis schwer zu realisieren ist, da nur eine 50% Chance besteht, dass ein potentieller Client sich am „bösen“ AP einloggt und sie einfach zu erkennen ist, da plötzlich 2 APs mit derselben SSID da sind.
Zurück zu SSL: Die Hinweise vom oben geposteten fefe-Link sind sicherlich wertvoll. Die Browserhersteller erzeugen außerdem beim Benutzer ein falsches (Un)Sicherheitsgefühl: Bei einer verschlüsselten, aber unauthentifizierten Verbindung wird eine Riesen-Paranoia erzeugt, während eine unverschlüsselte Verbindung ohne Warnung hergestellt wird. Um Sicherheitsbewusstsein zu schulen, sollte vor unverschlüsselten Verbindungen grundsätzlich gewarnt werden, und zwar noch mehr als vor unbekannten Zertifikaten.
firesheep ist für Klartext-Verbindungen wie eine Kettensäge für Bäume, jeder wird zum Holzfäller. (Frei nach WeldPond: http://twitter.com/WeldPond/status/28756804477)
@ ir(20) und markus (22):
die erfahrung mit dem verschwinden des facebook-chats hab ich auch bemerkt, was mich dann dazu gebracht hat, facebook bei trillian mit einzutragen. allerdings will der client für meinen geschmack zu viele informationen haben, die ich nach jedem einloggen manuell in facebook deaktivieren muss. so komme ich zwar in den chat, aber nervig ist es trotzdem. dafür hab ich noch keine lösung gefunden, aber deaktiviert wird trotzdem jedes mal. ;-)
ach ja, noch eine frage zu force-TLS: kann man das gleichzeitig mit https-everywhere laufen lassen? ist das eine empfehlenswerter als das andere? direkt mit der meldung gestern hab ich mir https-everywhere installiert, würde aber natürlich ganz gerne die bestmögliche variante wählen. ;-)
„Der Grund dafür ist (vermutlich) dass beim Verschlüsseln ein (heutzutage vernachlässigbarer) zusätzlicher Rechenaufwand für den Server anfällt.“
Das stimmt nicht. Als Anbieter kann ich dazu sagen:
Der Grund ist vor allem die Bevormundung durch bestimmte Browser bei „gemischten Content“ (z.b. eine SSL-Seite, die Nicht-SSL-Bilder embedded), d.h. die fetten Warn- und Fehlermeldungen, die dann kommen. Klar – damit kann sich u.U. nachvollziehen lassen, auf welcher Seite ein Nutzer ist und möglicherweise kann ein Anbieter sich auch selbst in den Fuß schießen damit und doch wieder ein unsicheres Angebot darüber schaffen.
Das Problem, gerade bei Web 2.0 Angeboten ist aber, dass die Nutzer erwarten, dass sie Kram von anderswo embedden können – das musst du dann effektiv verbieten mit SSL. Alternativ hast du einen wartungstechnisch albtraumhaften Parallelbetrieb von Nicht-SSL-Seiten (alles mit User Generated Content) und SSL-Seiten (alles andere), der letztendlich doch wieder irgendwo die Session-IDs leaked. Also machen die Anbieter dann bestenfalls die Minimal-Lösung: Passwörter über SSL-Server übertragen, den Rest unverschlüsselt. Selbst ohne Embedding hast du das Problem halt, weil du dann wirklich im kompletten Stack überall SSL brauchst, also vielleicht z.b. auch bei deinem Content Delivery Network. Sicherlich nicht unlösbar, aber eklig.
Das Sicherheits-„Feature“ der Warnungen bei gemischten Content verhindert also gerade im Moment die großflächigere Migration zu SSL. Würden die Browserhersteller das Problem endlich mal kapieren, würde vielen Anbietern die Umstellung – in ein paar Jahren wenn die Änderung auch auf die installierte Basis der Browser durchschlägt – wesentlich leichter fallen.
(Fairerweise muss ich sagen, dass ich vielleicht nicht ganz auf dem neuesten Stand bin. Mag sein, dass sich die Situation mittlerweile verbessert hat – mit IE6/7 war das Problem jedenfalls noch akut gegeben. Wir evaluieren sowas auch nur einmal im Jahr oder so, ob ein weiterer Umstieg sinnvoll ist – bei der letzten Prüfung war genau das oben beschriebene Problem das Hauptproblem).
Ach ja. Es wär sowieso mal ein Anfang, wenn man wenigstens Passwörter bei Mobile-Webseiten defaultmäßig verschlüsseln könnte. Kann man nicht, weil die Handys teilweise SSL gar nicht, oder nur vollkommen willkürlich ausgewählte Zertifikate fressen. Viele Social Network Anbieter verschlüsseln dort dementsprechend oft nichtmal die Passwörter, andere bieten 90er-Jahre-Style Umschalt-Links an….
@Markus Peter: Du sprichst mit aus der Seele. Das war mein erster Gedanke, als ich über den Satz mit dem „zusätzlichen Rechenaufwand“ (der schon seit PII-Zeiten praktisch unter den Tisch fällt) gelesen habe.
Das Hauptproblem bei HTTPS sind der Zertifikat-Terror der Browser-Hersteller und die Politik der kommerziellen CAs, die eine Verschlüsselung ohne Authentifizierung nicht zulassen – und ich glaube kaum, dass sich daran so schnell etwas ändern dürfte.
OpenID (https://myopenid.com) wäre ein guter Ansatz, wenigstens für Login-Daten, aber selbst das wird kaum unterstützt.
muss zum sniffen die wlan-nic nicht den monitor mode unterstützen? soviel ich weiß geht der bei den centrino-lappis (z.b. 3945abg) nicht… und centrino´s sind ja bekanntermaßen recht weit verbreitet…
Google Search mit TLS: https://encrypted.google.com
Auch eine feine Sache. ;-)
Github schaltet (zumindest bei mir) automatisch auf https um, auch ohne eingeloggt zu sein.
@R. Nitsch (40) und @RCL (17):
… und das versteckt jetzt eure Query-Strings (also das wesentliche in einer Google-Suchanfrage) auf welche Art?
m(
Autsch, das ging daneben. Ich ziehe meine letzte Aussage zurück. Der Host ist die einzige „Ortsangabe“, die bei HTTP-over-TLS noch sichtbar ist, wie man bspw. hier schön sehen kann:
http://mattfleming.com/node/289
@dustbunny (43,44):
Ja, wie du inzwischen bemerkt hast sind bei HTTPS sowohl deine Anfragen, als auch die Antworten vom Server verschlüsselt.
Das einzige das jemand der mitlauscht noch mitbekommt ist, mit welchem Server du komunizierst, und dass ein verschlüsselter Informationsaustausch stattfindet.
–
https://encrypted.google.com/ ist ja mal toll. Gibt es dafür ein Firefox Searchplugin?
Viiiiiel zu späte antwort, aber falls irgendwer das noch sieht:
Einfach about:config auf, und in keyword.URL folgendes reinhauen:
https://encrypted.google.com/search?ie=UTF-8&oe=utf-8&q=
Done.
Andy Greenberg berichtet jetzt von FireShepherd, einem Tool eines isländischen Hackers, das Firesheep unbraucbar macht, mit Link zum Runterladen:
http://blogs.forbes.com/andygreenberg/
Zum Thema Firefox-Plugins: Ich habe HTTPS-Everywhere nicht installiert (werde es aber mal bei Gelegenheit ausprobieren). Der Vorteil von Force-TLS ist dass es automatisch reagiert, sobald es einmalig per HTTPS mit einem Server verbunden war, der mitteilt, dass nur HTTPS verwendet werden soll (HTTP-Header „Strict-Transport-Security“). Der Konfigurationsaufwand für Endnutzer ist also quasi gleich null, und es ist auch nicht auf irgendwelche Listen angewiesen.
@27/gulbim: Die unverschämt teuren SSL-Zertifikate gibt es auch komplett umsonst, oder auch als „Flatrate“ für beliebig viele Domains (inkl. Wildcards) für 50$/2 Jahre:
https://www.startssl.com/
Startcom ist meines Erachtens der einzige Anbieter, der das System ehrlich praktiziert: Die Authentifizierung kostet einmalig Geld, danach kannst Du beliebig viele Zertifikate erstellen.