Исследователи проанализировали методы локального перехвата 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 выполняют данную проверку только если цепочка проверки ключей связана с сертификатом удостоверяющего центра. Проверка не выполняется, если цепочка верификации завершается локальным корневым сертификатом, установленным администратором.

WhatsApp для Windows ест до 1,2 ГБ RAM и тормозит даже на мощных ПК

WhatsApp (принадлежит корпорации Meta, признанной экстремисткой и запрещённой в России) для Windows превратился в прожорливый тормоз, пользователи жалуются на гигабайты памяти и лаги. Пока Meta рассказывает об успехах WhatsApp с его 3 миллиардами пользователей, владельцы Windows-компьютеров всё чаще задаются другим вопросом: как мессенджер умудрился стать настолько медленным?

Журналист Windows Latest опубликовал разгромный материал о текущей версии WhatsApp для Windows, которую Meta перевела на WebView2 — фактически браузерную оболочку на базе Chromium.

По его словам, приложение способно потреблять сотни мегабайт оперативной памяти ещё до аутентификации пользователя. А после входа в аккаунт и активной работы объём занятой памяти легко переваливает за 1 ГБ.

 

При этом проблема не только в аппетитах. Пользователи жалуются на задержки при отправке сообщений, медленное переключение между чатами, подтормаживания интерфейса и нестабильную работу после выхода компьютера из режима сна. Автор утверждает, что браузерная версия WhatsApp в обычной вкладке зачастую работает быстрее, чем официальное настольное приложение.

Особенно тяжело приходится владельцам старых ПК. В качестве примера приводится компьютер с процессором Intel Core i3 шестого поколения и 8 ГБ оперативной памяти. По наблюдениям автора, Windows 11 на такой машине работает вполне бодро, а вот WhatsApp способен загружать процессор более чем на 20 % даже в состоянии простоя.

 

Главным виновником называется переход с нативного UWP-приложения на WebView2. Старая версия WhatsApp для Windows занимала менее 100 МБ памяти и использовала системные механизмы уведомлений. Новая же фактически запускает внутри себя мини-браузер с набором отдельных процессов для рендеринга, сети, хранения данных и других задач.

Досталось и Microsoft. Автор напоминает, что даже корпоративный Teams до сих пор построен на WebView2 и также известен высоким потреблением ресурсов. По его мнению, именно многолетняя непоследовательность Microsoft в развитии собственных платформ заставила разработчиков всё чаще выбирать веб-оболочки вместо нативных приложений.

Самое ироничное в этой истории — у Meta есть полноценный и хорошо оптимизированный WhatsApp для macOS и даже для Apple Watch. А вот для полутора миллиардов пользователей Windows компания предлагает по сути браузерную вкладку, упакованную в отдельное окно и выдаваемую за полноценное приложение.

Напомним, ранее мы рассказывали о способе вернуть быстрый нативный WhatsApp в Windows 11. Речь идёт о версии 2.2546.3.0 от ноября 2025 года — это ещё тот самый UWP-клиент. Если установить её вручную и немного подправить, Windows 11 позволит продолжить пользоваться нативным приложением.

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