Roem.ru опубликовал со ссылкой на другой российский источник сообщение о том, что, «вероятно», «весь пользовательский HTTPS-трафик в Казахстане будет с 1 января 2016 года перехватываться и перешифровываться с помощью подставных «сертификатов», что «позволит властям иметь доступ ко всему до этого шифруемому HTTPS-трафику», что дало повод специалистам обсудить такую возможность с технической точки зрения.
Достоверность сообщения сомнительна. В начале «пищевой цепочки», по которой прошла эта новость прежде, чем попасть на авторитетный сайт Roem.ru, находится computerworld.kz, откуда сообщение удалено.
Тем не менее, тема вызвала интерес у специалистов и активно обсуждена на русском языке в социальных сетях. Приводим комментарий автора dxdt.ru Александра Венедюхина, эксперта, хорошо известного в Рунете: «Реализовать перехват TLS-соединений, в том числе, массовый, возможно. Есть готовые программно-технические комплексы, решающие эту задачу. Тем не менее, такой перехват испортит работу целого ряда сервисов. Однако технические подробности предполагаемого нововведения в Казнете опубликованы не были. Насколько можно судить по новостным сообщениям, речь идёт об обязательной установке на клиентские устройства особого доверенного корневого сертификата. Это действительно обычная практика при налаживании систем перехвата TLS — она неплохо известна в корпоративной среде.
Наличие такого сертификата на клиенте позволяет прозрачно перехватывать TLS-соединения (в частности, HTTPS), при условии, что перехватывающее устройство содержит соответствующие секретные ключи. Перехват можно осуществлять и без сертификата. Отдельный сертификат нужен для решения двух задач: во-первых, для маркирования разрешённых соединений; во-вторых, для исключения предупреждений системы безопасности браузера. Маркирование разрешённых соединений позволяет прерывать сессии, которые клиент пытается установить в обход перехватывающей системы.
Чем это грозит простым пользователям? Самая главная угроза: уровень безопасности всякого TLS-соединения сведётся к уровню безопасности перехватывающего узла. На стороне пользователя больше нельзя ни проверить валидность того или иного сертификата, предъявляемого веб-сайтом или каким-либо другим сервисом, ни контролировать прочие параметры безопасности, связанные с удалённым узлом. Распространённой на практике проблемой перехватывающих узлов является их отказ от валидации полученных сертификатов. В таком случае оказывается, что пользовательское ПО принудительно «доверяет всем и вся», что открывает новые перспективы для фишинга. Естественно, сбои и ошибки на перехватывающем узле ставят под угрозу данные пользователей, причём, не только проходящие через этот узел. Риск есть даже в том случае, если сервис, с которым пользователь работает, вполне безопасен. Это главная проблема.
Кроме того, массовый перехват TLS обязательно сломает целый ряд связанных с этим протоколом сервисов. Например, перестанет работать двусторонняя аутентификация, использующая клиентские сертификаты. Не смогут установить соединение с серверами приложения, использующие технологию Key Pinning (за исключением браузеров, в которых есть механизм обхода). Так как со стороны сервера ситуация будет выглядеть так, что соединение устанавливает перехватывающий узел, блокировка этого узла сервером приведёт к тому, что пользователи вообще не смогут достучаться до соответствующего веб-сайта. Ошибки в трансляции сессий могут приводить к тому, что данные одного пользователя окажутся доступны другому пользователю, имеющему аккаунт в том же сервисе.
Это только некоторые проблемы. В целом, можно говорить, что подобный перехват TLS уничтожает инфраструктуру обеспечения безопасности, сложившуюся вокруг данного протокола в глобальном Интернете».
