Firefox 23 blokkeert standaard onversleutelde content op ssl-pagina's

Mozilla wil in Firefox 23 content die via http wordt opgeroepen voortaan blokkeren als de gebruiker een ssl-pagina opent. Volgens de browserbouwer wordt daarmee de veiligheid voor de eindgebruiker verder verbeterd.

In Firefox 18 introduceerde Mozilla al een instellingsmogelijkheid om het laden van content op http-verbindingen te blokkeren als er een pagina via https wordt geopend. Hierdoor zal Firefox geen onversleutelde scripts, css-bestanden en andere webcontent laden van normale webservers, omdat deze als potentieel onveilig worden gezien. Deze beveiliging was echter niet standaard geactiveerd, maar Mozilla wil deze in Firefox 23 voortaan gaan inschakelen. Hierdoor zullen bepaalde pagina's die standaard via https worden geopend wellicht niet correct getoond worden in deze browser, maar de keuze van Mozilla kan webontwikkelaars wel dwingen om fouten in de ssl-implementaties sneller te corrigeren.

Firefox 23, momenteel nog een vroege Nightly-testversie, zal in de JavaScript-verwerking voortaan beter rekening houden met landspecifieke instellingen. Dit kan een rol spelen bij het verwerken van bijvoorbeeld kalenderdata, tijd en tekst. Developers kunnen bij inputdialogen bijvoorbeeld 'nl' aangeven als locale. Mozilla wil Firefox 23 volgens de huidige planning begin augustus uitbrengen.

Reacties (31)

[FragFrog]

Niet heel bijzonder eigenlijk, andere browsers doen dit al langer (Chrome) of vragen de gebruiker eerst om toestemming (IE). Ik vraag me af hoeveel dit daadwerkelijk helpt: SSL pas je toch voornamelijk toe om te voorkomen dat je verbinding wordt afgeluisterd. Dat is belangrijk bij de connectie die bijvoorbeeld je username en wachtwoord naar de server stuurt, maar volslagen irrelevant voor de connectie die de standaard stylesheet en plaatjes serveert.

Nu zijn er wel een paar scenarios te bedenken waarin ook via overige content belangrijke informatie verstuurt wordt, maar dan heb je het al snel over vrij exotische scenario's. Ondertussen zorg je wel voor extra belasting op de webserver en content die langzamer laadt doordat SSL verbindingen langer duren om op te zetten.

[Reactie gewijzigd door FragFrog op 24 juli 2024 17:20]

[Eagle Creek]

Dat is belangrijk bij de connectie die bijvoorbeeld je username en wachtwoord naar de server stuurt, maar volslagen irrelevant voor de connectie die de standaard stylesheet en plaatjes serveert.

Het gaat niet om die stylesheets of afbeeldingen. Waar het om gaat is dat door onbeveiligde content op beveiligde pagina's te plaatsen, de beveiligde content mogelijk afgeluisterd kan worden.

Om de veiligheid te kunnen garanderen, is het noodzakelijk dat er een gehele veilige keten is tussen webserver en eindgebruiker. Door gebruik te maken van non-SSL items op SSL-pagina's, verbreek je deze "keten". De krux is dus niet dat je onbeveiligde afbeeldingen of stylesheets ontvangt, maar dat de beveiliging veiligheidsgarantie van de gehele pagina in het geding is.

Firefox waarschuwt hier ook voor:

"You have requested an encrypted page that contains some unencrypted information. Information that you see or enter on this page could easily be read by a third party."

Net als IE:

"Do you want to view only the webpage content that was delivered securely? This webpage contains content that will not be delivered using a secure HTTPS connection, which could compromise the security of the entire webpage."

Als gebruiker van een website, zie jij niet welke inhoud wel ge-encrypt is en welke inhoud niet. Zo zou het kunnen zijn dat je op een beveiligd website zit, maar vervolgens jouw creditcardgegevens in een onbeveiligd formulier verstuurt. Als dit formulier onderdeel is van de beveiligde website, zou je normaliter dit niet opmerken.

Normaliter loop je niet meteen enorm risico. Immers, een onbeveiligd verzonden afbeelding maakt niet dat Anonoymous je pc leegstruint. Maar zoals gezegd, weet je normaliter niet wat wel en wat niet veilig is. Daarnaast kan bepaalde informatie (sessie-id, cookies, etc) ook onversleuteld over de lijn gaan. En die informatie kan dan weer interessant zijn voor iemand die kwaad wil.

[Reactie gewijzigd door Eagle Creek op 24 juli 2024 17:20]

[FragFrog]

Wanneer het om verkeer afluisteren gaat kun je prima veilig een formulier via een onbeveiligde verbinding binnenhalen en alleen bij het versturen posten middels een HTTPS verbinding. Andersom kun je ook prima een pagina volledig over HTTPS binnenhalen, en het formulier versturen via een onbeveiligde verbinding. Een hacker heeft er niks aan om te weten hoe het creditcardformulier eruit ziet, wat hij wil is je gegevens, en die gegevens worden pas verstuurd bij het versturen van het formulier wat over een nieuwe connectie gaat.

Daarnaast is het ook vreemd te zeggen dat de 'keten' verbroken wordt: content verbindingen lopen parallel aan de beveiligde verbinding, niet in serie. Je kan prima gevoelige data over een beveiligde verbinding versturen terwijl je niet-gevoelige data (zoals stylesheets en afbeeldingen) over een normale verbinding verstuurt. Dat die twee naast elkaar bestaan hoeft absoluut niet te betekenen dat je beveiligde content ineens niet meer veilig is, of andersom, dat je beveiligde content te vertrouwen is: SSL is geen beveiliging tegen XSS of XSRF aanvallen, het voorkomt alleen MitM aanvallen (en zelfs dat niet eens perfect). In theorie kan een MitM aanvaller nog javascript code injecteren om zo bij je data te kunnen, maar dat is zowel onwaarschijnlijk (al zijn er wel tools voor) als niet van toepassing bij afbeeldingen en stylesheets.

Het klopt dat wanneer je gevoelige info in een cookie plaatst en vervolgens data binnenhaalt met een onbeveiligde verbinding, deze wel af te luisteren is, maar in dat geval staat je gevoelige info ookal als plaintext op de computer van de gebruiker, dus dit is sowieso een dijk van een beveiligingsrisico, ookal gebruik je wel overal SSL verbindingen. Op die manier helpt SSL een beetje tegen session hyjacking, maar daar bestaan betere technieken voor.

[Reactie gewijzigd door FragFrog op 24 juli 2024 17:20]

[MrVulcan]

Het is niet voldoende dat alleen de POST van een formulier beveiligd wordt, ook het formulier moet via een beveiligde verbinding worden binnengehaald. Het is namelijk prima mogelijk dat het formulier wordt aangepast, of een javascript wordt geinjecteerd dat je credentials afluistert. Lees dit artikel maar eens van Troy Hunt over SSL.

Daarnaast draait het ook om vertrouwen van de bezoeker van een website. Hoe weet ik als eindgebruiker dat mijn inloggegevens beveiligd verstuurd gaan worden als het inlogformulier via HTTP wordt binnengehengeld? Dat kan ik pas zien als ik daadwerkelijk inlog...

[Kewne]

Als een formulier over een onbeveiligde verbinding ingeladen wordt dan kan een aanvaller met MITM-mogelijkheid vrij simpel een script injecten dat alle gegevens onbeveiligd verstuurd (erg simpel door gewoon een <img> tag te injecten met een locatie die gegevens bevat). Ditzelfde gaat op voor scripts en sommige iframes die onbeveiligd geladen zijn. Dat is ook de beveiligingsfout die de middler tool misbruikt. En sslstrip doet het natuurlijk nog makkelijker.

Daarnaast kunnen onbeveiligde stylesheets ook al voor rare clickjacking-achtige situaties zorgen. De praktische aanvallen hiermee zijn over het algemeen vrij beperkt en zullen altijd site-specifiek opgebouwd moeten worden. Een mogelijk voorbeeld is het rond swappen van een "post" en "private message" text box/submit button met wat absolute positioning truukjes. De meeste gebruikers zullen het verschil niet zien of accepteren en toch komt een privebericht staat komt ineens publiek te staan.

[SlaSauS]

Niet heel bijzonder eigenlijk, andere browsers doen dit al langer (Chrome) of vragen de gebruiker eerst om toestemming (IE).

Jij hebt het over het versturen van een formulier naar een niet-ssl verbinding, dat werkt in Firefox hetzelfde als wat jij beschrijft over IE. Waar het hier over gaat is echter wat anders, namelijk een pagina die netjes over ssl wordt ingeladen (https in de adresbalk), maar die vervolgens content (image, css, js, iframe, etc..) inlaad die niet over https geserveerd wordt. Dit creëert dus een gat in de beveiliging. Overigens, zoals anderen hier al hebben opgemerkt, waarschuwt Firefox hier al voor door niet een normaal slotje te laten zien als er sprake is van mixed http en https content. Wat nieuw is aan deze wijziging is dat men deze elementen ook niet meer in de pagina gaat inladen.

Ik vraag me af hoeveel dit daadwerkelijk helpt: SSL pas je toch voornamelijk toe om te voorkomen dat je verbinding wordt afgeluisterd. Dat is belangrijk bij de connectie die bijvoorbeeld je username en wachtwoord naar de server stuurt, maar volslagen irrelevant voor de connectie die de standaard stylesheet en plaatjes serveert.

Na het inloggen zet een website vaak een cookie met een unieke token. Als deze vervolgens uitlekt doordat de cookie niet over https verstuurd wordt (bijvoorbeeld na het inloggen), dan kan men zonder dat ze jouw username of wachtwoord weten zonder problemen jouw sessie overnemen en is de aanvaller dus ook gewoon ingelogd in jouw account. Los daarvan, alles wat je stuurt/ontvangt, bijv. lezen van webmail etc kan dan prima gevolgd worden. HTTPS is dus zeker niet alleen bij inloggen relevant maar ook voor de rest van de sessie.

[FragFrog]

Waar het hier over gaat is echter wat anders, namelijk een pagina die netjes over ssl wordt ingeladen (https in de adresbalk), maar die vervolgens content (image, css, js, iframe, etc..) inlaad die niet over https geserveerd wordt.

Lees mijn post nog eens, en dan vooral de zin "volslagen irrelevant voor de connectie die de standaard stylesheet en plaatjes serveert.", voor je aannames doet over waar ik het over heb

Als deze vervolgens uitlekt doordat de cookie niet over https verstuurd wordt (bijvoorbeeld na het inloggen), dan kan men zonder dat ze jouw username of wachtwoord weten zonder problemen jouw sessie overnemen en is de aanvaller dus ook gewoon ingelogd in jouw account

Session-hijacking kan ook op andere manieren gedaan worden, en zoals ook op Wikipedia te lezen valt, is het gebruik van een SSL verbinding alleen niet genoeg om dat te voorkomen:

Encryption of the data traffic passed between the parties; in particular the session key, though ideally all traffic for the entire session[2] by using SSL/TLS. This technique is widely relied-upon by web-based banks and other e-commerce services, because it completely prevents sniffing-style attacks. However, it could still be possible to perform some other kind of session hijack.

Het probleem is dat sniffing aanvallen veel minder gebruikelijk zijn dan, om maar iets te noemen, trojans en virussen op de PC van de gebruiker plaatsen, of XSS / XSRF aanvallen. En juist dan helpt een SSL verbinding geen ene moer. Zolang je niet op een openbaar WiFi netwerk zit is het risico van een MitM aanval verwaarloosbaar, en geeft dat SSL icoontje in je URL bar alleen maar een gevoel van schijnveiligheid.

Vereisen dat alle content over een HTTPS verbinding gaat is dan ook een beetje een brute-force manier om beveiligingsproblemen aan te pakken, die welliswaar kan helpen wanneer een websitebeheerder zaken niet op orde heeft, maar uiteindelijk maar weinig helpt. Temeer daar ook een HTTPS verbinding niet per definitie 100% veilig is: er zijn genoeg gevallen bekend waar een beveiligingscertificaat gehijacked was en die ssl verbinding dus helemaal niet veilig was.

[Reactie gewijzigd door FragFrog op 24 juli 2024 17:20]

[SlaSauS]

Je kan prima gevoelige data over een beveiligde verbinding versturen terwijl je niet-gevoelige data (zoals stylesheets en afbeeldingen) over een normale verbinding verstuurt. Dat die twee naast elkaar bestaan hoeft absoluut niet te betekenen dat je beveiligde content ineens niet meer veilig is, of andersom, dat je beveiligde content te vertrouwen is: SSL is geen beveiliging tegen XSS of XSRF aanvallen, het voorkomt alleen MitM aanvallen (en zelfs dat niet eens perfect).

en

Lees mijn post nog eens, en dan vooral de zin "volslagen irrelevant voor de connectie die de standaard stylesheet en plaatjes serveert.", voor je aannames doet over waar ik het over heb

Cookies worden ook met "niet-gevoelige data" zoals jij het zegt, stylesheets, JS, images etc. meegestuurd. Op een open wifi spot kan een aanvaller dan heel simpel de JS aanpassen voor het bij jou aankomt. Zo voer jij wel degelijk code van de aanvaller uit, binnen de site waar je op zit (die deels dan misschien via SSL is ingeladen, maar dat is op dat moment niet langer relevant).

Het probleem is dat sniffing aanvallen veel minder gebruikelijk zijn dan, om maar iets te noemen, trojans en virussen op de PC van de gebruiker plaatsen, of XSS / XSRF aanvallen.

Juist met mixed content (dus JS over http inladen) maak je het de aanvaller dus makkelijk om een XSS aanval te doen.

Maar het gaat er hier niet over dat er naast SSL nog andere manieren zijn om een sessie te hijacken of dat virussen en trojans een veel groter probleem zijn dan sniffen. Waar het hier om gaat is dat als je geen (of mixed) SSL gebruikt er in ieder geval sowieso een deur openstaat en mensen op publieke wifi spots extra risico's lopen. Dat is de deur die Firefox hier dicht gaat zetten. Dat er nog andere gevaren en problemen zijn wil niet zeggen dat dit probleem (mixed content) niet ogelost hoeft te worden.

[Reactie gewijzigd door SlaSauS op 24 juli 2024 17:20]

[boner]

als het er al vanaf 18 in zit waar kan ik dat dan in 20 activeren? ik wil het NU!

[army]

Simpel, je gaat naar about:config en zoekt naar "security.mixed_content.block_active_content" en zet die op true.

[kamerplant]

Dus als je een beveiligd forum heeft en een gebruiker plaats een HTTP afbeelding, ben je geforceerd om alle content in HTTP in plaats van HTTPS te bekijken.
Dat is een bijzonder begrip van "veiligheid" dan.

[Oberon]

Je zorgt er uiteraard voor dat enkel de logon pagina (en evt andere pagina's die confidentiele informatie ontvangen) beveiligd zijn met HTTPS.

Waarom je HTTPS op een volledig forum zou zetten weet ik niet. Lijkt me een enorme verspilling van server resources (SSL/TLS is niet gratis) en vraagt gewoon om problemen bij user generated content.

[Verwijderd]

Met HTTP kan je steeds de session ids van andere gebruikers sniffen op het netwerk en zo hun sessie hijacken en content in hun plaats schrijven. De veiligheid is dus niet gegarandeerd.

[MadEgg]

Veiligheid garanderen kun je nooit, ook niet met https. In veel gevallen is een sessie ID niet van dermate belang dat dat een probleem is dat die mogelijkheid aanwezig is.

Je kunt je sessie ID natuurlijk altijd koppelen aan bijvoorbeeld de HTTP User-Agent string, het IP adres van de bezoeker, de lijst met geinstalleerde plugins, dat soort dingen. Dat maakt het al een stuk lastiger om te spoofen zonder je hele site over HTTPS te serveren.

[aileron]

logisch, het is per definitie een security issue. Als jij https ziet in je adres balk denk je veilig te zijn, maar dat is dus niet altijd het geval.
Hoop dat dit standaard wordt voor alle browsers in de toekomst.

[jarrin]

Er wordt nu toch ook al aangegeven dat er "onveilige" content op de pagina staat? Krijg je een rood streepje door het slotje in je adresbalk.

Zelfs Facebook heeft hier soms last van.

Maar op zich natuurlijk geen verkeerd idee, brengt meer duidelijkheid voor de end-user. Dit zal niet het verschil weten tussen HTTP en HTTPS.

[mkools24]

Zelfde in GMail, op eeen emailtje met een foto erin die geladen wordt via http en je krijgt in Chrome ook een driehoekje te zien ipv. een SSL slotje.

[ronaldmathies]

Opzich klinkt het goed maar omdat ik niet weet hoeveel websites deels onversleutelde informatie ophalen heb ik geen idee hoeveel websites hierdoor gebroken raken.

Daarnaast vindt ik de zin:

maar de keuze van Mozilla kan webontwikkelaars wel dwingen om fouten in de ssl-implementaties sneller te corrigeren.

Als je nu een browser hebt die zeg maar 40% marktaandeel hebt dan kan ik mij voorstellen dat dit effect gaat hebben. Maar gezien het marktaandeel volgens mij zo rond de 20,8% ligt en dalend is al voor de laatste 12 maanden (elke maand een lichte daling) ben ik eerder bang dat je nog meer gebruikers weg jaagt.

[sfranken]

Elke browser doet dit, schijnbaar vraagt IE om toestemming en Chrome geeft een melding.

[Maurits van Baerle]

Maar gezien het marktaandeel volgens mij zo rond de 20,8% ligt en dalend is al voor de laatste 12 maanden (elke maand een lichte daling) ben ik eerder bang dat je nog meer gebruikers weg jaagt.

Het daalt niet, althans, het is al een jaar niet meer gedaald. Het is van 25% naar 20% teruggevallen in 2011 maar het is inmiddels al een jaar stabiel rond 20% en de laatste vier maanden op een rij zelfs weer lichtelijk gestegen. Aangezien de totale hoeveelheid internet gebruikers nog steeds toeneemt kun je dus stellen dat het absolute aantal Firefox gebruikers ook nog steeds toeneemt.

May, 2012 19.71%
June, 2012 20.06%
July, 2012 20.16%
August, 2012 20.05%
September, 2012 20.08%
October, 2012 19.99%
November, 2012 20.44%
December, 2012 19.82%
January, 2013 19.94%
February, 2013 20.12%
March, 2013 20.21%

Bron: http://marketshare.hitslink.com

Op zich kun je stellen dat ze als op één na grootste browser nog best wat marktmacht hebben om dit soort dingen aan de kaak te stellen en af te dwingen. Helemaal als je bedenkt dat veel andere browsers het vaak ook niet ongemerkt voorbij laten gaan en waarschuwingen geven.

[Reactie gewijzigd door Maurits van Baerle op 24 juli 2024 17:20]

[CaptJackSparrow]

Gaat dat dan problemen opleveren als je Tweakers via https bezoekt? Nu krijg ik onderin de statusbalk een waarschuwing met o.a: "Connection Partially Encrypted" melding.

Wordt er in FF23 dan informatie niet meer weergegeven die nu wel weergegeven wordt?

Betekent dit dat de devvers bij Tweakers aan het werk moeten?

[crisp]

Betekent dit dat de devvers bij Tweakers aan het werk moeten?

We werken al een tijdje aan verbeterde ondersteuning voor https, maar feitelijk is het nog steeds een niet-supported scenario met uitzondering van pagina's die via secure.tweakers.net gaan

[Beelzebassie]

https://www.eff.org/https-everywhere

Met deze plugin/addon worden alle requests als https afgehandeld...

Edit:

Ter verduidelijking:
"[The HTTPS Everywhere extension fixes] [sites filling] encrypted pages with links that go back to the unencrypted site [by using a clever technology to rewrite requests to these sites to HTTPS]."

[Reactie gewijzigd door Beelzebassie op 24 juli 2024 17:20]

[Uchy]

Je opmerking wekt de verkeerde suggestie dat alle browserverkeer zomaar automagisch https-versleuteld wordt. Dit is NIET het geval.
Veel sites hebben ook https-mogelijkheden, maar maken daar default géén gebruik van.
Https-everywhere checkt of die mogelijkheden er zijn en zorgt er vervolgens voor dat die altijd gebruikt worden.

(als ik deze post plaats, krijg ik in FF deze reactie:
Hoewel deze pagina is versleuteld, zullen de gegevens die u hebt ingevuld over een niet-versleutelde verbinding worden verzonden en kunnen ze gemakkelijk worden gelezen door derden.... Tweakers heeft dus ook nog wat te doen! :-))

[Soggney]

Met de trend van hacks en aanvallen die in het nieuws komen lijkt dit me een goede keuze van Mozilla.

[PrismSub7]

En straks weer een daling in het aantal Firefox gebruikers omdat de site wel op Chrome werkt. Helaas, maar nodig.

[Verwijderd]

maar de keuze van Mozilla kan webontwikkelaars wel dwingen om fouten in de ssl-implementaties sneller te corrigeren.

Mozilla zit niet meer echt in een dwingende positie. Firefox blijft volgens een recent artikel hier op T.net marktaandeel verliezen.