Исследователи проанализировали методы локального перехвата HTTPS-трафика

Исследователи проанализировали методы локального перехвата HTTPS-трафика

Исследователи проанализировали методы локального перехвата HTTPS-трафика

Группа, в которую вошли исследователи из ряда известных университетов, а также представители Mozilla, Cloudflare и Google, провела анализ распространения методов локального перехвата HTTPS-трафика и влияния такого перехвата на сетевую безопасность.

Результаты превзошли ожидания исследователей, оказалось, что 4-11% HTTPS-трафика перехватывается и анализируется сторонним ПО на стороне клиента (антивирусное ПО, межсетевые экраны), при этом в большинстве случаев подобный перехват приводит к уменьшению уровня защиты соединения.

Под локальным перехватом подразумеваются случаи анализа HTTPS-трафика с использованием программного обеспечения, установленного на системе пользователя (например, антивирусное ПО), или применением корпоративных шлюзов инспектирования трафика, работающих в виде прокси. Подобные системы перехватывают обращение клиента, затем от своего лица и с собственным сертификатом транслируют HTTPS-запрос на сервер, получают ответ и отдают его клиенту в рамках отдельного HTTPS-соединения, установленного с использованием SSL-сертификата перехватывающей системы. Для сохранения индикатора защищённого соединения в браузере на машины клиента устанавливается дополнительный корневой сертификат, позволяющий скрыть работу применяемой системы инспектирования трафика, пишет opennet.ru.

Исследователи разработали ряд эвристических методов, позволивших на стороне сервера выявить факты перехвата HTTPS и определить какие именно системы использовались для перехвата. На основании заголовка User Agent определялся браузер, а затем сравнивались специфичные для браузера и фактические особенности устанавливаемого TLS-соединений. Более того, сопоставив такие характеристики TLS-соединения, как параметры по умолчанию, поддерживаемые расширения, заявленный набор шифров, порядок определения шифров и методы сжатия, удалось достаточно точно определить конкретный продукт, применяемый для перехвата трафика.

 

 

Серверные компоненты для определения подмены HTTPS-соединения были установлены на серверы распространения обновлений для Firefox, в сеть доставки контента Cloudflare и на некоторые популярные интернет-магазины. В итоге, на серверах обновления Firefox выявлено 4% перехваченных запросов, в интернет-магазинах - 6.2%, а в CDN-сети Cloudflare - 10.9%. В 62% случаев использование корпоративных систем инспектирования снижало безопасность соединения из-за применения менее надёжных алгоритмов шифрования, а в 58% случаев соединения были подвержены известным уязвимостям. В 10-40% случаев системы перехвата анонсировали при установке соединения с сервером поддержку небезопасных шифров, подверженных MITM-атакам.

 

 

Из рассмотренных 12 шлюзов инспектирования только 5 предлагали актуальный набор шифров, 2 вообще не осуществляли верификацию сертификатов (Microsoft Threat Mgmt и WebTitan Gateway).

 

 

24 из 26 протестированных систем перехвата, работающих на компьютере клиента (как правило антивирусы), снижали общий уровень безопасности HTTPS-соединения. Актуальные наборы шифров предоставлялись в 11 из 26 продуктов. 5 систем не осуществляли верификацию сертификатов (Kaspersky Internet Security 16 Mac, NOD32 AV 9, CYBERsitter, Net Nanny 7 Win, Net Nanny 7 Mac). Продукты Kaspersky Internet Security и Total Security подвержены атаке CRIME. Продукты AVG, Bitdefender и Bullguard подвержены атакам Logjam и POODLE. Продукт Dr.Web Antivirus 11 позволяет откатиться на ненадёжные экспортные шифры (атака FREAK).

 

 

Интересно, что поддерживаемая современными браузерами возможность привязки сертификата к сайту (public key pinning) не работает в случае применения систем локального перехвата трафика. Chrome, Firefox и Safari выполняют данную проверку только если цепочка проверки ключей связана с сертификатом удостоверяющего центра. Проверка не выполняется, если цепочка верификации завершается локальным корневым сертификатом, установленным администратором.

Яндекс.Облако обновило оферту: блокировки и удаление контента — без суда

Яндекс.Облако предупредило клиентов о том, что новая редакция оферты даёт провайдеру право блокировать доступ к информации или удалять её по решению уполномоченного государственного органа. При этом судебный акт или предписание правоохранительных органов для таких действий больше не требуются.

Об изменении пользовательских соглашений Яндекс.Облака сообщает ComNews со ссылкой на нескольких пользователей. По данным издания, провайдер уведомил их об изменениях в оферте, которые вступят в силу 28 апреля.

Поправки затрагивают пункты 7.2.1 и 7.2.2 оферты. Они регулируют порядок приостановки доступа к сервисам, а также блокировки или удаления контента, размещённого на ресурсах платформы. Если в предыдущих редакциях оператор услуг мог применять такие меры на основании судебного решения или предписания правоохранительных органов, то в новой версии документа речь идёт уже о требовании «уполномоченного лица».

По мнению источников издания на рынке, такие изменения могут быть связаны с подготовкой к исполнению запрета на размещение VPN-сервисов на ресурсах хостинг-провайдеров. Соответствующее требование включено во второй пакет антимошеннических мер, который сейчас обсуждается в Госдуме.

«"Яндекс" закрепляет некую упрощённую процедуру приостановки сервисов: теперь в компании не будут дожидаться официальных актов от госорганов, что обычно занимало длительное время, а смогут оперативнее реагировать на запросы "приближённых" организаций. Под подозрительной активностью действительно может пониматься работа VPN-серверов в инфраструктуре "Яндекса". Однако эта оговорка может быть направлена и против условных скамеров, которые злоупотребляют бесплатными кредитами и возможностями Yandex Cloud до прохождения полной идентификации и оплаты сервисов», – отметил в комментарии партнёр и руководитель практики Tech компании «Комплай» Сергей Сайганов.

Пресс-служба Яндекса со своей стороны тоже прокомментировала изменения в оферте:

«Изменения в оферте Yandex Cloud не направлены на "расширение практики блокировок" или "подготовку к борьбе с VPN". Их задача — уточнить и сделать более прозрачными основания для возможных ограничений доступа, в том числе зафиксировать, что такие меры могут применяться при поступлении требований от уполномоченных органов в рамках действующего законодательства».

«Речь не идет о произвольной блокировке "по указанию" без правовых оснований. Напротив, изменения отражают уже существующую практику исполнения обязательных требований и направлены на то, чтобы прямо указать их в договоре с пользователями, а не оставлять в обобщенной формулировке "нарушение законодательства". В документе не вводится каких-либо новых механизмов, нацеленных на ограничение работы VPN или иных конкретных сценариев использования сервисов».

RSS: Новости на портале Anti-Malware.ru