На фоне блокировки VPN у клиентов Ростелеком упал BitTorrent

На фоне блокировки VPN у клиентов Ростелеком упал BitTorrent

На фоне блокировки VPN у клиентов Ростелеком упал BitTorrent

Несколько дней назад на форуме OpenNet стали появляться жалобы на проблемы со скачиванием Linux-дистрибутивов через BitTorrent — об этом сообщали пользователи услуг «Ростелекома» на Урале и в Краснодарском крае. Как оказалось, провайдер заблокировал соответствующий протокол на уровне DPI (deep packet inspection, глубокая проверка пакетов). В настоящее время ситуация уже исправлена.

Первые жалобы на отказ BitTorrent-каналов появились на OpenNet 3 сентября. Некоторые пользователи столкнулись с выпадением ресурсов из доступа, другие — с торможением трафика. На запрос одного из форумчан в техподдержку «Ростелекома» там ответили, что «торренты — это пиратство, поэтому  они теперь блокируются».

На следующий лень телеоператор вернул доступ к торрентам для обмена ISO-образами популярных дистрибутивов Linux. Сегодня, похоже, была снята блокировка протокола DHT — не исключено, что из-за шумихи в СМИ.

Участники форума OpenNet полагают, что «Ростелеком» заблокировал BitTorrent в рамках новой кампании против VPN в Рунете — по ошибке или умышленно, пока неизвестно, разъяснений провайдер пока не публиковал. Напомним, на прошлой неделе Роскомнадзор объявил о блокировке очередных VPN-сервисов, игнорирующих его требования об ограничении доступа к запрещенному в стране контенту.

Обычно такую карательную меру принимают с помощью технических средств интернет-провайдеров — через системы DPI, установленные ими в соответствии с законом о «суверенном Рунете», который вступил в силу 1 ноября 2019 года. Как показывает практика, такой метод не застрахован от ошибок: похожая акция против Twitter этой весной лишила россиян доступа к множеству других ресурсов и сайтов.

Android 17 спрячет от провайдеров названия посещаемых сайтов

Google добавит в Android 17 платформенную поддержку Encrypted Client Hello (ECH) — технологии, которая скрывает доменное имя сайта на начальном этапе установки защищённого соединения. Провайдерам и владельцам Wi-Fi станет сложнее определять, куда именно ходит пользователь.

Обычный HTTPS шифрует содержимое соединения, но имя запрашиваемого сайта может оставаться видимым в поле Server Name Indication.

ECH закрывает и эту щель, шифруя ClientHello — первую часть TLS-рукопожатия. Технология работает вместе с частным DNS.

Chrome и Firefox уже поддерживают ECH, но Android 17 внедрит защиту на уровне платформы. Она будет включена по умолчанию для приложений, ориентированных на новую версию ОС и использующих совместимые сетевые библиотеки — актуальные OkHttp, WebView или HttpEngine.

 

Если сервер не поддерживает ECH, Android отправит поле-пустышку ECH GREASE. Само доменное имя при этом останется видимым, зато защищённые соединения не будут выделяться среди остальных.

Подразделение Google Jigsaw протестировало механизм на 10 тыс. популярных доменов и в сетях 740 провайдеров из 202 стран, не обнаружив проблем с загрузкой сайтов.

Android 17 также потребует от приложений разрешение на поиск устройств в локальной сети, включит Certificate Transparency по умолчанию и позволит участвующим операторам автоматически отключать 2G для защиты от поддельных базовых станций и СМС-бластеров.

Таким образом, провайдер всё ещё увидит трафик, но список сайтов для любопытного отчёта собрать будет уже заметно сложнее.

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