Snart er det slut med at blande krypteret og ukrypteret indhold i Chrome

Illustration: Bigstock

Fra version 81 vil Chrome blokere for indhold, der ikke kan indlæses via HTTPS.

/tan Fredag, 4. oktober 2019 - 12:205

Fra næste år skærper Chrome-browseren politikken overfor websites, der blander krypteret indhold via HTTPS-protokollen med andre resurser, såsom billeder, lyd, video eller scripts, der hentes med HTTP.

Det skriver mediet Zdnet.

'Blandet indhold', som det kaldes, benyttes blandt andet for at nedsætte resurseforbruget på serversiden, hvor HTTPS stiller højere krav.

I de sidste par år har browsere i almindelighed ignoreret udfordringerne i at gennemskue graden af sikkerheden på en side, der udgøres af blandet indhold - så længe hoveddomænet blev indlæst via HTTPS.

Læs også: Tysk forskning: Ny HTTP-protokol er ikke nævneværdigt hurtigere end forgængeren

Men nu sætter Google altså hælene i.

»I en række skridt, der starter med Chrome 79, vil Chrome gradvist flytte til at blokere alt blandet indhold som standard,« udtalte Google i går.

I version 81, vil Chrome blokere for indhold, der ikke kan indlæses via HTTPS.

Firmaet oplyser også, at 90 procent af trafikken for Chrome-brugere kommer via HTTPS, målt i tid, brugerne bruger på de enkelte sider.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk

Følg forløbet

Kommentarer (5)

Sortér kommentarer

Ældste først
Nyeste først
Bedste først

Martin Storgaard Dieu Fredag, 4. oktober 2019 - 13:37

Is TLS Fast Yet?

benyttes blandt andet for at nedsætte resurseforbruget på serversiden, hvor HTTPS stiller højere krav.

https://istlsfastyet.com/:

Data delivered over an unencrypted channel is insecure, untrustworthy, and trivially intercepted. We owe it to our users to protect the security, privacy, and integrity of their data — all data must be encrypted while in flight and at rest. Historically, concerns over performance have been the common excuse to avoid these obligations, but today that is a false dichotomy. Let's dispel some myths.

Magnus Jørgensen Lørdag, 5. oktober 2019 - 4:10

optimering

Jeg går ud fra at den strøm af data man får fra netflix er krypteret med en speciel DRM kryptering. Hvis Chrome kræver TLS kryptering oven i den DRM kryptering der er brugt spildes der da nogle cpu cycles her og der. Hvilket princip gør at alt skal krypteres med TLS?

Joe Sørensen Lørdag, 5. oktober 2019 - 9:51

Re: optimering

Foreslår du en ny protokol der kun signerer og ikke krypterer indholdet. Det ville faktisk være næsten gratis på serveren og klienter kan så vælge om den vil kontrollere signaturen. Hvilket koster ca det samme som at dekryptere. Men er frivillig.

Hvis man er ligeglad med at andre kan se datastrømen og kun bekymret om at nogen kan ændre der, så giver det faktisk mening. Og hus Netflix kan man tit se på domænenavnet hvilken film du streamer alligevel. Og i TLS sendes den som klartekst.

Magnus Jørgensen Søndag, 6. oktober 2019 - 11:29

Re: optimering

Foreslår du en ny protokol der kun signerer og ikke krypterer indholdet.

Nej, jeg spørger hvilket princip der gør at traffic skal igennem TLS.

Sune Marcher Mandag, 7. oktober 2019 - 14:29

Re: optimering

Jeg går ud fra at den strøm af data man får fra netflix er krypteret med en speciel DRM kryptering. Hvis Chrome kræver TLS kryptering oven i den DRM kryptering der er brugt spildes der da nogle cpu cycles her og der. Hvilket princip gør at alt skal krypteres med TLS?

DRM er per definition 100% spild, så den må Netflix vel bare sluge :-)

Log ind eller Opret konto for at kommentere