Uppdatering: nu är det enkelt att skydda Facebook. Gå till dina inställningar, välj ”Account security” och kryssa i att https ska användas.
Delar av internetvärlden, och massmedia, är i ett tillstånd av chock och panik. För resten av oss har det bara varit en tidsfråga. Att man kan kapa cookies som sänds okrypterade över trådlösa nätverk kommer inte som en överraskning. Det som är nytt är att Eric Butler satt ihop en plugin som gör att vem som helst kan göra det. Firesheep är så enkel att min mamma fixar det. ”Allemans-kapning” som @claes så träffande uttrycker det. Lyckligtvis är inte fixen så mycket svårare.
Notera: även om du inte bryr dig så mycket för din egen skull bör du ändå vidta åtgärder för att skydda dig. Genom access till din inloggning exponerar du också dina vänner på ett sätt som de kanske inte önskar. Be a good netizen och ta ditt ansvar.
1. Se till att all information skickas över SSL, där det är möjligt. Du har säkert sett det in action, webbadressen inleds då med https istället för http. Det här låter kanske som fikonspråk för dig, men oroa dig inte. Det enda du behöver göra är att installera en plugin i den webbäsare som löser det här. Jag kör Chrome och då funkar KB SSL Enforcer utmärkt. För Firefox rekommenderas tydligen Force TLS. Jag återkommer med förslag för Safari och IE, om det finns sådana. För Chrome och Firefox är det i alla fall bara att installera pluginen, följa anvisningarna – så är du säker mot #firesheep.
Uppdatering, i kommentarerna diskuteras inställningarna av de här skydden. Se till att du ställer in dem manuellt, lägg in www.facebook.com och facebook.com i ”whitelist” (motsv). Förlita dig inte på att de löser det automatiskt, då sker en första uppkoppling utan skyddet aktiverat och du kan drabbas ändå.
Uppdatering 2: än värre, tecken tyder på att skyddet i Chrome inte kickar in direkt, oavsett hur man konfigurerar det. Se kommentarerna nedan.
2. Om du inte reder ut ovanstående, stanna på din 3G-uppkoppling tills du fått hjälp med #1. Undvik öppna, trådlösa, nätverk.
3. På vissa tjänster, tex gmail, kan du gå in i inställningarna och klicka i att den alltid ska använda SSL, där behövs ingen plugin. Men det skyddar alltså inte Facebook, Twitter och många andra tjänster som du loggar in på. Tillbaka till #1 igen alltså.
Ingen anledning till panik alltså. Däremot får du gärna smälla till tomtarna på Facebook och Twitter för att de inte gjort något åt det här för länge sedan. Firesheep var bara en tidsfråga…
Men det viktigaste av allt har jag sparat till sist. Och det här är viktigt. Om något är riktigt, riktigt viktigt för dig – digitalisera det inte, och ägna dig inte åt det på offentliga platser. Men så kan man ju inte hålla på… ;)
Mer:
Bra från Jeroen Wolfers.
Mindre bra, expressens tips. På andra plats: ”Om du loggar in på dessa konton – undvik Firefox.” WTF?
Uppdatering: Jag tänker om och pushar för bästa lösningen. Läs mer om VPN.
Tack för bra inlägg! Men har jag förstått rätt att det är bara via öppna WIFI nätverk som risken finns? Om jag kör via 3G telefon eller skyddat nätverk så är det lugnt.
Japp, så är det. (för just det här problemet iaf ;)
Det är inte lugnt. Hotbilden ser bara annorlunda ut. Du vill ha end-to-end-kryptering. Alltid och av allt.
Ungefär som jag sa till @emanuelkarlsten på twitter nyss – det finns massor som behöver göras och som äntligen kommer börja ske maa det här. Men här och just nu gäller det att ordna med #firesheep damage control. Ingen kan köra firesheep på ett WPA-nät, eller om du är uppkopplad med din 3G-dongel. Eller hur?
Korrekt, så länge du inte kan WPA-lösenordet, vilket typiskt är fallet på ett kontor t ex.
http://wiki.wireshark.org/HowToDecrypt802.11
Fast inte med just Firesheep. I ett WPA-PSK-nät används så kallade pairwise master keys samt pairwise transient keys, och man måste ha lyckats fånga utbytet av dessa – utöver att kunna det delade lösenordet – för att kunna avkryptera frames. Det är inget som Firesheep gör i dag. Det betyder inte att det inte går.
http://en.wikipedia.org/wiki/IEEE_802.11i-2004
Om jag inte har missat något grundläggande så löser inte KB SSL Enforcer problemet. Du kan läsa på extension-sidan:
Det innebär att när du i Chrome (med KB SSL Enforcer aktiverad) klickar på en http-länk till Facebook (i ett mail från Facebook, t ex) så kommer webbläsaren först att skicka en request till http://www.facebook.com/ innan extensionen snappar upp det och omdirigerar dig till https://www.facebook.com/. I den första requesten kommer dina kakor på facebook.com-domänen att skickas okrypterat över nätet, redo att ätas av kakmonstret.
Chrome behöver fixa issue 50943 innan det går att implementera funktionalitet motsvarande EFF:s HTTPS Everywhere, som jag skulle rekommendera över Force-TLS om du måste välja (även om det inte skadar att ha båda).
Men åh. Varför lägger Disqus in en massa br-element i kommentarerna. Det blir ju inte så snyggt. Strippar cite-attribut från blockquote-element gör de också. Hur tänkte de då?
Jag kanske inte var tillräckligt tydlig med att man ska läsa instruktionerna. Poängen är att inte förlita sig på autodetect utan att i inställningarna lägga till de sajter som är känsliga i whitelist. Jag ska uppdatera posten.
Whitelist räcker inte när det gäller SSL Enforcer. Den hugger inte in förrän en request redan är skickad.
Korrekt. Här är en TCP-dump från Wireshark där man tydligt ser Facebook-kakorna i ett HTTP-anrop från en Chrome med KB SSL Enforcer aktiverad och Facebook vitlistad för HTTPS:
https://skitch.com/aehn/d7f1y/follow-tcp-stream
Fungerar denna till Chrome bättre tro?
http://github.com/nikcub/Force-SSL
Som jag förstått det så skriver det tillägget om cookies att inte skickas över en okrypterad uppkoppling.
Första gången t.ex. facebook.com anropas skickas cookies okypterat, men skrivs då om så nästa gång facebook.com anropas bör man vara säker (enligt utvecklaren).
Kan du bekräfta det?
Jag ser inget i källkoden som överhuvudtaget har med cookies att göra, så jag lutar åt ett nej.
Stämmer. Om jag skriver “facebook.com” i mitt adressfält, med SSL Enforcer igång, hinner Chrome skicka min sessionscookie allra minst 2 ggr innan jag är överflyttad till https.
Om Facebook såg till att sätta secure-flaggan på cookien (så att den aldrig ska skickas med en icke-krypterad request) om man loggar in via https skulle det vara ett lite mindre problem. Men med tanke på att de helt idiotiskt strösslar sidorna med hårdkodade http-länkar även när man kör SSL kanske man inte ska hoppas för mycket.
Det sura är bara att en SSL-anslutning kräver fem roundtrips av TCP-paket för att etableras, istället för två roundtrips för en icke-ssl-anslutning. Detta betyder att om man sitter på en lina med dålig ping så blir det fruktansvärt trögt. Det och att lirare som facebook skulle behöva köpa en jäkla massa extra servrar för att göra alla extra beräkningar. Men aja, det är väl dit vi måste till slut, ett nät där allt körs i SSL-tunnlar. Kanske vettigt med tanke på FRA osv. :)
In January this year (2010), Gmail switched to using HTTPS for everything by default. Previously it had been introduced as an option, but now all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy no additional machines and no special hardware. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that.
If you stop reading now you only need to remember one thing: SSL/TLS is not computationally expensive any more.
http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
Problemet med SSL och Google är att om man t ex sitter i Sverige så skickas man automatiskt till google.se när man ska göra en sökning. Denna domän har inget SSL-certifikat och man får då frågan från sin webbläsare om huruvida man vill fortsätta till den osäkra sajten. Problemet, om man är inloggad på Gmail, är då att cookies som hanteras av Google när man besöker google.se fortfarande är öppna. Så Googles SSL-hantering är mycket bristfällig.
Läs mer på http://www.bluebirdsolutions.se/?id=3&blogid=400&rub=Falsk+trygghet+med+Google:+Gmail+och+HTTPS/SSL
Filip, Andreas och ni andra. Kan detta fungera till Safari? http://blog.diktator.org/index.php/2010/10/26/glimmerblocker-filter-against-firesheep/
Det ser ut att fungera fint om man installerar prenumerationen som också finns föreslagen på sidan. Programmet dirigerar då om webbläsaren till https i istf http.
KB SSL Enforcer fungerar inte på den allra första uppkopplingen till sidan, och beror på en begränsning i Google Chrome’s stöd för tillägg. En bugg finns öppen för det här problemet däremot (Chromium issue 50943), och utvecklaren av KB SSL Enforcer har redan sagt att när det är fixat (tidigast i Chrome 9), så kommer han att uppdatera sitt tillägg för att stödja även detta, och därmed vara mer likställd det motsvarande tillägget för Firefox.
Kör via stationär dator, ADSL modem o fast anslutning, MS XP Pro sp2 o FF 5.0 – bör jag vara på min vakt? Inget trådlöst här inte!!!