Google o zmianie podejścia do przetwarzania treści mieszanych na stronach otwieranych poprzez HTTPS. Wcześniej, jeśli na stronach otwieranych poprzez HTTPS znajdowały się komponenty, które zostały wczytane bez szyfrowania (poprzez protokół http://), wyświetlany był specjalny wskaźnik. W przyszłości zdecydowano o domyślnym blokowaniu ładowania takich zasobów. Dzięki temu strony otwierane poprzez „https://” będą zawierały wyłącznie zasoby pobrane bezpiecznym kanałem komunikacji.
Należy zauważyć, że obecnie ponad 90% stron internetowych jest otwieranych przez użytkowników Chrome przy użyciu protokołu HTTPS. Obecność wstawek załadowanych bez szyfrowania stwarza zagrożenia bezpieczeństwa poprzez modyfikację niechronionych treści w przypadku kontroli nad kanałem komunikacyjnym (na przykład podczas łączenia się przez otwarte Wi-Fi). Wskaźnik zawartości mieszanej okazał się nieskuteczny i wprowadzający w błąd użytkownika, gdyż nie pozwala na jednoznaczną ocenę bezpieczeństwa strony.
Obecnie najniebezpieczniejsze typy treści mieszanych, takie jak skrypty i ramki iframe, są już domyślnie blokowane, ale obrazy, pliki audio i filmy nadal można pobierać za pośrednictwem witryny http://. Poprzez fałszowanie obrazu osoba atakująca może zastąpić pliki cookie śledzące użytkownika, spróbować wykorzystać luki w procesorach obrazu lub popełnić fałszerstwo, zastępując informacje zawarte w obrazie.
Wprowadzenie blokady podzielone jest na kilka etapów. Chrome 79, którego premiera zaplanowana jest na 10 grudnia, będzie zawierał nowe ustawienie, które umożliwi wyłączenie blokowania określonych witryn. To ustawienie zostanie zastosowane do treści mieszanych, które są już zablokowane, np. skryptów i ramek iframe, i będzie wywoływane poprzez menu rozwijane po kliknięciu symbolu kłódki, zastępując wcześniej proponowany wskaźnik wyłączania blokowania.
Chrome 80, którego premiera ma nastąpić 4 lutego, będzie korzystać z miękkiego schematu blokowania plików audio i wideo, co oznacza automatyczne zastępowanie linków http:// przez https://, co zachowa funkcjonalność, jeśli problematyczny zasób będzie dostępny również przez HTTPS . Obrazy będą nadal ładowane bez zmian, ale jeśli zostaną pobrane przez http://, strony https:// będą wyświetlać wskaźnik niepewnego połączenia dla całej strony. Aby automatycznie przejść na https lub zablokować obrazy, twórcy witryny będą mogli korzystać z właściwości CSP: upgrade-insecure-requests i block-all-mixed-content. Chrome 81, którego premiera zaplanowana jest na 17 marca, automatycznie poprawi http:// na https:// w przypadku przesyłanych obrazów mieszanych.
Poza tym Google o integracji z jedną z kolejnych wersji przeglądarki Chome nowego komponentu Password Checkup już wcześniej w formie . Integracja doprowadzi do pojawienia się w zwykłym menedżerze haseł Chrome narzędzi do analizy wiarygodności haseł używanych przez użytkownika. Kiedy spróbujesz zalogować się do dowolnej witryny, Twój login i hasło zostaną sprawdzone w bazie danych zainfekowanych kont, a w przypadku wykrycia problemów wyświetli się ostrzeżenie. Kontrola przeprowadzana jest w oparciu o bazę danych obejmującą ponad 4 miliardy zainfekowanych kont, które pojawiły się w bazach danych użytkowników, które wyciekły. Ostrzeżenie zostanie również wyświetlone w przypadku próby użycia trywialnych haseł, takich jak „abc123” (by Google 23% Amerykanów używa podobnych haseł) lub gdy używa tego samego hasła w wielu witrynach.
Aby zachować poufność, podczas uzyskiwania dostępu do zewnętrznego API przesyłane są tylko dwa pierwsze bajty skrótu loginu i hasła (stosowany jest algorytm hashujący ). Pełny skrót jest szyfrowany kluczem wygenerowanym po stronie użytkownika. Oryginalne skróty w bazie Google są również dodatkowo szyfrowane i do indeksowania pozostają tylko dwa pierwsze bajty skrótu. Ostateczna weryfikacja skrótów objętych przesyłanym dwubajtowym prefiksem przeprowadzana jest po stronie użytkownika z wykorzystaniem technologii kryptograficznej”„, w którym żadna ze stron nie zna treści sprawdzanych danych. Aby zabezpieczyć zawartość bazy danych zainfekowanych kont przed wykryciem metodą brute-force żądaniem podania dowolnych prefiksów, przesyłane dane są szyfrowane w powiązaniu z kluczem wygenerowanym na podstawie zweryfikowanej kombinacji loginu i hasła.
Źródło: opennet.ru