Chrome gaat http-downloads vanaf https-sites blokkeren

Google gaat gefaseerd doorvoeren dat Chrome geen mixed content downloads meer accepteert. Dit zijn downloads die de gebruiker start vanaf een https-site, maar die zelf niet via een versleutelde verbinding verlopen.

Google blokkeert dergelijke downloads, omdat gebruikers geen weet zouden hebben van de risico's voor privacy en beveiliging. Chrome geeft immers nog geen melding bij het binnenhalen via een http-verbinding vanaf een site die zelf wel via https wordt geopend. Vanaf Chrome 82, die in juni verschijnt, begint het bedrijf met dit soort waarschuwingen. De browser start met de notificaties bij downloaden van risicovolle bestanden zoals executables.

Vanaf Chrome 83 blokkeert de browser het binnenhalen van dit soort bestanden via http dan volledig. Bij Chrome 84 en 85, die achtereenvolgens in augustus en september uitkomen, voorkomt Google dat Chrome zo nog respectievelijk archiefbestanden en documenten kan downloaden. En bij de komst van Chrome 86, gepland voor oktober, accepteert de browser het binnenhalen van mixed content helemaal niet meer.

Het gaat bij voorgenoemde updates om de desktopreleases. De Chrome-versies voor Android en iOS volgen telkens een release later en daar begint Google dus in Chrome 83 met waarschuwen. Volgens het bedrijf zijn mobiele gebruikers al beter beschermd tegen malware en kunnen ontwikkelaars door de latere release zich op tijd voorbereiden.

Reacties (110)

[Terrestrial]

Op zich geen slecht idee maar blokkeren vind ik dan weer te ver gaan, er zijn genoeg webinterfaces te bedenken die bijv. in een intern netwerk geen https gebruiken, een melding is dan prima maar blokkeren lijdt er toe dat je geen chrome meer kunt gebruiken voor dit soort applicaties. Bovendien ook op het publieke internet zal niet iedereen zijn stok oude website gaan voorzien van TLS, je moet altijd de keus houden om toch iets te downloaden als je dat wilt.

Wat ik trouwens liever heb is dat er standaard hashes gepubliceerd worden en deze automatisch worden gecheckt, versleuteling is 1 ding maar je wil ook weten of het bestand wat je download niet mee geknoeid is onderweg. Want ook met een TLS verbinding is dat nog steeds mogelijk.

[Jimbolino]

het gaat om mixed content.
dwz een http link op een https website.

dus een oude/intranet pagina die op http draait heeft er geen last van.

[kozue]

Maar dit is dus geen mixed content. Er wordt geen http content op de pagina zelf geladen. Er gebeurt niets totdat je op de link klikt. Het is vergelijkbaar met een verwijzing naar een http site vanaf een https site.

En hiermee gaan wel degelijk zaken stuk. Het web is in rap tempo naar https aan het migreren, maar oudere sites waar nog waardevolle bestanden op staan kun je binnenkort dan nergens meer linken. Dat is dus effectief gezien het weggooien van een stukje web.

[Jimbolino]

Zelfde argument kun je gebruiken voor een login formulier wat post naar een http url.
Er gebeurt niks totdat je op de button klikt.
Gelukkig is die fout jaren geleden al opgelost (ie6)

Belangrijkste argument is dat de gebruiker niet duidelijk kan zien dat hij van https naar http is gegaan. Omdat "het slotje" nog steeds in de adresbalk staat.
Goed van Chrome dat ze deze bug nu fixen.

[Reactie gewijzigd door Jimbolino op 23 juli 2024 19:02]

[Adion]

Wat ik trouwens liever heb is dat er standaard hashes gepubliceerd worden en deze automatisch worden gecheckt, versleuteling is 1 ding maar je wil ook weten of het bestand wat je download niet mee geknoeid is onderweg. Want ook met een TLS verbinding is dat nog steeds mogelijk.

Als je niet zeker bent van de verbinding dan kan je toch ook niet zeker zijn dat de hashes die je te zien krijgt correct zijn? Al helemaal niet als ze automatisch gecontroleerd moeten worden, want dan is er zelfs een standaard over hoe hashes doorgegeven moeten worden.

[casberrypi]

Er is geen geldig excuus voor het niet gebruiken van een veilige versleutelde verbinding voor sites. Met Let's Encrypt is dit nooit moeilijk.

Het is met een TLS verbinding praktisch gezien onmogelijk om te knoeien met een download onderweg. Je kunt wel een bestand muteren, maar niet zelf bepalen waarin het dan muteert. Dus je kunt een bestand stuk maken, maar de uitkomst niet manipuleren.

[BarôZZa]

Prima zaak. Je kan zeggen wat je wil, maar Google/Chrome en Letsencrypt hebben er samen wel voor gezorgd dat in een paar jaar tijd vrijwel alle sites over zijn op https.
Ja, het is een machtige partij die z'n wil oplegt aan de kleinere partijen (toen ze dat net begonnen te pushen had je veel protest van alle sites die het maar onzin vonden), maar dit is 100% in het belang van de eindgebruiker.
Persoonlijk vind ik de manier waarop ze het stapje je beetje uitrollen met duidelijke aankondigingen prima behapbaar voor de webmasters.

[mr_evil08]

Maar wat is er "onveilig" aan "http" voor websites met alleen maar statisch content waar je niet inlogd, kan je dat uitleggen ?

Tuurlijk het zou gemanupuleerd kunnen worden door "man in the middle attack".

[Reactie gewijzigd door mr_evil08 op 23 juli 2024 19:02]

[Gropah]

Hier is een goede uitleg van Troy Hunt waarom ook statische sites HTTPS nodig hebben.

[nullr0ute]

Zie ook: https://doesmysiteneedhttps.com/

[LeonM]

Zonder TLS (encryptie) kan elke download worden gemuteerd tijdens het transport. Men spreekt dan van een 'man-in-the-middle' aanval.

Bijvoorbeeld: jij download een applicatie door een onbeveiligde verbinding. Het is dan mogelijk voor alle partijen tussen jou en de server (je ISP, meerdere overheden, werkgever, publieke wifi, etc) om het bestand te muteren en spyware te injecteren.

Heeft dus niks te maken met wel/niet ingelogd zijn, maar het beveiligen van data terwijl het wordt getransporteerd naar jouw computer.

[jozuf]

Naast wat hierboven word gezegd is http/2 praktisch alleen in te zetten op https sites.
Dat scheelt soms best merkbaar in performance,afhankelijk van de site en met name de hoeveelheid assets die binnengeharkt worden.

Was bedoeld op reactie van mr_evil08.

[Reactie gewijzigd door jozuf op 23 juli 2024 19:02]

[mxcreep]

MITM is ook mogelijk als er wel TLS gebruikt wordt, mits de aanvaller maar een werkend private key/certificaat paar in zijn handen heeft uitgegeven door een CA die de browser vertrouwd.

Precies de achilleshiel van het huidige CA verhaal.

Er zijn wel wat oplossingen voor bedacht, zoals onder andere http public key pinning maar dat introduceert ook weer nieuwe problemen. Onder andere de complexiteit, als je HPKP signatures combineert met de noodzaak voor backup signatures en vervolgens met de korte levensduur van LetsEncrypt certificaten dan is de procedure ineens helemaal niet meer zo easy.

LetsEncrypt word nu bij heel veel websites toegepast omdat allerlei control panels waarmee die websites beheer worden dit ook faciliteren, o.a. DirectAdmin en Plesk plus de diverse eigenbouw panels van grote aanbieders.

Persoonlijk vind ik dat niet elke site TLS encryptie nodig heeft, veel data is gewoon niet interessant genoeg daarvoor.

Mixed content vind ik wel een risico, als je delen via https aanbiedt en delen via http heb je dus blijkbaar al twee webroots en moet je dus zorgen dat de juiste content via het juiste protocol wordt aangeboden. Dat is een risico, als hier fouten worden gemaakt kan content via http worden aangeboden waar dat niet bedoeld was.

[kftnl]

Mensen praten elkaar hierover allemaal na, maar in feite boeit het voor veel simpele sites gewoon niet. Er is geen gevoelige informatie, manipuleren is zinloos, en als je het al wilde manipuleren zou je het veel makkelijker kunnen doen door het wordpress thema te hacken dan door bij KPN te gaan inbreken en de glasvezel te gaan splicen. De belangrijkste reden om het toch (bijna) verplicht te stellen is dat er anders ook sites waar het wel van belang is op HTTP blijven omdat de mogelijkheid blijft bestaan.

Daarnaast zijn er aanvallen waarin je mensen overschakelt op HTTP, in sommige gevallen zijn die moeilijker te detecteren zonder dit soort maatregelen - maar het gaat dan specifiek niet over dit soort simpele sites, maar die zijn van dit soort maatregelen een beetje de collateral damage.

[Reactie gewijzigd door kftnl op 23 juli 2024 19:02]

[BarôZZa]

Het kan gemanipuleerd worden en derden kunnen bijhouden welke pagina's je precies bezoekt, welke zoektermen je daar gebruikt, welke berichten je verstuurt(denk aan een contactformulier) etc etc. Het maakt het ook veel makkelijker om het massaal te doen voor bijvoorbeeld de providers, kwade overheden etc. Denk aan een sleepnetje waarbij je alle traffic met zoektermen kan filteren. Eerst werkten die trucjes op verreweg het grootste deel van het internetverkeer en dat is nu enorm veranderd.

[Reactie gewijzigd door BarôZZa op 23 juli 2024 19:02]

[darkfader]

Theoretisch zou een browser elk willekeurig invoercomponent, downloads en onveilige content kunnen blokkeren op onbeveiligde sites. En een grote banner bovenaan die laat zien dat de inhoud niet betrouwbaar is.
Of redirecten naar een proxy of internet archief die wel beveiligd is.

[air2]

Omdat je https site die content toont en die zou idd onderweg gemanipuleerd kunnen worden. Zo zou onveilige javascript van een malafide site op je https site terrecht kunnen komen zonder dat je het doorhebt. Sterker nog de browser zegt gewoon, deze site is veilig en kan geen man in de middle attack plaatsvinden, terwijl dat dus wel kan.

[Ghxst]

Het is niet alleen dat je met een MITM de traffic kan inzien maar het intercepten en return van malicious payloads, of trackers e.d. kan gevaarlijk zijn.

[Stoelpoot]

Maar wat is er "onveilig" aan "http" voor websites met alleen maar statisch content waar je niet inlogd, kan je dat uitleggen ?

De mogelijkheid om een login-formulier te injecteren, bijvoorbeeld. Dan heb je opeens alle gevaren van een onveilig login-form, en een aanvaller die volledige toegang heeft tot dat formulier.

[mkools24]

Sommigen vinden Letsencrypt juist een slecht idee

https://medium.com/swlh/w...lly-bad-idea-d69308887801

En ik kan me daar wel in vinden, de vraag is hoe veilig het internet nog is wanneer iedereen Letsencrypt gebruikt en de private key lekt een keer uit, dan zijn de gevolgen niet te overzien.

[HakanX]

Nou omdat Letsencrypt toch maar voor 3 maanden is en niet voor 10jr zoals andere aanbieders, heeft iedereen verplicht wel een script draaien welke geautomatiseerd het certificaat vernieuwd ipv handmatig over tig jaar en na een heleboel klachten over onveilig meldingen.
Het is dus een kleine moeite om het certificaat te vernieuwen zodra er key is gelekt. Want dat systeem is al geïmplementeerd. Zelfs als de admin dood is, heb je in het slechte geval over 3 maanden een nieuw certificaat.

[Rob Coops]

Het zou goed zijn als men dat terug bracht naar 1 maand gewoon omdat het kan en omdat dit het gevaar bij het lekken van een key nog verder verkleint. Ook al ga ik er van uit dat "goede" regiem's (lees Amerika) heus die key al wel in handen hebben want national security en zo...

[alexvanniel]

Maar, welke private key dan? Want de private key van mijn website bezit ik zelf...tenminste... voor zover je volledige beschikking hebt over je eigen server dan ;-) Er valt dus bar weinig te decrypten door een NSA aan de hand van een private key die ze niet hebben. (nou ja... *aluhoedje*)

https://www.digicert.com/blog/where-is-your-private-key/
"A private key is created by you—the certificate owner—when you request your certificate with a Certificate Signing Request (CSR). The Certificate Authority providing your certificate (such as DigiCert) does not create or have your private key."

Overigens heeft de NSA jouw private key helemaal niet nodig. Die gebruiken gewoon wat backdoors in protocollen, encryptiemethodes of andere methodes om aan de gegevens te komen die ze nodig hebben maar dat is volledig offtopic.

[fastedje]

Controleert Letsencrypt ook of de public key vernieuwd is? Zo niet dan is het aanvragen van een nieuw certificaat met dezelfde private key nog steeds niet veiliger.

[iRobbery]

Met die key van LE hebt, kan je wel alle certificates signeren die je wilt, en een heel hoop fraude uithalen.

[Slonzo]

Daarvoor heb je dan Certificate Revocation List (CRL) en Online Certificate Status Protocol (OCSP). Eens de root/intermediary revoked is, zijn alle daarmee gesignde certificaten verderop in de keten ook ongeldig.

[Reactie gewijzigd door Slonzo op 23 juli 2024 19:02]

[Mushroomician]

Een man in the middle kan een proxy opzetten en de client een vals, zelf gemaakte certificaat serveren. De client heeft dan niet door dat het certificaat een andere is. Dat valse certificaat wordt dan vertrouwd omdat die is "ondertekent" met de privesleutel van de CA, waarvan de publieke sleutel al aanwezig is op de hardware van de client.

[uiltje]

Behalve als je een man-in-the-middle attack uitvoert kan je met de private key nog steeds niets. Vanaf TLS 1.3 heb je overal forward security. Voor het afspreken van de sleutel voor de berichten wordt gebruik gemaakt van een key agreement protocol met tijdelijke sleutels. Die RSA sleutel wordt alleen gebruikt voor het authenticeren van de handshake. Dus dan moet de veiligheidsdienst je sleutel al van tevoren kennen.

Bij TLS 1.2 wordt het overigens ook al vaak gebruikt, maar er zijn ook nog RSA ciphersuites aanwezig waarbij de "shared secret" gewoon wordt versleuteld door de client/browser.

[Reactie gewijzigd door uiltje op 23 juli 2024 19:02]

[mkools24]

Je hebt dan een nieuw certificaat maar de private key blijft hetzelfde!

[HakanX]

We gaan er wel vanuit dat ze na het bekend worden van de hack niet dezelfde private key blijven gebruiken he

[sdk1985]

Zelfs als de admin dood is, heb je in het slechte geval over 3 maanden een nieuw certificaat.

Dan moet die admin het wel zo hebben ingeregeld dat het script zelf ook update. Pin me er niet op vast maar ik geloof dat de ToS zo nu en dan wijzigen en dat de uitgave daar op vastloopt.

[Reactie gewijzigd door sdk1985 op 23 juli 2024 19:02]

[aequitas]

Letsencrypt stimuleert het vaak (een keer per paar maanden) verversen van je certificaten en heeft gezorgd dat dit proces triviaal is om te automatiseren. Dus als de key nu zou lekken dan is de schade snel te beperken. Dit i.t.t. de processen bij traditionele CA's waar er altijd veel mensenwerk aan te pas komt. Daarnaast is Letsencrypt open source dus een willekeurige CA kan zo zijn eigen Boulder server opzetten en klanten kunnen hun Letsencrypt client makkelijk instellen om die te gebruiken.

[D-Raven]

Dit inderdaad. Als die andere CA's het nou ook zo makkelijk zouden maken om hun certificaat op een veilige manier te vernieuwen....
Er wordt in die wereld ontzettend veel ingespeeld op de onwetendheid van mensen, en daar flink misbruik van gemaakt door middel van onzin procedures en hoge kosten.

[alexvanniel]

De private key van wat precies? Want de private key van mijn certificaten (niet allemaal Let's Encrypt overigens) staan gewoon op mijn server. Daar heeft LE eigenlijk niet zo heel veel mee van doen. https://www.digicert.com/blog/where-is-your-private-key/

Als die van de CA uit lekt, dan is het mogelijk dat er iemand certificaten namens LE gaat uitgeven. Naast het feit dat de schrijver van het artikel waar jij naar linkt, volledig voorbij gaat aan het feit dat er bij LE alles aan gedaan wordt om dit soort zaken te voorkomen, worden er ook halve waarheden verkondigt.

[Rob Coops]

Nou nee niet jouw private key das een beetje lastig en duur om allemaal bij te houden eerder de key die nodig is om uit naam van de CA nieuwe keys uit te geven en dus heel makkelijk sites te kunnen spoofen met echte keys die ook echt door de CA ondertekend zijn en zo.
Dan kunnen ze immers een cert aanmaken voor de site die ze willen zonder dat de admin van die site er weet van heeft en hoeven ze niet bij te houden wie welke private key etc heeft. One key to rule them all

[mkools24]

Precies, net als destijds met die Nederlandse certificaatboer die gehackt was, kan even niet op de naam komen maar toen maakten hackers gewoon een *.* certificaat.

[slaapkopje]

DigiNotar

[mkools24]

Dat was hem thx

[RoestVrijStaal]

Want het dowloaden via http van een backup van de huidige configuratie van je router op self-signed https webinterface is zo onveilig

Of de telemetrie e.d van je netwerkprinter uitzetten via de webinterface, wat ook via http of self-signed https gaat, is zoooo erg.

Ik zou me meer zorgen maken dat er in de toekomst een derde partij èn internet nodig zou moeten zijn omdat mijn browser https vereist voor het gebruik van webinterfaces van netwerkapparatuur.

[BarôZZa]

De browser kan niet zien of het veilig is en toont een waarschuwing waarbij staat dat als je weet wat je doet (wat jij overduidelijk weet), dat je dan verder kan gaan.

Dat lijkt me een logisch verhaal. Het probleem is natuurlijk http op het web.

Chrome geeft ook meldingen dat mijn lokale (zelf ontwikkelde) extensies mogelijk onveilig zijn. Dat is om de gemiddelde gebruiker te helpen die niet zelf lokaal extensies installeert.

[RoestVrijStaal]

Extensies van een arbitraire bron installeren is wat anders dan data tussen lokale machines over een protocol sturen wat persoon/bedrijf XYZ onveilig vindt.

En het is belachelijk dat het probleem van dat digibeten door hun browser geen backup van de instellingen van hun netwerkapparatuur mogen maken en/of een grote rode waarschuwing krijgen, met alle gevolgen van dien. (Het eng vinden om de instellingen te veranderen / de firmware ervan te updaten / netwerkapparatuur resetten) bij de leverancier van de netwerkapparatuur wordt gelegd.

[Reactie gewijzigd door RoestVrijStaal op 23 juli 2024 19:02]

[BarôZZa]

De browser weet niet of het een lokale machine is of dat iemand aan het vissen is.

Het is volstrekt logisch dat je een waarschuwing krijgt. Een waarschuwing is niet meer dan dat. Je kan prima je werk doen. Als je bang bent voor waarschuwingen dan moet je sowieso ver weg blijven van de routerconfiguratie. Zulke mensen kunnen beter de Ziggo genius bar bellen.

[McBacon]

Letsencrypt is inderdaad goeie shit, maaar er is wel één mogelijk groot probleem: het huidige cert van de root CA (IdenTrust/DST Root CA X3 aka TrustID X3 Root) die de LE intermediate certs cross-signed heeft, verloopt in september 2021. Nog steeds niet "alle" devices vertrouwen de ISRG Root X1, dus ik vraag me af hoe lang het gaat duren voor deze devices de nieuwe DST Root CA X4 zullen vertrouwen*. We weten allemaal dat er nog mensen op Windows XP en 7 draaien.

* Op de forums van Letsencrypt wordt wel gesproken over dat ze waarschijnlijk de cross-signing door IdenTrust achterwege zullen laten zodra deze verloopt. Dus devices die DST X4 niet kennen maakt voor LE dan niet uit.

[Bardman1]

Lekker dan een ander (browser) die voor je gaat beslissen.

[Lucb1e]

Chromium is open source, dat kun je altijd zelf patchen als er iets is dat je niet leuk vindt. Of natuurlijk Firefox of andere alternatieven

[SuperDre]

Wat een onzin zeg, ja het is opensource, maar nee, je kunt het niet altijd zelf even patchen, want dan moet je dus constant die branch zelf onderhouden..

[Lucb1e]

"Onderhouden", mwah. Een nieuwe versie installeren is git pull && make, in ieder geval zolang er geen merge conflicts zijn. Afhankelijk van de edit (in dit geval is het het if-statement aanpassen die de check doet, dat is 1 regel code) is het onwaarschijnlijk dat je de wijziging vaak opnieuw moet toepassen.

In alle eerlijkheid is het natuurlijk wel wat werk om Chromium te compilen, dat project is best fors. Maar ik zeg maar, als het zo vervelend is als velen hier stellen dat dit gaat zijn (ben ik het overigens niet mee eens), of als Bardman1 het zo vervelend vindt om zijn keuzes uit handen genomen te krijgen, dan kunnen diegenen best de source code erbij pakken en een alternatieve build maken. Buiten de clone- en compiletijd (wat op de achtergrond kan draaien) zal het maken van de codewijziging zelf (een eenmalige actie) niet meer dan 5 minuten kosten als je de code kent of misschien een half uur als je het voor het eerst doet.

[Reactie gewijzigd door Lucb1e op 23 juli 2024 19:02]

[SuperDre]

Dat zijn een hoop 'alsen'....

[Lucb1e]

Dat zijn weinig woorden

[BlueTooth76]

Hoewel ik die veiligheid aanmoedig ga ik toch liever voor een browser die waarschuwt dan alles blokkeert.

[Isawkson]

Ik denk voor mensen die een "digibeet" zijn dit heel erg kan helpen. De kans dat ze iets onveiligs downloaden wordt dan kleiner, en worden ze (hoop ik) bewuster van wat ze downloaden.

[Remenic]

Ook over een veilige verbinding kun je onveilige dingen downloaden. En met letsencrypt kan iedereen zo een 'beveiligde' server opzetten om jou malware te serveren.

[theboss100]

Toch denk ik dat voor het overgrote deel van de gebruikers het beter is dat het geblokkeerd wordt. Veel mensen kennen de gevaren niet en klikken gewoon op downloaden. Tuurlijk kun je dan zeggen dat het je eigen schuld is maar sommige gebruikers weten niet beter. Voorkomen is altijd beter dan genezen.

[Z80]

Klopt. Maar voor de rest van de gebruikers is Chrome geen optie meer. Zeker omdat het veel voorkomt dat drivers en firmware, zeker van oudere apparaten, niet via https gaan.

[NDSFREAK]

Helemaal mee eens wat je zegt. Blokkeren lijkt nu gelijk op censuur voor de gebruiker.
Wat me grootste bezwaar is : je kunt op een https site zitten maar er zijn genoeg bedrijven die een bestand aanbieden die via een andere servers verlopen die in het interen DMZ zone zitten die een bestand aanbieden via een andere webserver of CRM pakket of als ftp of download bestand.
Hoe gaat de nieuwste chrome browser hier mee om ?

[mr_evil08]

Dat gepruts heb ik de laatste tijd al met Chrome, er worden regelmatig "false positive" aangegeven, ook kan ik niet op bepaalde website,s.

"bestand is onveilig gekenmerkt" of "website is gerapporteerd als onveilig" fijn terwijl het zeker weten niet zo is...

Kan ik weer appart IE11 starten(wat nog onveiliger is) en vanuit daar het bestand gaan downloaden.

Blokkeren vind ik ook niet kunnen, hooguit waarschuwen en het knopje doorgaan een klein beetje verstoppen, bepaalde custom software wordt standaard geblokkeerd terwijl er niets aan de hand is.

[Reactie gewijzigd door mr_evil08 op 23 juli 2024 19:02]

[De Nelis]

Hij waarschuwt ook met deze notificatie en blokkeert niet direct, zoals ook met niet veilige sites kun je er zelf alsnog voor kiezen door te gaan met de potentieel onveilige download door op het pijltje naast discard te klikken verwacht ik.

[theboss100]

Vanaf Chrome 83 blokkeert de browser het binnenhalen van dit soort bestanden via http dan volledig. Bij Chrome 84 en 85, die achtereenvolgens in augustus en september uitkomen, voorkomt Google dat Chrome zo nog respectievelijk archiefbestanden en documenten kan downloaden. En bij de komst van Chrome 86, gepland voor oktober, accepteert de browser het binnenhalen van mixed content helemaal niet meer.

Zoals in het artikel staat komt er in de komende versies helemaal geen optie meer om dit te omzeilen.

[De Nelis]

Overheen gelezen, excuus

[Stoney3K]

Net zoals het proberen te versturen van EXE of ZIP bestanden in Gmail dus. Wil je even een fix naar een collega sturen voor een bepaald probleem ("Installeer dit bestandje en het probleem is opgelost") wordt dat door Gmail gewoon blind geblokkeerd omdat het mogelijk onveilige content is. Zonder dat je de mogelijkheid hebt om zelf te zeggen dat ie dat bestand door moet laten.

[coffey]

Bij ons: Extensie zip veranderen in piz en bestand loopt zo door de bedrijfsfilters. Blijft me verbazen.

[Martijn.C.V]

Hoewel ik het met je eens ben dat het niet perse aan een browser is, als ze het laten bij een notice veranderd het niet.

> Hoe ga je verkopen "Ja chef, ik moet tijd besteden aan het omzetten naar http. Waarom? Nou, anders krijgen we een melding in het console. Console? Ja daar kijken alle developers in. Nee, klanten niet nee. Nee, we gaan er niet meer door verdienen nee."

In sommige gevallen is het heel simpel, maar er zijn een hoop situaties waar het aardig wat werk kost. Tweakers is er bijvoorbeeld zelf ook even mee bezig geweest. Zodra je afhankelijk bent van derde partijen is het opeens al een stuk uitdagender. Of als je meerdere subdomeinen hebt, dan is het minder simpel dat je denkt. Of als for some reason LetsEncrypt niet een optie is, dan gaat het ook nog eens extra geld kosten.

[Reactie gewijzigd door Martijn.C.V op 23 juli 2024 19:02]

[Verwijderd]

Hoeveel tijd kan je kwijt zijn aan het vervangen van http door https.
Mixed content wordt al jaren op neergekeken. En niet alleen door browsers.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 19:02]

[Blasterxp]

ja, ik ook. Waarom zou je een download van een .exe niet in plaintext kunnen doen? De inhoud is toch al onleesbaar.
Wel of niet https - maakt toch niet voor een goed, of slecht bestand? Een simpel SSL certificaat bewijst alleen communicatie, niet echtheid van een schoon of vies bestand.

[wica]

Bij HTTPS is encryptie niet eens het belangrijkste . Maar dat dat je weet van wie iets komt en dat het onderweg niet aangepast is.

Bij HTTP, zou je de inhoud kunnen aanpassen, zonder dat iemand het door heeft.

[Chinco]

Sorry, maar de bron is net zo onbetrouwbaar als de weg waarlangs het komt. Wat dat betreft is de S in https valse veiligheid voor de gemiddelde gebruiker.

Ik haat het dat browsers gaan bepalen wat ik wel en niet doe. Het is mijn pc en mijn risico. Waarschuwen is uitstekend, de eindbeslissing ligt bij mij. Het is toch van de zotten dat ik een tweede, oude versie van een browser moet installeren om bepaalde taken nog uit te kunnen voeren???

[GertMenkel]

Als je wilt kun je prima de code van Chrome pakken, return true geven op alle checks en je eigen onveilige browser maken. Alternatief is een systeempje met een eigen certificate authority en een proxy die niet op geldigheid checkt zo gebouwd voor de gemiddelde tweaker denk ik. Gooi je eigen browser online, noem het "warningless Chrome" en doe ermee wat je wilt, zolang je het maar niet adverteert naar mensen die niet snappen wat het inhoudt.

Het probleem met waarschuwen is dat men handleidingen gaat maken waar staat hoe je de waarschuwing moet omzeilen en juist de mensen die niet de keuze kunnen maken (ouderen, digibeten, laaggeletterden voor wie de waarschuwing onbegrijpelijk is) het slachtoffer worden van beveiligingsmaatregelen die niet volledig zijn geïmplementeerd.

Kijk bijvoorbeeld naar waarschuwingen over onveilige certificaten. In Chrome kun je die bypassen door "thisisunsafe" in te typen (geen tekstveld aanklikken ofzo, gewoon typen). Vroeger kon dat door "badidea" te typen maar de producenten van een aantal grote softwarepaketten die hun beveiliging niet op orde hadden heeft die string in hun handleiding gezet. Iedereen typt braaf de tekst uit de handleiding over en vanaf dat moment zal iemand die dezelfde waarschuwing op openbare WiFi krijgt de waarschuwing voor eeuwig bypassen. Zelfs als je dan verder goede security practises erop nahoudt kunnen cookies en/of wachtwoorden nog steeds worden gejat door criminelen.

Ik betwijfel of er veel websites zijn die al over https werken maar nog naar http-downloads linken. Van HTTP naar HTTP mag nog (want dat is geen mixed content) dus oude websites zullen het gewoon nog doen.

Browsers zijn vanaf het begin eigenlijk al onveilig ontwikkeld en iedere stap die naar veilige browsers wordt gezet maakt oude, doorgaans slechtgebouwde websites kapot. Eigenlijk had mixed content vanaf het begin al niet toegestaan moeten zijn (dan had je dit probleem ook niet) maar helaas is de geschiedenis anders gelopen.

[Stoney3K]

... of op zijn minst een optie biedt om bepaalde zaken te whitelisten.

[McBacon]

Ik moet wel eens Java Web Start progjes (*.jnlp) downloaden vanaf een website. Chrome zegt al jaren dat het mogelijk onveilig is, maar je kunt zelf op "Keep" klikken om ze toch te downloaden. Ik zie op de screenshot een pijltje aan de rechterkant dus mogelijk dat daar een soortgelijke optie onder komt te staan. Het lijkt me sterk dat ze het ronduit blokkeren zonder mogelijkheid om iets toch vrij te geven, al dan niet met een omweg. Er zijn namelijk gewoon nog sites die refereren naar een externe site die geen HTTPS redirect/HSTS heeft. En hoe gaan ze het doen met de in-browser FTP client, dat is immers ook meestal zonder encryption (bijv. ftp://speedtest.tele2.net)? Zodra je er ftps:// van maakt krijg je de vraag om het te openen in een andere applicatie, die niet iedereen zal hebben (als ze überhaupt weten wat FTP is).

[Kenhas]

Voorlopig kan dat nog. In het najaar kan ook dat niet meer. Staat duidelijk in het artikel

n bij de komst van Chrome 86, gepland voor oktober, accepteert de browser het binnenhalen van mixed content helemaal niet meer.

[Reactie gewijzigd door Kenhas op 23 juli 2024 19:02]

[alexvanniel]

Het lijkt er wel op dat wanneer er https:// ergens vóór staat, men dit meteen als veilig acht. Maar een malafide download blijft een malafide download. Of deze nu via een secure of een unsecure verbinding wordt gedownload. Het enige dat er gebeurt is dat er geen man-in-the-middle attacks gedaan kunnen worden en dat er dus geen valse download geïnjecteerd kan worden.
Oftewel, als ik een programma op een of andere schimmige website aanklik, of als iemand een download op een of andere schimmige website linkt dan wordt dit door het gebruik van https:// niet ineens veilig. Als er aan de andere kant rommel zat, blijft het rommel.
Misschien moeten we maar eens stoppen met net te doen alsof https:// de oplossing is voor mensen die een makkelijk prooi zijn op het internet. Tenminste, daar lijkt het soms wel erg veel op.
Uiteraard voorkomt het dat wanneer ik bijvoorbeeld de meest recente Ubuntu ISO ergens download, en dit is een https:// origin, dat het niet zo eenvoudig meer is om die verbinding te onderscheppen en er een aangepaste download/datastream in te plaatsen. Dat is op zich goed. Mixed-content is overigens ook wel echt passé en nergens voor nodig in de meeste gevallen.
Maar wanneer ik een of andere gekraakte file download van een of andere help site, dan blijft het nog steeds rommel waar ik mijn computer mee infecteer.

[Verwijderd]

Een niet malafide bestand kan tijdens transport via http malafide gemaakt worden. Dat is wat https dus voorkomt.

[alexvanniel]

Dat klopt. Als je mijn opmerking goed leest betwist ik dát ook niet maar beaam ik dat zelfs.
Er wordt alleen net gedaan alsof https:// de oplossing is voor alle problemen die er zijn met malafide downloads. Als in beginsel het bestand malafide is, wordt het daar niet veilig van. Als in beginsel het bestand veilig en officieel is, dan is serveren vanaf een niet beveiligde verbinding niet bepaald verstandig en dat zou deze change dan misschien kunnen voorkomen. Injecteren van malafide javascripts gaat dit echt niet voorkomen. Je kunt je dan ook afvragen dat wanneer er staat dat je secure bent, maar op de achtergrond een of ander via javascript bestand geinjecteerd is in je browser vanaf een https origine, wat is dan de waarde van dat "je verbinding is beveiligd"? Men zou eens moeten realiseren dat het alleen maar betekent dat je zo goed als zeker bent dat waar hetgeen je download ook vandaan komt, dit onveranderd bij jou is aangekomen. Niets meer, niets minder.

[Verwijderd]

Ah, eens dan . Denk dat ik op de verkeerde"Reageer" heb gedrukt

[cricque]

Voor "henk van om de hoek" zal het een worst wezen, die kent het verschil tussen https en http toch niet. Maar mij lijk thet nogal dom om over http https files aan te leveren. En iets dat geïnfecteerd is, maakt niet uit zoals je zegt, dus ik ben het met je eens

Mixed content zie je nog wel eens ... http site, waar dan een iframe in draait met https ... En dat is meestal te wijten aan de klant, want die heeft zijn site niet in https ... want dat kost dan geld is altijd de reden, of ze weten niet hoet ze het moeten doen, maar ze gaan wel zelf liggen prutsen. Dat zie je wel nog al eens. En er zijn genoeg van die kleine bedrijven die gewoon een website hebben, dikwijls ziet het er niet uit. Maar ze moeten het hebben. Als je bekijkt wat mensen mij vroeger voorstelden als ik vroeg wat ze wouden qua website ... Dan val je achterover ... Ooit is eentje gehad rood/geel met een textuur van een ijzerplaat ... Klant is koning, maar deze draken zouden nooit mogen bestaan. Smaken verschillen uiteraard. Maar hier valt niks op te plakken, dit was gewoon ronduit een zeer slecht idee

[Reactie gewijzigd door cricque op 23 juli 2024 19:02]

[alexvanniel]

Wat mixed-content betreft voel ik je pijn, zeg maar. Ik zei ook niet voor niets "in de meeste gevallen" want ik kom ze zelf ook nog tegen. Soms is de "software" die er in geplakt moet worden oud, unmaintainable en toch iets dat de klant eist. Mja. Je kan moeilijk iemand dwingen, waarschuwen is dan het minste maar ook het maximale dat je kan doen.

[MrMonkE]

Dus iedereen moet verplicht vanaf nu alle images/txt/mp3/etc via https aanbieden als de site https is?
Want er staat downloads, wat velen zullen zien als een file downloaden en saven, maar lijkt me dat het ook gaat om alle elementen die in een website worden getoond. Dat kan nog lachen worden in sommige oudere websites.

[DrBreakalot]

Chrome blokkeert mixed content al standaard. Daar verandert deze wijziging dus niets meer aan.

[Kafka]

Nee hoor. Je krijgt alleen een waarschuwing. Er wordt niks geblokkeerd.

[LeonM]

Nee, het gaat om 'downloaden' zoals de gemiddelde gebruiker dat begrijpt, dus het opslaan van de data op disk.

Het laden van content (danwel niet met caching op disk) valt in dit geval niet onder de term 'downloaden'.

Maar, sowieso is er al jaren CSP, wat er vaak wel op neerkomt dat bijvoorbeeld een CSS niet over een onbeveiligde verbinding mag worden geladen als de website zelf wel via HTTPS is geserveerd.

[SinergyX]

Ik heb de ini file voor de settings aangepast, deze kan je [url=http://www.gaap.nl/test.ini[/], zou dus meteen geblokkeerd worden? Wat komt hierna? Selfsigned https blokkeren?

Veiligheid en alles, helemaal best, maar eerst was het de www en https weghalen, toen werd het http elementen, maar stop eens gewoon met direct blokkeren, zo komen er rustig steeds meer redenen om Chrome vrolijk links te laten liggen en altijd nog zelf te bepalen wat ik wel en niet wil downloaden. Blijft humor dat er zo gestampt wordt op http en https, een virus/trojan wordt natuurlijk niet via https verstuurd, phising gebruikt natuurlijk geen https, maar ondertussen begint het praktisch werken in chrome (en ergens nog enigzins zonder nonstop data naar Google te sturen) een aardig probleem worden.

Ben blij dat Edge Enterprise net een stable heeft gekregen, kan direct alles omgezet worden.

[Bender]

Selfsigned https blokkeren?

Dat gebeurt toch ook al, die moet je gericht deblokkeren om verder te kunnen.
Lijkt mij een goede zaak.

Waarom zou jij http://www.gaap.nl/test.ini (http) vanaf een https website linken, lijkt me ook niet handig?

[Khrome]

Aangezien LE een ding is gebeurt phishing etc ook gewoon via https tegenwoordig hoor.

Omdat Chrome de bedrijfsinformatie niet meer in de adresbalk toont is EV ook geen "bescherming" meer.

[Jeoh]

EV was altijd al schijnveiligheid.

[Khrome]

Vandaar de aanhalingstekens

[crowke]

Eigenlijk is de boodschap van het nieuwsbericht: Chrome verplicht https-websites hun downloads via https aan te bieden. Dat lijkt me op zich niet slecht, al is het de vraag of het goed is of Google hierover kan/mag beslissen.

[xenn99]

Google is wel lekker bezig de laatste tijd..
Eerst dat hele gedoe rondom het verwijderen van www, en nu dit weer.
Misschien toch is tijd om over te schakelen naar een andere browser die niet probeert alle keuzes voor mij te maken.

Dat een browser waarschuwt voor een onbeveilgde download lijkt me geen slecht idee,
maar blokkeren?
Dat lijkt mij persoonlijk nogal overdreven en onnodig.

Sowieso zie ik niet in wat het grote "gevaar" is dat Google hiermee probeert te blokkeren..

Of een file nu uit een https of http bron wordt gedownload maakt natuurlijk geen verschil voor de inhoud..
Malware kan immers net zo goed worden geserveerd vanaf een https verbinding.

De enige situatie waarbij ik me nog iets kan voorstellen is als je bijvoorbeeld een bestand download met gevoelige informatie, maar ik denk niet dat dat soort bestanden vaak via http verbindingen worden geserveerd.

[Plompie]

Weet iemand toevallig hoe Firefox hiermee om gaat? Kan er zo snel niets over downloads vinden op de support page.