Förslag: Stänga av SSL

För att det är en säkerhetsfråga. Utan SSL finns det noll skydd mot exempelvis spoofing eller avlyssning, något som kan vara extremt viktigt för anonymiteten på flashback. Att då kunna slå av den öppnar upp onödiga risker för användarna, något som man nog vill undvika.

Angående att problemet skulle ligga hos flashback och inte hos dig, hur vet du det? Hittills är du den enda personen som klagat vad jag märkt, av den här tråden att döma. Men vi får väl se om fler med samma problem hittar tråden.

Surfar helt problemfritt på FB med en SGS2 så problemet ligger sannolikt lokalt hos TS.

Zom: På vilket sätt öppnar det säkerhetsproblem hos användarna, om man har ett klickbart lås för att stänga av/på SSL, och att man har domänen http://nossl.flashback.org för icke-SSL?
Samtidigt som standard http://www.flashback.org redirrar till SSLen som vanligt.

Det finns ju ingen risk för att användaren råkar gå in på sajten utan SSL utan att manuellt klicka på det låsta hänglåset så det låses upp, eller att de manuellt skriver http://nossl.flashback.org eller att de manuellt har ett bokmärke till http://nossl.flashback.org ?

Naturligtvis ska inte inställningen för låset sparas i någon cookie, utan varje gång man vill besöka utan SSL så får man skriva http://nossl.flashback.org eller besöka SSL-varianten och klicka på låset.
Detta tar då bort risken för att besökaren innan tex stängt av SSL på en skoldator, för nästa gång en användare går in så är SSL på igen (om inte denna användare vill köra utan SSL med nossl)

Att man klickar på låset av misstag, den risken kan vi utesluta. Klickar man på låset av misstag är det ju lätt att märka och då kunna klicka på låset en andra gång för att stänga det igen.

Logincookies fungerar inte cross-domain så ytterligare en säkerhetsfunktion - varje gång man växlar mellan SSL och icke-SSL så blir man urloggad.


Så vad är säkerhetsproblemen?

Det utgör en onödig risk för användare som inte vet vad de pysslar med, och riskerar att de får sina konton kapade eller sin identitet röjd. Risken är kanske minimal, men jag ser inte riktigt varför man ens skulle ha det som alternativ.

Exempelvis skulle man då kunna spoofa nossl.flashback.org, vilket gör att användare som använder den sidan aldrig vet vems server som svarar på förfrågningen. Det finns ingen verifiering att de använder den riktiga sidan och det finns inte heller någon kryptering på trafiken.

Till viss del får väl folk skylla sig själva, men varför ska flashback tillhandahålla pistolen som de kan skjuta sig själva i foten med?

Fixa så din telefon fungerar korrekt istället.

Kör Samsung Nexus Galaxy med ICS 4.0.2 och det fungerar perfekt att surfa på flashback.org

// rancor

Tycker TS borde återställa sin telefon och sedan testa att ansluta igen. Då det fungerar för andra och inte för dig.

Zom: Det finns andra scenarion där det är användbart också. Tex på en del arbetsplatser och skolor har man börjat blocka TCP/443 utåt helt och hållet, bara för att elever inte ska surfa på proxysidor - även om flashback kanske är en jättebra informationsresurs för skolarbeten och vissa arbetsplatser ibland.

Tycker att man kan tillhandahålla alternativet, sedan är det upp till användarna hur de vill använda det. Vill en skola/arbetplats specifikt blocka flashback så slänger dem in nossl.flashback.org i brandväggen bara, så vi hindrar inte folk från att blocka om de vill.

Så skolor stänger av 443 enbart på grund av Flashback?
Inte så troligt.

På det stora hela så är det bra jobbat men jag måste ändå ge typ 3 av 10 för bra SE försök här....

Det finns ingen bra anledning till att FLB skulle gå no SSL...

justitieombudsman: Nej du missförstod mig. Vad jag menar är att en del skolor stänger av TCP/443 utgående för att hindra elever från att använda typ hidemyass , thecloak och liknande webbproxys.

Dock åker då flashback med av bara farten.

Därför jag föreslår att man inför nossl-funktion så man valfritt kan stänga av SSL. Om nu en skola *specifikt* vill blocka flashback utöver sin SSL-blockfunktion så är det lätt för skolan att då blocka http://nossl.flashback.org om flashback inför nossl-funktion.

justitieombudsman: Fortfarande, funktionen är valfri, altså om du vill fortsätta surfa SSL så kan ju du göra det. Så förstår inte varför du motsätter dig möjligheten att stänga av SSL om man VILL. Tycker man borde respektera individens vilja gällande SSL och inte tvinga på alla SSL. Låt alla få välja om de vill ha SSL eller inte. Om redirren från http://www.flashback.org till https://www.flashback.org ligger kvar, samt att http://nossl.flashback.org införs, så är det ju SSL per default, altså kan man inte "råka" gå in på nossl av misstag.

nossl kräver då en aktiv handling av användaren att antingen besöka http://nossl.flashback.org via ett bokmärke eller genom att skriva adressen, alternativt klicka på det låsta hänglåset.

Bra scenario, men om dessa skolor eller arbetsplatser blockerar 443/tcp utåt så är det knappast flashbacks problem. Då har ju snarare administratören som satte den policyn endera en riktigt bra anledning eller så är den helt dum i huvudet. Vill man så får man väl då prata med administratören och förklara varför de borde ta bort spärren på port 443.

Då tycker jag att det är rätt dumt att flashback skulle öppna upp en risk för användarna, även om vi nu förutsätter de användarna som påverkas nu skulle vara både medvetna och villiga att ta den risken, bara för skolors eller företags policy. I just det här fallet tycker jag då att ett bättre alternativ vore väl om man erbjöd en endast läsbar version av sidan som inte använde SSL. Vill någon logga in och skriva ett inlägg måste de då göra det över SSL.

Men vad är det för risk?

Som funktionen är föreslagen ska den altså ligga på 2 separata domäner. Det betyder altså att om du är inloggad på flashback, och sedan (medvetet eller av misstag) växlar till icke-SSL (eller från icke-SSL till SSL) så kommer din dator aldrig att skicka cookien till den domänen och då blir du utloggad.

Och är man urloggad så kan ju ev avlyssnare inte se att du är medlem på flashback ens. Dvs ingen chans att få identiteten röjd.

Det krävs altså 2 aktiva handlingar för att få sin identitet på flashback röjd, eller att få sitt konto på flashback kapat, plus att det krävs ett tredje scenario också:

1: Du måste besöka http://nossl.flashback.org på något sätt, antingen manuellt eller genom att klicka på låset.
2: Nu oavsett så kommer du bli urloggad. Du måste logga in igen för att du ens ska ha risken att få din identitet röjd eller kontot kapat. Det betyder att skulle man klicka på låset så blir man gäst och man märker misstaget och har chans att rädda det hela innan något allvarligt händer.
3: Det tredje scenariot: Det måste finnas någon på tråden som är intresserad av att få din identitet röjd eller att kapa ditt konto, som ligger och lyssnar just nu.

Och hur stor är risken för 3? i stort sett 0.

Om man nu är så rädd för att någon ska göra misstag, ha en popupruta när man trycker på låset: "Du kommer nu växla till en version av flashback som inte använder sig av skyddad anslutning. Vill du fortsätta? ja/nej"
Det är lätt att fixa en sådan ruta i javascript med en onclick på href:en.

Det handlar inte om att folk är inloggad på en plats och sen råkar byta till den andra. Vad det handlar om är att de besökarna som skulle köra utan SSL inte med säkerhet kan veta om det är flashbacks servrar som svarar eller vem som kan råka lyssna på det hela. Oavsett om de är medvetna om riskerna så är det onödigt från flashbacks sida att erbjuda dessa användare att skjuta sig i foten på det viset.

Risken är omöjlig att bedöma, men vid exempelvis flygplatser, café eller arbetsplatser kan då vem som helst som önskar helt enkelt spoofa nossl.flashback.org, och sen samla upp de inloggningsuppgifter som användare anger. Det behöver inte ens vara i realtid för att vara en risk. Den risken elimineras helt med att tvinga SSL för inloggning.

Så vad har vi då? Två risker, en som är "i stort sett noll" (eller okänd med bättre ord) jämfört med "garanterat noll" (om ingen också lyckas knäcka certifikatet). Vilken tycker du låter säkrast?