<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title><![CDATA[Linux Forum &mdash; Исследование негативного влияния на безопасность локального перехвата HTTPS-трафика]]></title>
		<link>https://linuxforum.ru/viewtopic.php?id=38479</link>
		<atom:link href="https://linuxforum.ru/extern.php?action=feed&amp;tid=38479&amp;type=rss" rel="self" type="application/rss+xml" />
		<description><![CDATA[Недавние сообщения в теме «Исследование негативного влияния на безопасность локального перехвата HTTPS-трафика».]]></description>
		<lastBuildDate>Wed, 08 Feb 2017 03:18:37 +0000</lastBuildDate>
		<generator>PunBB</generator>
		<item>
			<title><![CDATA[Исследование негативного влияния на безопасность локального перехвата HTTPS-трафика]]></title>
			<link>https://linuxforum.ru/viewtopic.php?pid=451951#p451951</link>
			<description><![CDATA[<p><br />&nbsp; &nbsp; Группа, в которую вошли исследователи из ряда известных университетов, а также представители Mozilla, Cloudflare и Google, провела анализ распространения методов локального перехвата HTTPS-трафика и влияния такого перехвата на сетевую безопасность. Результаты превзошли ожидания исследователей, оказалось, что 4-11% HTTPS-трафика перехватывается и анализируется сторонним ПО на стороне клиента (антивирусное ПО, межсетевые экраны), при этом в большинстве случаев подобный перехват приводит к уменьшению уровня защиты соединения.&nbsp; &nbsp; &nbsp; Под локальным перехватом подразумеваются случаи анализа HTTPS-трафика с использованием программного обеспечения, установленного на системе пользователя (например, антивирусное ПО), или применением корпоративных шлюзов инспектирования трафика, работающих в виде прокси. Подобные системы перехватывают обращение клиента, затем от своего лица и с собственным сертификатом транслируют HTTPS-запрос на сервер, получают ответ и отдают его клиенту в рамках отдельного HTTPS-соединения, установленного с использованием SSL-сертификата перехватывающей системы. Для сохранения индикатора защищённого соединения в браузере на машины клиента устанавливается дополнительный корневой сертификат, позволяющий скрыть работу применяемой системы инспектирования трафика.&nbsp; &nbsp; &nbsp; &nbsp;Исследователи разработали ряд эвристических методов, позволивших на стороне сервера выявить факты перехвата HTTPS и определить какие именно системы использовались для перехвата. На основании заголовка User Agent определялся браузер, а затем сравнивались специфичные для браузера и фактические особенности устанавливаемого TLS-соединений. Более того, сопоставив такие характеристики TLS-соединения, как&nbsp; параметры по умолчанию, поддерживаемые расширения, заявленный набор шифров, порядок определения шифров и методы сжатия, удалось достаточно точно определить конкретный продукт, применяемый для перехвата трафика.&nbsp; &nbsp; <span class="postimg"><img src="https://www.opennet.ru/opennews/pics_base/0_1486536412.png" alt="https://www.opennet.ru/opennews/pics_base/0_1486536412.png" /></span><br />&nbsp; &nbsp; Серверные компоненты для определения подмены HTTPS-соединения были установлены на серверы распространения обновлений для Firefox, в сеть доставки контента Cloudflare и на некоторые популярные интернет-магазины. В итоге, на серверах обновления Firefox выявлено 4% перехваченных запросов, в интернет-магазинах - 6.2%, а в CDN-сети Cloudflare - 10.9%. В 62% случаев использование корпоративных систем инспектирования снижало безопасность соединения из-за применения менее надёжных алгоритмов шифрования, а в 58% случаев соединения были подвержены известным уязвимостям.&nbsp; &nbsp;В 10-40% случаев системы перехвата анонсировали при установке соединения с сервером поддержку небезопасных шифров, подверженных MITM-атакам.&nbsp; &nbsp; <span class="postimg"><img src="https://www.opennet.ru/opennews/pics_base/0_1486536451.png" alt="https://www.opennet.ru/opennews/pics_base/0_1486536451.png" /></span><br />&nbsp; &nbsp; &nbsp; &nbsp; Из рассмотренных 12 шлюзов инспектирования только 5 предлагали актуальный набор шифров, 2 вообще не осуществляли верификацию сертификатов (Microsoft Threat Mgmt и WebTitan Gateway).&nbsp; &nbsp; <span class="postimg"><img src="https://www.opennet.ru/opennews/pics_base/0_1486536474.png" alt="https://www.opennet.ru/opennews/pics_base/0_1486536474.png" /></span><br />&nbsp; &nbsp; 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).&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Интересно, что поддерживаемая современными браузерами возможность привязки сертификата к сайту (public key pinning) не работает в случае применения систем локального перехвата трафика. Chrome, Firefox и Safari выполняют данную проверку только если цепочка проверки ключей связана с сертификатом удостоверяющего центра. Проверка не выполняется, если цепочка верификации завершается локальным корневым сертификатом, установленным администратором.<br />&nbsp; &nbsp; Источник: <strong>http://www.opennet.ru/opennews/art.shtml?num=45996</strong><br />&nbsp; &nbsp; <br /><a href="http://www.opennet.ru/opennews/art.shtml?num=45996">_источник</a></p>]]></description>
			<author><![CDATA[null@example.com (R2-D2)]]></author>
			<pubDate>Wed, 08 Feb 2017 03:18:37 +0000</pubDate>
			<guid>https://linuxforum.ru/viewtopic.php?pid=451951#p451951</guid>
		</item>
	</channel>
</rss>
