10 September 2016

Chrome начнёт помечать небезопасными страницы, открытые по HTTP

Information Security
Пока люди всего мира изобретают новые полезные технологии, другие люди решают, какие из старых, проверенных, но, вероятно, не таких полезных технологий считать, увы, небезопасным и вредным.
Что же, компания Google сообщила, что с января 2017 (с Chrome версии 56) при просмотре в Chrome сайты, которые передают пароли и номера кредиток по протоколу HTTP (т.е. не по HTTPS), будут маркироваться как небезопасные. Это делается в рамках долгосрочного плана перехода к маркировке всех не-HTTPS сайтов как небезопасных, что должно подтолкнуть владельцев сайтов поголовно переходить на использование HTTPS.

На самом деле, анализ будет проще: браузер станет помечать страницы, полученные по протоколу HTTP, и в которых есть поля для ввода паролей или номеров кредиток — анализ на «передачу паролей и номеров карт по http», судя по всему, делаться не будет. Визуально нововведение будет выглядеть как на картинке выше.

Позиция Google по поводу того, почему еще не так давно считавшимися «нормальными» страницы, получаемые по HTTP, становятся «небезопасными», состоит в том, что в передаваемые по протоколу HTTP объекты (код страниц, содержимое файлов) легко внести изменения в процессе передачи, а содержимое передаваемых данных крайне легко перехватить. Этого риска нет при использовании протокола HTTPS. С учетом этого, корпорация стремится дать пользователям визуальный индикатор риска при использовании конкретных сайтов и их страниц. По сообщениям Google, более половины из загружаемых на десктопах сайтов сегодня уже перешли на использование HTTPS.

В ближайшем будущем Chrome начнет помечать все загруженные по HTTP в режиме «Инкогнито» страницы как небезопасные. В дальнейшем Google планирует помечать все страницы, получаемые по протоколу HTTP, как небезопасные, и помечать их красным треугольником, который сегодня помечают страницы, полученные по «неправильному» HTTPS.

Противники подхода «все на HTTPS» называют свои контраргументы, среди которых:

— не всем сайтам необходимо прятать свое содержимое от посторонних глаз. Скажем, онлайн библиотека или энциклопедия по сути направлены на распространение знаний, и, вероятно, нуждаются в шифровании менее, чем сайт банка.
— не все сайты работают «через» имя домена, масса ресурсов (в т.ч. в интранет) работает с использованием либо IP-адресов, либо «плюшевых» имен (либо действующих только в локальной сети, либо вообще прописанных чуть не в hosts), и на такие «ненормальные» (на самом деле, совершенно обычные) адреса не получить «легальных» сертификатов.
— шифрование создает дополнительную нагрузку как на серверное оборудование, так и на устройства клиентов, что, в частности, может привести к более быстрому разряду смартфона в процессе пользования работающего по HTTPS сайта.
— подозрения в лукавстве Google, которые за благой целью защиты от модификации страниц прячут свою потребность затруднить фильтрацию собственной рекламы и модулей слежения на страницах сайтов мира.
— дополнительные проблемы, которые возникнут у правоохранительных органов и провайдеров при попытке отслеживания трафика в рамках программ, подобных СОРМ, и блокировки тех или иных ресурсов по предписаниям судов, что, вероятнее всего, приведет к форсированию пользователей интернет к установке государственного сертификата на все устройства, с целью обеспечения работы теперь уже государственного, «законного» MITM-решения, по примеру того, как это предполагалось сделать в Казахстане и некоторых других странах.

Отдельно интересна дискуссия по поводу скорости открывания страниц по HTTP и HTTPS (в т.ч. с учетом использования SDPY, HTTP/2 и т.д.) Переход на эти протоколы интересен сайтам, отдаваемых с одного сервера, т.к. ускорение от их использования компенсирует затраты времени на первоначальное установление TLS-соединения. В случае загрузки ресурсов с разных серверов или с CDN, возникают дополнительные вопросы по скорости открывания сайта, что требует дополнительного внимания со стороны администратора сайта.
Tags:chromehttphttpstlsspdyhttp/2let's encryptчерты будущегоMITM в массы
Hubs: Information Security
+23
19.4k 20
Comments 101