Chrome gaat http-elementen op websites automatisch blokkeren

Google Chrome gaat in de toekomst geen http-elementen meer laden op verder versleutelde pagina's. Op websites met https-verbindingen die ook niet-versleutelde elementen bevatten worden die laatste niet meer zomaar ingeladen.

Dergelijke 'gemixte content' wordt in de toekomst geblokkeerd in Chrome, schrijft Google in een blogpost. De browser zorgt er dan voor dat https-websites alleen nog maar https-content kunnen laden. Google wil daarmee de privacy en veiligheid van gebruikers verbeteren. Volgens het bedrijf surfen internetgebruikers inmiddels meer dan 90 procent van hun tijd over een versleutelde verbinding.

Chrome blokkeert dergelijke gemixte content op dit moment al in bepaalde gevallen. Dat gebeurt als het gaat om onversleutelde scripts of iframes. Multimediale content zoals afbeeldingen, audio of video worden echter gewoon nog afgespeeld, ook als zij niet met https versleuteld zijn. Daardoor kunnen aanvallers in principe zulke content gebruiken om malware of trackingcookies naar bezoekers te sturen. Bovendien, zegt Google, zorgt dergelijke gemixte content voor verwarrende signalen voor gebruikers. Die zien in hun url-balk weliswaar dat een site met ssl is versleuteld, maar dat er 'delen onveilig zijn.'

De verandering vindt niet van de ene op de andere dag plaats. In Chrome 79 komt er een nieuwe instelling waarmee gebruikers gemixte content handmatig kunnen aan- of uitzetten. Die zit in hetzelfde menu als waar gebruikers meer informatie kunnen vinden over de beveiliging van een site. In Chrome 80 worden audio- en video-elementen automatisch via https verstuurd, of worden ze geblokkeerd als dat niet lukt. Bij het gebruik van onversleutelde afbeeldingen krijgen gebruikers de melding te zien dat de hele website onveilig is. In Chrome 81, dat uitkomt in februari volgend jaar, worden alle onveilige elementen automatisch geblokkeerd.

Reacties (94)

[paradoXical]

Ik haal aan:

Dat gebeurt als het gaat om onversleutelde scripts of iframes. Multimediale content zoals afbeeldingen, audio of video worden echter gewoon nog afgespeeld, ook als zij niet met https versleuteld zijn. Daardoor kunnen aanvallers in principe zulke content gebruiken om malware of trackingcookies naar een bezoekers te sturen.

Dat kan ook via https ook, dit maakt geen enkel verschil. Lijkt mij niet nodig dit als reden op te geven, het wel of niet encrypted zijn met TLS zegt niets over de veiligheid van de geboden content.

[Niet Henk]

Het verschil is dat het ongemerkt door een derde partij kan gebeuren. Stel je internetbank laad een script in met via HTTP op de loginpagina, en je zit op publieke WiFi. Dan kan, in theorie, dit script onderschept en aangepast worden zonder dat jij er weet van hebt (een man-in-the-middle aanval). Dit script kan dan de login onderscheppen, ondanks dat er een slotje naast de URL staat (maar wel één met uitroepteken).

Scripts waren al langer geblokkeerd, omdat dit een zeer reeel risico vormt. Afbeeldingen en video's zijn iets lastiger uit te buiten, maar als je afbeeldingen vanaf het zelfde domein gebruikt, krijgen deze ook onversleuteld de cookies van het domein mee, en dit kan gebruikt worden om iemands login-cookies te onderscheppen via een MITM aanval.

Natuurlijk kunnen er nog steeds tracking cookies geplaatst worden via HTTPS. Maar dan wel door degene die de domeinnaam beheerd, omdat het verkeer niet onderweg onderschept en aangepast kan worden zonder HTTPS te kraken of fouten te genereren.

[Reactie gewijzigd door Niet Henk op 24 juli 2024 21:50]

[hakog2]

Scripts waren al langer geblokkeerd, omdat dit een zeer reeel risico vormt. Afbeeldingen en video's zijn iets lastiger uit te buiten, maar als je afbeeldingen vanaf het zelfde domein gebruikt, krijgen deze ook onversleuteld de cookies van het domein mee, en dit kan gebruikt worden om iemands login-cookies te onderscheppen via een MITM aanval.

Op zich klopt het wel wat je zegt, maar.. precies voor deze use-cases zijn er secure cookies. Secure cookies worden alleen meegestuurd over een beveiligde verbinding.

https://developer.mozilla...cure_and_HttpOnly_cookies

[Alfa1970]

Met een MITM aanval hoef je helemaal geen login cookies te onderscheppen.
Je kan alles doen wat je wilt met het verkeer, in plain text, want bij MITM wordt de encryptie ook doorbroken, dat is nu juist het hele probleem van MITM.

Het maakt geen ene zier uit of het verkeer encrypted is of niet omdat het hele principe van HTTPS en vooral de véél slechtere proprietary 1.3 variant die Google de wereld door z'n strot heeft geduwd, je op geen enkele manier kan beschermen tegen een MITM.

[Ghxst]

Dit klopt niet helemaal. Om een MITM uit te voeren over een HTTPS verbinding moet het doelwit wel een certificaat geïnstalleerd hebben die gegenereerd is door jouw CA. Zolang dit niet het geval is, zul je ook de encryptie niet kunnen "doorbreken".

Echter kun je op dat moment nog steeds wel gewoon de resources zien die geladen worden over HTTP, en dit is vaak ook een manier waarop veel applicaties en websites info lekken.

Ook ben ik wel benieuwd naar je kritiek op TLS 1.3, op welke manier zou deze versie minder bescherming bieden?

[Alfa1970]

Dit klopt niet helemaal. Om een MITM uit te voeren over een HTTPS verbinding moet het doelwit wel een certificaat geïnstalleerd hebben die gegenereerd is door jouw CA. Zolang dit niet het geval is, zul je ook de encryptie niet kunnen "doorbreken".

Nee hoor, een subordinate van een root certificate is voldoende. En er zijn plenty organisaties die een root certificate hebben die door willekeurig welke browser worden vertrouwd. De enige moeilijkheid is om aan zo'n subordinate root te komen. Maar afhankelijk van wie "je" bent hoeft dat niet onoverkomelijk te zijn.

Ik heb niet zozeer een probleem met TLS 1.3, ik heb een probleem met het feit dat Google z'n wil doorduwt met een proprietary versie gebaseerd op een vroege draft die niet zo sterk is als de werkelijke standaard die later uitkwam.

[Ghxst]

Ik neem aan dat je met "een subordinate van een root certificate" een intermediate certificate bedoeld?

Deze maken nog steeds gebruik van een chain of trust, en daarom heeft je browser er geen problemen mee.

Overigens zijn deze intermediate certificates vrij gelimiteerd en kunnen alleen gebruikt worden voor de communicatie binnen desbetreffend domein.

[Alfa1970]

Een intermediate van een Root CA ja. De chain of trust is in dat geval de Root CA zelf.
Een Root CA wordt door alle browsers ten alle tijden vertrouwd, ongeacht welk domein ermee ondertekend is.
Dat is mede waarom het Diginotar verhaal zo'n groot probleem was. En Diginotar was en is niet de enige die gecompromitteerd was/is.

[Ghxst]

Een intermediate certificate kan alleen niet gebruikt worden voor communicatie buiten het domein waar deze voor uitgegeven is.

Google kan bijvoorbeeld geen intermediate certificate aanvragen en die vervolgens gebruiken om jouw traffic naar de Rabobank te decrypten.

Met communicatie over HTTP kan ik dat wel via een MITM op mijn laptopje in een publieke omgeving.

[Alfa1970]

Ik denk dat je niet helemaal goed snapt wat het DigiNotar verhaal inhield.
Het DigiNotar debacle hield in dat een subordinate van het Root CA certificate waarmee bijvoorbeeld het Rabobank of Google Certificate is ondertekend in verkeerde handen terecht is gekomen.

Het is met zo'n certificate mogelijk om on-the-fly certificates aan te maken van willekeurig welk domein en die worden automatisch vertrouwd door de browser omdat die subordinates in de Root CA lijst van de browser staan.
De Root CA certificates staan bovenaan in de trust lijst.

Het grote probleem is dan ook dat de "Google" uit het voorbeeld helemaal geen certificate hoeft aan te vragen voor de Rabobank, want "zij" kunnen die zelf ondertekenen met hun eigen Root CA die door elke "Google" browser wordt vertrouwd omdat hun Root CA bovenaan staat in de trust chain in de browser.
Maar bij "Microsoft" kunnen ze met datzelfde Google Root CA certificate óók een Rabobank certificate ondertekenen en die wordt ook door alle "Microsoft" browsers vertrouwd omdat dat Root CA ook bij 'Microsoft" bovenaan in de trust chain staat. (dit is een voorbeeld in analogie van het gegeven voorbeeld).

[Ghxst]

Ik denk dat we afdwalen van mijn initiële argument.

De suggestie dat het hele probleem van een MITM is dat alle encryptie doorbroken zou worden is gewoon weg niet waar.

Je haalt er een zeer uitzonderlijk geval bij om een fundamenteel aspect van een gecentraliseerd systeem te bekritiseren.

Echter is dit geval wel iets waar Chrome tegen bestand is, en daarnaast is het geen run-of-the-mill MITM.

Om te suggereren dat het hele punt van een MITM is dat alle encryptie doorbroken wordt en HTTPS daarbij geen verschil maakt is daarmee dus ook gewoon fout, een aanval op dusdanige schaal waar zowel browser als CA compromised zijn gaat veel verder als alleen een MITM.

[Alfa1970]

Voor een MITM hoef ik de browser zelf niet te kapen, dat is slechts één van de vele mogelijkheden om het netwerk verkeer om te leiden. En het gaat niet om een gewone CA maar een Root CA die compromised /is/.

[Ghxst]

Zelfs met een compromised CA en een compromised DNS zal Chrome nog steeds voor belangrijke websites (waaronder hun eigen domein) jou een warning laten zien bij een MITM aanval waar valse certificaten worden gebruikt die wel gesigned zijn door een compromised CA.

HTTPS is wel degelijk veilig(er) dan HTTP, zelfs bij een MITM aanval op deze schaal (die eigenlijk bijna nooit voorkomt).

[Alfa1970]

Het enige dat Chrome doet, source code beschikbaar, is het controleren van de trust chain, IP adres en domein naam in het certificate.
Het "mooie" van een MITM met een Root CA is dat die alle 3 die zaken onder controle heeft.

[Ghxst]

1) De sourcecode voor de Chrome browser is niet open source (ik denk dat je in de war bent met Chromium, dat is een opensource project waar Chrome op gebaseerd is).

2) Chrome vergelijkt de publieke key voor sommige belangrijke websites met een key die "hardcoded" is in de browser zelf.

Ook al is de CA compromised, hoeft dit niet te betekenen dat de private key van desbetreffend bedrijf compromised is.

Nogmaals om mijn punt duidelijk te maken, er is meer nodig dan een MITM om de encryptie die HTTPS biedt te doorbreken.

[Alfa1970]

Nogmaals om mijn punt duidelijk te maken, er is meer nodig dan een MITM om de encryptie die HTTPS biedt te doorbreken.

Iedereen met een proxy zal je het tegenovergestelde kunnen vertellen.
Een certificate dat vertrouwd wordt door de browser is alles wat nodig is.

[Ghxst]

Nou nee dus, ik heb zelf meerde proxies om network audits te doen en ben dus niet alleen zeer bekend met het uitvoeren van een MITM maar ook hoe HTTPS werkt...
Je hebt echt maar half verstand van dit onderwerp en je bent simpelweg misinformatie / FUD aan het verspreiden.

[Alfa1970]

Ik heb de afgelopen 15 jaar zelf honderden proxies opgezet bij even zovele klanten die exact dit doen, het is slechts een kwestie van de correcte configuratie en geen enkele browser, zelfs Google Chrome niet, heeft er problemen mee, gewoon vanwege het feit hoe het protocol functioneert. Zo lang dat de browser de trust chain kan resolven is er niks aan de hand en gaat die nooit protesteren.

[Ghxst]

Ok maar over wat voor een configuratie hebben we het dan?
Je had het hier enkel over een MITM. Dus geen verdere configuratie bij het doelwit / de cliënt.

Edit: zolang er geen verdere configuratie plaats vindt bij de cliënt gaat de browser wel zeker protesteren op welbekende domeinen waarvan de public key op het certificaat nu niet matched. Sterker nog, dit is ook de rede dat het hele DigiNotar debacle aan het licht is gekomen. Toen wist Chrome het te detecteren voor zijn eigen domeinen en hedendaags pinnen ze public keys voor meer bekende domeinen.

[Reactie gewijzigd door Ghxst op 24 juli 2024 21:50]

[faim]

Afbeeldingen en video's zijn iets lastiger uit te buiten, maar als je afbeeldingen vanaf het zelfde domein gebruikt, krijgen deze ook onversleuteld de cookies van het domein mee, en dit kan gebruikt worden om iemands login-cookies te onderscheppen via een MITM aanval.

Ja dat kan in theorie, maar dan is de implementatie van de website slecht, omdat je secure en non-secure cookies hebt. Secure cookies worden niet in een non-secure request meegestuurd. Hoewel het in dat geval sowieso al slechte implementatie is om je website over TLS te serveren en je content niet.
Nog veel veiliger is je content vanaf een CDN domein serveren en stricte CSP-headers te hanteren.

[mrwiggs]

Waarom is via een CDN veel veiliger dan vanaf je eigen domeinnaam?

[faim]

Het zal met TLS minder uitmaken natuurlijk, maar je cookies van het hoofddomein hangen niet aan alle requests.

[codebeat]

Ja wacht even, alleen als de pagina direct land op www. Als je pagina land op mijndomeinnaamwhatever.ext en je serveert vanaf daar content en cookies, dan is alsnog alles wat daarna geserveerd wordt en alles van eventuele subdomeinen met cookies 'bevuild'. Dus als je CDN een subdomein onderdeel van je site is (om het gemakkelijk te houden - kan een compleet ander IP-adres hebben) dan ontvangt deze alsnog cookies ongeacht wat voor content. Echter wanneer je gebruikers doorverwijst en laat landen op www. dan heb je dat niet en kan een CDN een subdomein zijn. Dat is wat ik heel vaak doe als er geen CDN is en je wilt voorkomen dat andere content (opmaak, afbeeldingen e.d.) cookies ontvangen. Alle content komt dan van www. en al het andere van cdn.

Als je bijvoorbeeld bij de rabobank kijkt, dan land de site nooit op rabobank.nl maar op www,rabobank.nl. Dat is een goede implementatie want dat zorgt ervoor dat je een goed cookies kan managen zonder rare 'bugs'. Maar bijvoorbeeld een bank wil wél cookies en dat heeft met veiligheid te maken. Dat betekend overigens niet dat ze geen CDN hebben. Sterker nog, kunnen dat intern geregeld hebben door alle content over meerdere servers te verspreiden en dat te serveren vanaf één hoofd-/serveerdomein.

[faim]

Nee dat is niet waar, dit ligt er helemaal aan hoe de implementatie is van het wegschrijven van cookies en heeft niks te maken met het www-subdomein.
Ik ben geen fan van het www-subdomain, dit zal ik ook nooit gebruiken, maar ik kan prima mijn content serveren vanaf static.hoofddomein.nl zonder dat deze cookies mee stuurt vanaf hoofddomein.nl.

Dit zit al een tijdje in de rfc6265-specificatie. Het verschil zit em erin hoe je het domein van de cookie specificeert, of eigenlijk niet specificeert moet ik zeggen. Geef je geen domein mee aan de cookie, dan geldt deze alleen voor het huidige domein, dus niet voor subdomeinen:
Set-Cookie: hash=1234567890; Secure; HttpOnly

Geef je wel het domein mee, geldt deze cookie ook voor alle subdomeinen, dus ook bijvoorbeeld static.hoofddomein.nl:
Set-Cookie: hash=1234567890; domain=hoofddomein.nl; Secure; HttpOnly

Hier trouwens een handige site waar je de verschillende behaviours makkelijk kan zien.

[Reactie gewijzigd door faim op 24 juli 2024 21:50]

[hakog2]

Precies! Je was me net voor.

En omdat de cookies niet iedere request meegestuurd worden is het alleen daarom ook al een stukje sneller.

[paradoXical]

Klopt, het gaat mij echter om hoe dit geformuleerd wordt. Nu wekt het de indruk dat plain text potentieel gevaarlijk is en TLS encrypted niet.

[Creesch]

Niet helemaal waar natuurlijk, niet encrypted verbindingen zijn veel gevoeliger voor een man in the middle attack.

[Loggedinasroot]

Ik denk dat hij bedoeld dat malware.com malware kan serveren of dit nou via HTTP of via HTTPS gebeurd. De encrypte maakt niks uit wat je geserveert krijgt.

MitM ligt het uiteraard anders.

[monotype]

Voor MitM heb je toegang tot een netwerk nodig. Dat zal voor criminelen vaak een onversleuteld wifi netwerk zijn want netwerken bij serieuzere internet providers worden (hopelijk) beter in de gaten gehouden, maar MitM is niet de enige manier waarop onversleutelde elementen in een pagina kunnen worden gemanipuleerd. Er kan bijvoorbeeld ook gebruik worden gemaakt van DNS spoofing, waarbij, als niet versleutelde elementen op een pagina van een andere server worden geladen (...), de DNS cache entries voor dat IP worden "gespooft" en de items dus van die andere server worden opgehaald.

<alu hoedje>
Het versleuteld zijn van verbindingen hoeft trouwens een MitM aanval van een overheid (of voldoende grote speler) niet in de weg te staan: Zolang overheden vertrouwde certificaten in de browser ingebakken hebben zitten of bedrijven die dat hebben onder druk kunnen zetten, kunnen ze in theorie (bijna) alles meelezen. Als ze deze mogelijkheid gericht gebruiken bij verbindingen van "high value targets" kraait er geen haan naar.

Er geen misbruik bekend van het CA certificaat van de staat der nederlanden ( nieuws: Mozilla trekt vertrouwen in certificaatautoriteit Staat der Nederland... ).
Het "misbruik" van de Turkse overheids-certificaten ( https://arstechnica.com/i...certificate-accidentally/ ) was per ongeluk.
Sommige andere ongelukjes hebben echter wel geleid tot intrekken van vertrouwen in certificaten (o.a. https://arstechnica.com/i...rity-for-breach-of-trust/ https://www.zdnet.com/art...ecure-certificate-vendor/ ).

Als een overheid stelselmatig vervalste certificaten gaat inzetten om grote groepen burgers te volgen, dan valt dit wel op zoals bij het gebruik van het diginotar certificaat in Iran: https://www.eff.org/deepl...-iranian-diginotar-attack , maar voordat dat gemerkt wordt ben je 200000 gebruikers verder.

Wat dat betreft was de Kazachstaanse aanpak wel bewonderenswaardig. Niks achterbaks aan, gewoon iedereen verplichten een certificaat te installeren, dan weet je tenminste waar je aan toe bent: nieuws: Isp's Kazachstan moeten https-verkeer onderscheppen op last van overheid.

Uitteraard heeft een overheid al de beschikking over de volledige verkeersgegevens van elke verbinding, en met welke server(s) je praat zegt soms al bijna even veel als de inhoud.

TL;DR Tegen domme criminaliteit zal het best wel wat helpen dat alles versleuteld moet worden, maar verwacht vooral niet teveel privacy van het versleuteld zijn van een verbinding, dan word je daarin niet teleurgesteld.
</alu hoedje>

[mae-t.net]

Ik vraag me, over aluhoedjes gesproken, eigenlijk af wat het belang is van Google om overal https te pushen. Dat doen ze al jaren, en dat zal niet alleen uit idealisme gebeuren.

Voordelen op idealistisch niveau zijn het lastiger afluisteren of injecteren van data/credentials bij gevoelige zaken zoals bankieren.
Nadelen zijn bijvoorbeeld een hoger stroomverbruik (relevant op portable devices, maar ook door schaalgrootte op vaste apparatuur) en het soms onnodige gebruik van encryptie waardoor het geheel in theorie onveiliger wordt.

[WhatsappHack]

het soms onnodige gebruik van encryptie waardoor het geheel in theorie onveiliger wordt.

In welk geval is dat?
Ik zou eigenlijk het liefst standaard versleuteling zien. Maak het gewoon onmogelijk om te werken zonder encryptie. Behandel versleuteld verkeer zoals 'onveilige' http nu wordt behandeld en laat sites met een geldig certificaat zoals het is.

Dat energieverbruik valt met de laatste paar generaties processoren, incl SoC's voor mobile devices, wel mee.

[mrkazoodle]

Google heeft er baat bij dat het internet in zijn geheel groeit een bloeit: meer mensen online = opzoekingen = meer reclame. Zodoende helpt het als de beveiliging goed zit en mensen onbevreesd online kunnen: ook je (groot)ouders bijvoorbeeld, of je (klein)kinderen, die je continu loopt te waarschuwen over gevaren en risico's die ze amper begrijpen.

[fastedje]

Het grootste verschil van een TLS/https vebinding is dat er meer round trips zijn om de verbinding op te zetten (zie ook nieuws: Http/3 gaat Googles http-over-quic in plaats van tcp gebruiken

Bij het opzetten van de beveiligde verbinding worden ook asymmetrische ciphers gebruikt zoals RSA of ECDSA, die behoorlijk wat rekenkracht vergen , echter is dit maar eenmalig.

De data over een https vebinding wordt met een block cipher versleutelt en is een stuk efficienter. Deze link laat zijn dat zelfs een stokoude ARM A9 ca 90 MB/s haalt bij met AES: https://calomel.org/aesni_ssl_performance.html

Als je een gemiddelde groote weet van een https request/response dan kan je dit uitrekeken. Ik denk dat het in de praktijk minder dan 5 a 10% zal zijn: dit lever ik heel graag in voor extra veiligheid.

[Reactie gewijzigd door fastedje op 24 juli 2024 21:50]

[Alfa1970]

Zodra man in the middle mogelijk is maakt encrypted of niet encrypted niks meer uit.
HTTPS is een grote wassen neus het biedt geen enkele vorm van veiligheid, bescherming of identificatie.
Zo lang jij niet in staat bent om op beide plaatsen tegelijkertijd op netwerk niveau te zien dat jouw verbinding aankomt met datgene wat jij hebt verzonden en dat jij de informatie krijgt die de OCS verzend dan pas kun je er vanuit gaan dat hetgeen je ziet ook daadwerkelijk hetgeen is dat op de OCS staat en/of dat gegevens die jij verzend aankomen op de plek waar jij denkt dat die aan dient te komen.

Helaas is dat ondoenlijk.
Daarnaast zijn er veel te veel instanties en instellingen die automatisch vertrouwd worden waarvan met vrij grote zekerheid kan worden gezegd dat ze dat niet zijn (inclusief, of misschien wel juist vooral, de overheid).
Je moet dus geen enkele illusie hebben dat HTTPS encryptie ook maar enige vorm van veiligheid of privacy biedt.
En man-in-the-middle gebeurt bij je ISP want die is namelijk wettelijk verplicht om alles wat jij doet vast te leggen.

[lenwar]

Het hele idee achter https is om de zekerheid te hebben dat all het verkeer tussen jou en de webserver versleutelt en ondertekent is. Vooral dat laatste zorgt juist dat een mitm-aanval wordt tegengaan, omdat de tussenpersoon niet de sleutel heeft om te ondertekenen.

Mocht hij bijvoorbeeld op welke manier dan ook name server hebben gekaapt (eventueel met malware op de pc van het slachtoffer) dan zou er geen CA moeten zijn die een geldig ondertekend certificaat af heeft gegeven. Even er vanuit te gaan dat iedereen z'n werk netjes heeft gedaan dus.

Dit filmpje (ong 20 minuten) laat zien hoe simpel het is om een mitm aanval op http-sites uit te voeren, wat dus niet gaat met https.

https://m.youtube.com/watch?v=_BNIkw4Ao9w

Je ISP kan dan ook niet zien wat jij me verbind. Uiteraard wel het ipadres, maar niet welke url daar achter zit. (even los van dat je ISP onversleutelde DNS verzoeken zou kunnen volgen)

Edit: filmpje toegevoegd 😊

[Reactie gewijzigd door lenwar op 24 juli 2024 21:50]

[Alfa1970]

Het hele idee achter https is om de zekerheid te hebben dat all het verkeer tussen jou en de webserver versleutelt en ondertekent is. Vooral dat laatste zorgt juist dat een mitm-aanval wordt tegengaan

én dat is nu de kern van het probleem, mensen die willens nillens continue blijven ontkennen wat er mogelijk is met een MITM.

Er is met HTTPS totaal geen enkele vorm van garantie dat het verkeer tussen jou en de webserver versleuteld is.
Sterker nog je kan er 100% vanuit gaan dat dat niet het geval is in geval van een succesvolle MITM.
Het verkeer tussen jou en de MITM wordt ondertekend met een door jouw webbrowser geaccepteerd certificate. Maar dat is /niet/ het certificate van de webserver. Het is een certificate dat on-the-fly wordt gegenereerd, het lijkt erop alsof alles klopt, je krijgt zelfs een groene balk te zien in je browser, maar toch zit er iemand tussen jou en de webserver in en die kan alles in plain text zien.

Je ISP kan dan ook niet zien wat jij me verbind. Uiteraard wel het ipadres, maar niet welke url daar achter zit.

Ook dat is een foutieve aanname.
Het eerste gedeelte van een HTTPS verbinding vindt dus gewoon plaats in plain text.
Iedereen kan zien waar je naartoe gaat als je een HTTPS verbinding gaat opzetten.

Pas als de encryptie verbinding is opgezet zou in theorie het verkeer volledig versleuteld en niet meer (snel) te achterhalen moeten zijn.

Echter, je ISP zal vervolgens door gebruik te maken van SSL Visibility alsnog al je verkeer in plain tekst kunnen zien, in real time!
Dit is een geavanceerdere techniek waarbij via een side channel wordt gewerkt.
Bij een MITM wordt het verkeer onderschept en onderbroken waar bij in het "midden" het verkeer niet versleuteld is.
Bij SSL Visibility gebeurt de vertaling naar plain text op een side channel waar het verkeer naartoe wordt gekloond. Deze techniek is niet te detecteren op de client.
Aan de server kant zou men in theorie dit kunnen ontdekken alleen wordt er op de serverkant niet naar dit soort "aanvallen" gekeken.

[lenwar]

Heb je dat een voorbeeld van, een één of andere audit? Of een voorbeeld waarin dit gedemonstreerd wordt?

De enige manier hoe mijn browser een certificaat zal accepteren is als die is ondertekend door een door mijn browser geaccepteerde CA. (ik ken dit eigenlijk alleen bij bedrijfsomgevingen doe on the fly een certificaat genereren dat is ondertekend door de bedrijfs CA die met policies naar de bedrijfscomputers is gedistribueerd)

Het eerste stukje is inderdaad nog ongecodeerd. (het SNI verzoek (foute term maar je snapt wat ik bedoel)) hier wordt nog aan gewerkt (encrypted SNI)

SSL Visibility ken ik alleen als Symantec product dat een soort https-proxy is, en ook weer on the fly certificate afhandeld

[Alfa1970]

De enige manier hoe mijn browser een certificaat zal accepteren is als die is ondertekend door een door mijn browser geaccepteerde CA

Exact. En wie hebben die geaccepteerde CA's, naast de bedrijfs CA?
Verisign, Thawte, Symantec, en nog honderden anderen.
Als je het DIGINotar debacle nog niet vergeten bent....

SSL Visibility van idd bijvoorbeeld Symantec kun je op meerdere manieren gebruiken, waarvan één inderdaad als een sort van proxy is. Maar daar heb je net zoals bij de traditionele MITM een certificate voor nodig omdat de client connectie wordt getermineerd op de proxy.

Er is echter een methode waarbij niet wordt uitgegaan van de proxy, en de client verbinding dus niet wordt getermineerd.
Het nadeel van die tweede methode is wel dat je dan niets anders kunt dan alleen meekijken, terwijl je bij een proxy ook zaken daadwerkelijk kan aanpassen zonder dat de client dat door heeft.
Maar alleen mee kunnen kijken is mogelijk al schadelijk genoeg om wachtwoorden e.d. te achterhalen.

[Sando]

Je ISP kan dan ook niet zien wat jij me verbind. Uiteraard wel het ipadres, maar niet welke url daar achter zit.

Ook dat is een foutieve aanname.
Het eerste gedeelte van een HTTPS verbinding vindt dus gewoon plaats in plain text.
Iedereen kan zien waar je naartoe gaat als je een HTTPS verbinding gaat opzetten.

De waarheid ligt in het midden. De ISP ziet de server/hoofddomein/ip waarmee de handshake plaatsvindt. Niet de query.

De ISP kan dus wel zien dat je naar Wikipedia gaat, maar niet welk artikel je leest.

[SuperDre]

tja, maar alleen waan je jezelf nu veilig met een https verbinding, terwijl zowat alle malware sites inmiddels ook gewoon https gebruiken.. Dus de reden vanwege veiligheid op dat gebied is gewoon nonsense..

[fastedje]

Https sites zijn veilig zolang:

-Er geen mixed content is met http en
-Het certificaat is uitgegeven door een CA die niet malafide is (anders worden deze na een belaalde tijd wel gebanned) en
-De site die het certificaat gebruikt te bertrouwen is en zelf niet gehackt is en
-De gebruikte encryptie ondertussen al niet achterhaald is.
Eigenlijk koopt encryptie in alle gevallen je een hoeveheid tijd waarbij je gegevens veilig zijn, hoeveel tijd hangt van de sterkte van de encryptie af.

Verder worden er natuurlijk regelmatig zwakheden in ciphers en protocollen ontdekt waardoor deze hoeveelheid tijd flink af kan nemen.

[SuperDre]

Ofwel wat je zegt maakt het hele https verhaal gewoon bullshit en de enige reden waarom https nu nog een beetje interessant is, is dat je data niet unencrypted over het internet verstuurd wordt, maar verder zegt https dus tegenwoordig helemaal niets mee.
Maar het probleem is nu dus dat een hoop mensen denken, oh https, dus dan zal het wel een te vertrouwen site zijn..
En precies wat je zegt, de betreffende encryptie kan dus ook nog eens achterhaald zijn en daarmee dus man-in-the-middle attack weer mogelijk. Waarbij 'wij' dus niet met zekerheid kunnen zeggen dat de huidige laatste 'standaard' niet al achterhaald is (voor de grootheden)..

[HoeZoWie]

Jij ook hoor, trouwens.
Nee,
ik ben Taal-Ridder, zonder werk... .

Edit Typo

[Reactie gewijzigd door HoeZoWie op 24 juli 2024 21:50]

[LEX63]

Ik vind versleutelde https verbindingen prima als de gebruiker maar een uitzondering kan maken voor bepaalde http websites.

Er zijn oude websites waar al jaren niets mee gebeurd of veranderd maar waar wel een schat aan informatie op staat of downloads.

Ik zou het vreselijk vinden al deze worden geblokkeerd.

[418O2]

Het gaat om gemixte content. Http op een http site is prima. Als je site op https draait, dan mag je dus geen http content laden

[Christoxz]

Er zijn zat oude websites die https hebben maar mixed content waar niks meer mee gebeurd of veranderd.
Er zullen hier dus toch enkele websites onder lijden.

[LEX63]

Vreselijke ontwikkeling.

Worden de eigenaars van deze websites hierover dan ook geïnformeerd.

Dat zou wel zo netjes zijn.

Ik vrees als hier kosten of extra kosten mee gemoeid gaat dat velen websites alsnog verdwijnen.

Lex

[Reactie gewijzigd door LEX63 op 24 juli 2024 21:50]

[Sheean]

Als ze echt oud zijn dan houden ze nog rekening met Internet Explorer, die stond mixed content ook niet toe.

[GertMenkel]

Je lokale webserver heeft niet per definitie HTTPS nodig als je ontwikkelt (localhost wordt gezien als een secure origin). Dit wordt anders als je over het netwerk debugt, maar dat zullen de meeste developers niet doen.

Firefox doet ook al een tijd aan het blokkeren van mixed content. Als Firefox voor je werkt, zal het gedrag van Chrome hier niet veel veranderen.

Overigens ben ik het compleet eens met de beslissing van Google. Ja, dit is irritant als je (denk dat je) een veilig intern netwerk hebt waar HTTPS onmogelijk is. Voor een paar enthousiastelingen met een aantal servers op het thuisnetwerk kan dit inderdaad irritant zijn als je geen zin hebt om een domein te kopen en letsencrypt te gebruiken. Deze mensen zijn echter een minimale minderheid, want ik bedrijfsnetwerken wil je ook niet over HTTP werken namelijk.

Chrome heeft in het verleden een truc toegevoegd voor ontwikkelaars om HTTPS errors te omzeilen (je typte "badidea" op welke HTTPS error dan ook en de warning wordt genegeerd). Na enkele maanden gingen grote bedrijven vervolgens die magische string aan hun gebruikers vertellen omdat ze te incompetent waren om HTTPS op hun omgevingen in te richten. Nu is de string veranderd naar "thisisunsafe", maar het is natuurlijk een kwestie van tijd tot bedrijven hun readmes aanpassen. Om die reden zijn uitzonderingen voor een paar developers gewoon een slecht idee als het gaat om beveiliging.

Als je geen zin hebt om een echt certificaat aan te vragen, kun je altijd een van de vele gratis tutorials volgen om zelf een CA op te zetten voor ieder domein dat je maar wilt.

[ThomasG]

Tja, het lijkt er een beetje op dat jij vast blijven hangen in het verleden. Een SSL certificaat is, zelfs op je lokale huis-tuin-en-keuken server, in een handomdraai en gratis gebeurt met letsencrypt. Daarnaast is HTTP/2, wat vele voordelen heeft over HTTP/1.1, SSL-only. Als je als developer moderne technieken wilt gebruiken heb je dus indirect SSL nodig. Google Chrome laat trouwens wel gewoon sub domeinen zien, alleen niet als het "subdomain" www. is; want dat is vrij nutteloze en redundante informatie.

[valkenier]

Lets encrypt moet wel geregeld een verificatie/update uitvoeren. De GUIs van mijn router en NAS hebben een self-signed certificate. Als ik dat wil veranderen moeten de poorten naar buiten open, om een certificaat te verifieren. Ik houd die poorten liever alleen lokaal bereikbaar.

[mschol]

sterker nog, de gemiddelde consumenten apparatuur bied niet eens de optie een geldig certificaat te installeren (en voor de normale mensen zonder domeinen of wat dan ook is dat niet te doen)

ik zie het op mijn router ook: leuk die waarschuwing bij https, maar geen enkel certificaatboer gaat router.local voor mij in een geldig certificaat zetten (of fritz.box voor de fritzboxen)

[mj.oke]

als ik dit lees verandert er niets aan het selfsigned certificaat (op je prive server)
nog steeds keer op keer uitzondering toevoegen en je kan door

ook veranderd er niets op de al oude http pagina's
die worden nog steeds in de balk als onveilig of onbeveiligd weer gegeven

als extra worden nu https pagina's waar wat http content opstaat de http content geblokkeerd
lijkt mij een strak plan, https denk je is veilig, blijkt er intussen allerlei dingen niet https te zijn
of 100% of 0% , maar een uitzondering optie toevoegen voor de tweaker blijft welkom

voor de oude internetgarde klinkt dit overdreven, voor mij ook
voor de doorsnee burger is het een erg goed idee,

we doen tegenwoordig veel meer belangrijkere dingen via http protocol dus ja, extra beveiliging op "kan bijna niet fout model" is een goed idee

[Ventieldopje]

Ik weet dat het allemaal lastige materie is maar dit is paniek om niks. Het gaat hier om mixed content, niet om self-signed SSL certificaten, die blijven gewoon werken en is ook gewoon HTTPS.

[RobinF]

Of een API naar een DNS Aanbieder

[GoBieN-Be]

www is zeker geen nutteloze informatie. Mensen kunnen daardoor ten onrechte er van uit gaan dat de site ook bereikbaar is zonder de www prefix en dat is niet altijd het geval.

Een goed voorbeeld is bijvoorbeeld active directory domein, daar kun je een www subdomein naar een webserver sturen, maar je root domein verwijst altijd naar de DC.

En om terug ontopic te gaan is dit wel een probleem voor websites die externe content tonen, zoals bijvoorbeeld een forum waar de gebruiker [IMG] tags kan gebruiken met niet-https URL's.

[Reactie gewijzigd door GoBieN-Be op 24 juli 2024 21:50]

[The Zep Man]

Een goed voorbeeld is bijvoorbeeld active directory domein, daar kun je een www subdomein naar een webserver sturen, maar je root domein verwijst altijd naar de DC.

Dat is helemaal geen goed voorbeeld. Een AD domein zou als root een DNS subdomein kunnen gebruiken, zoals ad.domein.ext. Vaak wordt dat iets van ad.intranet.domein.ext. Die hoef je natuurlijk alleen in eigen DNS servers te configureren.

[mae-t.net]

"vast bent blijven hangen in het verleden" en hoe makkelijk het wel niet is om moderne technieken te gebruiken. Klinkt allemaal leuk (voor zover het niet denigrerend klinkt), maar zijn niet echt redenen om die technieken te gebruiken.

[watercoolertje]

Nu is de rede wel er wel, het werkt straks niet meer

Wat er nu gebeurt is stap 1, maar het gaat gewoon verdwijnen.

[fastedje]

Het is toch niet zo eenvoudig voor iedereen om een SSL certificaat aan te vragen en te gebruiken:

1. Je hebt een publiek IP nodig waar je een Let's Encrypt cert op aan kan vragen.
2.Je moet een eigen DNS hebben op je lokale netwerk waar je de hostname van het certificaat op je eigen interne server IP op kan mappen, of
3. Je moet het externe IP wat bij de hostname van het certificaat hoort kunnen herrouteren naar je interne server IP.

[Creesch]

Je lokale webserver met 100% unencrypted content zal nog steeds prima weergegeven worden als ik het goed lees. Het gaat om gemixte content in dit geval. Verder ben ik het wel met je eens en gebruik ik zelf ook firefox, maar als ik eerlijk ben is dit één van die dingen die ik ook nog wel in firefox verwacht op een bepaald ogenblik.

[Martinspire]

Als jij vanuit je webserver dingen deelt met andere sites die wel via HTTPS werken, dan gaat het natuurlijk wel stuk. Zelfs met plaatjes

[jvvj]

Http wordt enkel geblokkeerd op https pagina's. Als je geen certificaat op jouw lokale webserver hebt blijft je website op diezelfde server gewoon werken.

[CH4OS]

Heb je het artikel goed gelezen? Het gaat erom dat alles over HTTPS gaat, op het moment dat het domein over HTTPS geserveerd wordt. Doe je dat over HTTP, hoeven andere elementen dat dus ook niet.
En daarnaast is het overigens niet moeilijk om je lokale webserver ook in HTTPS te laten serveren.

Wat sowieso aan te raden is wat mij betreft, zodat de lokale development omgeving zoveel als mogelijk op de productie omgeving lijkt, in het klein.

[rko4u]

Ook al zou dit nodig zijn, dan is een self signed certificaat zo gemaakt, is zelfs een ingebouwde feature van IIS. Lokaal registreren en klaar ben je voor lokale https!

[Menesis]

Ik vind dit te ver gaan. Er zijn zat websites waarbij je alleen informatie leest, waarbij het dan ook geen enkel verschil maakt of een derde partij de inhoud daarvan ziet, want het is toch public. En dat je zo’n website bezoekt kan ook met https gewoon worden gecheckt dus het maakt geen verschil.
Ik denk hierbij vooral aan persoonlijke websites, portfolio sites etc etc.

[Anoniem: 58485]

Als je mixed content op een https website draait, dan heb je het niet goed begrepen. De doelstelling van een fully complaint https website is dat het 100% een beveiligde verbinding zijn moet. Dat is het niet zodra er http content over heen gestuurd wordt.

Als je een website bouwt moet je niet meer werken met http://www.site.nl/css/blaat.css maar gewoon //site.nl/css/blaat.css, met // zoekt de browser namelijk zelf uit of het https of http gebruiken moet.

[Menesis]

Nee juist alleen HTTP en statische content.

[rko4u]

Het gaat niet alleen om de persoonlijke data! Hackers kunnen niet persoonlijke content opvangen en vervangen en Zo je browser overhalen de persoonlijke data naar ze toe te zenden.

[P_de_B]

https://www.troyhunt.com/...atic-website-needs-https/

[Martinspire]

Fijn, en wie gaat mijn gebruikers uitleggen dat het plaatje wat zij op een andere site zien zonder problemen, niet op mijn site gelinkt mag worden omdat het niet veilig is? Waarbij veilig alleen gaat over de verbinding naar het plaatje en niet om het plaatje zelf?

Want oh oh oh de AIVD zal toch eens je meme zien....

[Reactie gewijzigd door Martinspire op 24 juli 2024 21:50]

[triflip]

En linkje naar het plaatje kan nog steeds prima, als je hem ook direct zelf wilt weergeven zal je het plaatje ook zelf moeten gaan hosten of door een https proxy halen.

Zo moeilijk is het allemaal niet. Daarnaast wil je toch ten alle tijden een veilige verbinding bieden.

Stel je voor dat iemand in de MacD jouw site bezoekt en krijgt net door een MitM attack tijdens het laden van die afbeelding wat gratis extra code toegedient dan zal de gebruiker jouw website als boosdoener zien en dan verlies je een bezoeker.

[Martinspire]

Zo moeilijk is het allemaal niet.

Het is anders weer iets extra's wat je op de server moet aanbieden en integreren. Bovendien is het ook weer een extra stuk code die misbruikt kan worden. Wie zegt dat mijn proxy veilig is? In plaats van sites te hacken, hoeven ze dan alleen maar op die proxy's af te gaan, lekker doelwit.

En een MitM bij de MacD is aardig, maar er zijn meer manieren om mensen te misleiden of erop in te hacken voordat het hosten van plaatjes een ding gaat zijn. Het is dan simpeler om simpele sites met zwakke wachtwoorden te hacken dan dit soort fratsen uit te halen. Ik denk dan ook dat dit voor 99+% van de internetbezoekers totaal geen issue is. Prima als je aparte situaties probeert te voorkomen, maar je beinvloed daarmee wel de overige 99+%.

Dit hoort geen standaard feature van browsers te zijn, maar een optionele setting waar je mogelijk in een bedrijfsomgeving baat bij hebt.

[lenwar]

Als het jouw gebruikers zijn, dan jij . En dan leg je uit dat een 'veilige' verbinding het moeilijker maakt voor potentiële kwaadwillenden om iets te serveren wat ze niet hebben opgevraagd.
De AIVD kan het sowieso zien, gezien ze de logs van de ISP kunnen opvragen.

[r1ch_ard]

Ik lees vaak genoeg encryptie zus en zo. Dan komt dat weren. Is er een voorbeeld waar iemand met mitm bijvoorbeeld iemand benadeeld heeft in welke vorm dan ook, met het laden van een frauduleuze afbeelding?

[GertMenkel]

Op de middelbare school heeft iemand via een app op hun telefoon redirects/javascript geïnjecteerd en plaatjes omgedraaid op het onbeveiligde schoolnetwerk door middel van een app op mijn geroote Android-telefoon. Dit was nog in het Android 2.3 tijdperk.

Er was ook een app (firesheep als ik het me goed herinner) die door de cookies van random HTTP-requests te onderscheppen profielen van Facebook users kom hijacken. Origineel een addon voor Firefox overigens.

In Amerika zijn er zeer veel providers die javascript en andere elementen injecteren om klanten te "overtuigen" dat ze een (duur) nieuw modem nodig hebben, dat ze binnenkort hun data moeten ophogen, die jarenlang unieke ID's hebben geïnjecteerd waarmee mensen tussen browsers persoonlijk te volgen waren, en ga zo maar door.

Diverse routers zijn gehackt en hebben onder andere verkeerde DNS settings gekregen waardoor aanvallers in HTTP verkeer ads en andere ongein konden injecteren.

Een bepaalde Nederlandse provider heeft via een transparante image proxy alle HTTP afbeeldingen gecomprimeerd (onder het mom van "bespaart data") waardoor ik op WiFi of over een VPN de full quality pictures moest downloaden. Dit is een minor annoyance vergeleken met de andere voorbeelden maar dat is mij persoonlijk overkomen.

Beantwoordt dat je vraag?

[r1ch_ard]

Jazeker, mijn vraag is beantwoord. Dat zijn belangrijke punten. Ik betreur het dat met met regelmaat er stappen gemaakt worden die mijn forum benadelen. Ik kan niet zondermeer volledig https zijn als gebruikers nog met http afbeeldingen aankomen. Verder steekt het mij dat Google standaarden probeert neer te zetten. Ze houden het technisch netjes maar de gemiddelde internetter die dus nog net begrijpt wat een slotje is, is nou net waar mijn forum het van moet hebben. Helaas loopt de forum software achter, is het door mij custom gemaakt om de nieuwste browser tegemoet te komen maar is het einde wel in zicht. Betaalde oplossingen zijn beter maar het kostenplaatje is jammergenoeg niet evenredig met het club verband van mijn forum.

Nu wijk ik wel wat af van het onderwerp, Facebook draagt bij aan een leeg forum want mensen weten niet meer hoe een forum werkt want Facebook kan het wel, daar is als hobbyist ook niet tegen te customizen.

Samen met Google zie ik mijn forum doodbloeden en ik dacht dat het internet voor de mensen is bedoeld, niet voor bedrijven met een dubbeke agenda welke in bed liggen met een zich niet nader bekendmakende overheid.

[GertMenkel]

Forums zijn een lastig ding inderdaad. Voor zover ik weet heeft tweakers dit opgelost door alle oude plaatjes die over HTTP gingen te proxyen via hun servers, zodat ze nog inladen. Dat lijkt me de enige goede optie om de plaatjes te blijven weergeven.

Zoiets zou je kunnen doen (script schrijven dat door alle posts gaat, afbeeldingen downloaden naar server, url herschrijven naar je eigen cache). Kost wat moeite, maar als je je eigen forumsoftware kan schrijven dan geloof ik dat je zeker de technische capaciteiten hebt om zoiets te schrijven. Het is dan alleen de tijd die het kost om te maken die in de weg zit, maar dat is natuurlijk ook de crux van het probleem.
Voor nieuwe content kun je bij het posten een waarschuwing laten zien dat HTTP-afbeeldingen niet goed werken in moderne browsers met een linkje naar de Google documentatie. Of je zou zo'n zelfde proxysysteem kunnen opzetten voor nieuwe posts als je het je gebruikers makkelijker wil maken.

Eerlijk gezegd denk ik dat we dit probleem nooit hadden gehad als bij de introductie van HTTPS dit soort dingen al goed gedaan werden. Mixed content was vanaf het begin al een ding waarvan we wisten dat het problemen zou veroorzaken maar omdat browsers vroeger zo laks waren, zitten we nu met de gebakken peren. Ik ben zelf blij dat Google en Mozilla hier nu zo goed achteraan zitten maar de oude meuk waarvan het internet vol staat raakt hier wel door verloren (kijk maar naar de aankomende dood van Flash en de vele animatie en spellen die daarmee verloren gaan). Zodra dingen weer op orde lopen, zullen de wijzigingen een stuk minder impact hebben.

Ik ben zelf ook tegen veel standaarden die Google neer wil zetten, maar dit is daar niet een van. Ze mogen hun vage CSS en JS API's van mij houden, AMP mag van mij een pijnlijke door sterven en het weghalen van www. en m. is ronduit achterlijk, maar beter omgaan met HTTPS vind ik een welkome verbetering.

Zodra mixed content uit staat denk ik dat het wel gedaan is met de wijzigingen die jouw soort software kapot maken. Oude HTML API's worden niet snel gewijzigd en helemaal voor simpele pagina's zal er niet veel meer veranderen. Hooguit zal je eens in de paar jaar je TLS ciphers moeten ophogen, maar als je een daar een proxy voor gebruikt als NGINX of HAProxy dan is dat een kwestie van config copy pasten van het tooltjes van Mozilla. Het einde van die onzin lijkt dus in zicht; nog een keer dingen updaten voor HTTPS en je zult er eindelijk klaar mee zijn! Heb hoop dat het beter wordt .

[lenwar]

https://m.youtube.com/watch?v=_BNIkw4Ao9w hier benoemen o.a. Dat isps reclames in http sites injecteren in de vs

[Reactie gewijzigd door lenwar op 24 juli 2024 21:50]

[Anck]

De laatste keer dat ik dit tegen kwam was op een forum (https enabled) met [IMG] tags naar externe content (http only). Dat gaf een mixed content waarschuwing en zal in de toekomst dus stempel onveilig krijgen en uiteindelijk helemaal geblockt worden. Dan moeten we voortaan onze memes ook maar over https linken.

[nsacrawler]

Of zoals Tweakers op dit moment doet, http images door een https proxy halen voordat de gebruiker ze ziet

[Martinspire]

Maar is wel wat onnodig, niet? Dan is het uiteindelijk alleen voor de show

[mae-t.net]

Jep, en een uitstekend voorbeeld van het stroomverbruik dat wereldwijd stijgt door ongepast https-gebruik.

[watercoolertje]

Tja dan blokkeer je toch alle images? Help jij daar iig niet aan mee...

Je hebt in essentie gelijk maar die ene druppel meer of minder in een 100 liter vat, is dat de moeite om je druk over te maken waard? De voordelen ervan zijn vele malen groter dan die paar dingen die wat lame opgelost zijn zoals een https proxy is...

[comecme]

Nee hoor. Hierdoor kan een MITM niet meer plaatsvinden tussen mij en tweakers.net.

[GodlikeGiles]

Dit was al het geval?
Heb op mijn site een gedeelte waar met iframes wordt gewerkt en content van andere sites wordt getoond en daarvoor heb ik een speciaal HTTP gedeelte moeten opzetten omdat die HTTP content niet op een HTTPS site getoond kon worden. En dat is al enkele jaren terug.

[Redbaard]

Uit het artikel:
Chrome blokkeert dergelijke gemixte content op dit moment al in bepaalde gevallen. Dat gebeurt als het gaat om onversleutelde scripts of iframes

[Bellamy]

Dus in principe wat de HTTPS Everywhere extensie in je browser doet? Ik kan het iedereen aanbevelen icm uBlock Origin (blokkeert ads) en Ghostery (blokkeert trackers)

[Anoniem: 1264688]

Ben mee eens het heeft geen zin om HTTP te blokeren, want zoals eerder werd aangegeven is er niet zo veel verschil kwa veiligheid tussen Http en HTTPS bij website laten maken word toch vaak voor HTTPS gekozen