Google om å endre tilnærmingen til å behandle blandet innhold på sider som åpnes via HTTPS. Tidligere, hvis det var komponenter på sider åpnet via HTTPS som ble lastet fra uten kryptering (via http://-protokollen), ble en spesiell indikator vist. I fremtiden har det blitt besluttet å blokkere lasting av slike ressurser som standard. Dermed vil sider åpnet via "https://" garantert kun inneholde ressurser som er lastet ned via en sikker kommunikasjonskanal.
Det bemerkes at for øyeblikket er mer enn 90 % av nettstedene åpnet av Chrome-brukere som bruker HTTPS. Tilstedeværelsen av innlegg lastet uten kryptering skaper sikkerhetstrusler gjennom modifisering av ubeskyttet innhold hvis det er kontroll over kommunikasjonskanalen (for eksempel ved tilkobling via åpen Wi-Fi). Indikatoren for blandet innhold ble funnet å være ineffektiv og villedende for brukeren, siden den ikke gir en klar vurdering av sikkerheten til siden.
Foreløpig er de farligste typene blandet innhold, som skript og iframes, allerede blokkert som standard, men bilder, lydfiler og videoer kan fortsatt lastes ned via http://. Gjennom bildeforfalskning kan en angriper erstatte brukersporingsinformasjonskapsler, prøve å utnytte sårbarheter i bildebehandlere, eller begå forfalskning ved å erstatte informasjonen som er oppgitt i bildet.
Innføringen av blokkeringen er delt inn i flere stadier. Chrome 79, planlagt til 10. desember, vil ha en ny innstilling som lar deg deaktivere blokkering for bestemte nettsteder. Denne innstillingen vil bli brukt på blandet innhold som allerede er blokkert, for eksempel skript og iframes, og vil bli kalt opp gjennom menyen som ruller ned når du klikker på låsesymbolet, og erstatter den tidligere foreslåtte indikatoren for å deaktivere blokkering.
Chrome 80, som forventes 4. februar, vil bruke et mykt blokkeringsskjema for lyd- og videofiler, noe som innebærer automatisk erstatning av http://-koblinger med https://, som vil bevare funksjonaliteten hvis den problematiske ressursen også er tilgjengelig via HTTPS . Bilder vil fortsette å lastes uten endringer, men hvis de lastes ned via http://, vil https://-sidene vise en usikker tilkoblingsindikator for hele siden. For automatisk å bytte til https eller blokkere bilder, vil nettstedutviklere kunne bruke CSP-egenskapene upgrade-insecure-requests og block-all-mixed-content. Chrome 81, planlagt til 17. mars, vil automatisk korrigere http:// til https:// for opplasting av blandede bilder.
I tillegg Google om integreringen i en av de neste utgivelsene av Chome-nettleseren av den nye Passordsjekk-komponenten, tidligere i formen . Integrasjon vil føre til opptreden i den vanlige Chrome-passordbehandlingen av verktøy for å analysere påliteligheten til passordene som brukes av brukeren. Når du prøver å logge inn på et hvilket som helst nettsted, vil påloggingsinformasjonen og passordet ditt bli sjekket mot en database med kompromitterte kontoer, med en advarsel hvis problemer oppdages. Kontrollen utføres mot en database som dekker mer enn 4 milliarder kompromitterte kontoer som dukket opp i lekkede brukerdatabaser. En advarsel vil også vises hvis du prøver å bruke trivielle passord som "abc123" (av Google 23 % av amerikanerne bruker lignende passord), eller når de bruker samme passord på flere nettsteder.
For å opprettholde konfidensialitet, når du får tilgang til en ekstern API, blir bare de to første bytene av hashen til påloggingsinformasjonen og passordet overført (hashingalgoritmen brukes ). Hele hashen er kryptert med en nøkkel generert på brukerens side. De originale hashene i Google-databasen er også kryptert i tillegg, og bare de to første bytene av hashen er igjen for indeksering. Den endelige verifiseringen av hashes som faller inn under det overførte to-byte-prefikset utføres på brukerens side ved hjelp av kryptografisk teknologi "", der ingen av partene kjenner til innholdet i dataene som kontrolleres. For å beskytte mot at innholdet i en database med kompromitterte kontoer bestemmes av brute force med en forespørsel om vilkårlige prefikser, krypteres de overførte dataene i forbindelse med en nøkkel generert på grunnlag av en verifisert kombinasjon av pålogging og passord.
Kilde: opennet.ru