Guglo pri ŝanĝi la aliron al prilaborado de miksita enhavo sur paĝoj malfermitaj per HTTPS. Antaŭe, se estis komponentoj sur paĝoj malfermitaj per HTTPS kiuj estis ŝarĝitaj de sen ĉifrado (per la http:// protokolo), speciala indikilo estis montrita. En la estonteco, estis decidite bloki la ŝarĝon de tiaj rimedoj defaŭlte. Tiel, paĝoj malfermitaj per "https://" estos garantiitaj enhavi nur rimedojn elŝutitajn per sekura komunika kanalo.
Oni rimarkas, ke nuntempe pli ol 90% de retejoj estas malfermitaj de Chrome-uzantoj uzante HTTPS. La ĉeesto de enigaĵoj ŝarĝitaj sen ĉifrado kreas sekurecajn minacojn per modifo de senprotekta enhavo se estas kontrolo super la komunika kanalo (ekzemple, kiam oni konektas per malferma Wi-Fi). La miksita enhava indikilo estis trovita neefika kaj misgvida al la uzanto, ĉar ĝi ne disponigas klaran takson de la sekureco de la paĝo.
Nuntempe, la plej danĝeraj specoj de miksita enhavo, kiel skriptoj kaj iframoj, jam estas blokitaj defaŭlte, sed bildoj, sondosieroj kaj filmetoj ankoraŭ povas esti elŝutitaj per http://. Per bildfalsado, atakanto povas anstataŭigi uzantajn spurajn Kuketojn, provi ekspluati vundeblecojn en bildprocesoroj aŭ fari falsaĵon anstataŭigante la informojn provizitajn en la bildo.
La enkonduko de la blokado estas dividita en plurajn stadiojn. Chrome 79, planita por la 10-a de decembro, prezentos novan agordon, kiu permesos al vi malŝalti blokadon por specifaj retejoj. Ĉi tiu agordo aplikiĝos al miksita enhavo jam blokita, kiel skriptoj kaj iframoj, kaj estos alvokita per la menuo, kiu malleviĝas kiam vi alklakas la ŝlosilon simbolon, anstataŭigante la antaŭe proponitan indikilon por malŝalti blokadon.
Chrome 80, kiu estas atendita la 4-an de februaro, uzos molan blokadskemon por son- kaj videodosieroj, kio implicas aŭtomatan anstataŭigon de http://-ligoj kun https://, kiu konservos funkciecon se la problema rimedo ankaŭ estas alirebla per HTTPS. . Bildoj daŭre ŝargiĝos sen ŝanĝoj, sed se elŝutite per http://, la https:// paĝoj montros nesekuran konektan indikilon por la tuta paĝo. Por aŭtomate ŝanĝi al https aŭ bloki bildojn, retejprogramistoj povos uzi la CSP-propraĵojn ĝisdatig-nesekurajn-petojn kaj bloki-ĉion-miksitan-enhavon. Chrome 81, planita por la 17-a de marto, aŭtomate korektos http:// al https:// por miksitaj bildaj alŝutoj.
Krome, Google pri la integriĝo en unu el la venontaj eldonoj de la Chome-retumilo de la nova komponanto Password Checkup, antaŭe en la formo de . Integriĝo kondukos al la apero en la kutima administranto de pasvortoj de Chrome de iloj por analizi la fidindecon de la pasvortoj uzataj de la uzanto. Kiam vi provas ensaluti en iu ajn retejo, via ensaluto kaj pasvorto estos kontrolitaj kontraŭ datumbazo de kompromititaj kontoj, kun averto montrata se problemoj estas detektitaj. La kontrolo estas farita kontraŭ datumbazo kovranta pli ol 4 miliardojn kompromititajn kontojn kiuj aperis en likitaj uzantdatumbazoj. Averto ankaŭ aperos se vi provas uzi bagatelajn pasvortojn kiel "abc123" (per Guglo 23% de usonanoj uzas similajn pasvortojn), aŭ kiam ili uzas la saman pasvorton en pluraj retejoj.
Por konservi konfidencon, alirante eksteran API, nur la unuaj du bajtoj de la hash de la ensaluto kaj pasvorto estas transdonitaj (la hash algoritmo estas uzata ). La plena hash estas ĉifrita per ŝlosilo generita flanke de la uzanto. La originalaj haŝiŝoj en la Guglo-datumbazo ankaŭ estas aldone ĉifritaj kaj nur la unuaj du bajtoj de la haŝo restas por indeksado. La fina konfirmo de hashoj, kiuj kategoriiĝas sub la elsendita dubajta prefikso, estas farita flanke de la uzanto uzante kriptan teknologion "", en kiu neniu partio konas la enhavon de la kontrolitaj datumoj. Por protekti kontraŭ la enhavo de datumbazo de kompromititaj kontoj determinita per kruda forto kun peto de arbitraj prefiksoj, la transdonitaj datumoj estas ĉifritaj lige kun ŝlosilo generita surbaze de kontrolita kombinaĵo de ensaluto kaj pasvorto.
fonto: opennet.ru