Хабрахабр

Как Protonmail блокируется в России

Не хотелось бы эксплуатировать «жёлтый заголовок», но история странная и несколько возмутительная. Совершенно рутинный трабл-тикет в нашу техподдержку вскрыл очередную странную блокировку довольно значимого для уважающего свои интернет-свободы сообщества сервиса Protonmail в некоторых сетях России.

TL;DR

Может «мальчика и нет», но скорее всего есть. Важное замечание: разбор продолжается и пока всё в процессе. Будет дополняться по мере появления новой информации.

Судя по всему, уже достаточно долго, но никто особого внимания пока не обращал. Крупнейшие российские операторы связи МТС и Ростелеком внереестрово блокируют трафик на SMTP-сервера сервиса защищённой электронной почты Protonmail по некому письму из ФСБ. А мы вот обратили.

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

Технически подкованные пользователи знают, что такое «компьютерная гигиена». Мы любим наших хабрапользователей за то, что они технически подкованы. Оставим в стороне обсуждение самого сервиса, их продукта и бизнес-модели, обсудим только значимые технические моменты. Некоторые из наших пользователей решили воспользоваться сервисом «защищённого email» Protonmail.

Для этого мы используем свои мощности, начиная от bare-metal серверов и контролируемых нами MX-серверов, заканчивая шифрованием соединений и владением своими независимыми IP-адресами. Мы ежедневно рассылаем достаточно много электронной почты нашим пользователям, а так как мы беспокоимся о своей независимости и об их приватности, мы не используем сторонние сервисы рассылки email (ESP) для рассылки большинства типов сообщений.

К нам в тикет-систему технической поддержки на прошлой неделе поступило достаточно много обращений от пользователей Protonmail о том, что наши письма до них не доходят.


И тут всё заверте… Конечно, базовым ответом нашей техподдержки было предложение поискать в спаме и прочие типовые решения типовых проблем, но объём обращений побудил разобраться в вопросе подробнее.

Краткое описание, как работает email

С помощью какой-то магии через мгновение письмо появляется в веб-интерфейсе сервиса email получателя. Для большинства современных пользователей Интернета пользование электронной почтой состоит из захода браузером в «личный ящик» на сайте поставщика услуг email, составления и отправки письма получателю через тот же web-интерфейс.

Сервер отправителя отрезает доменную часть (после @) от адреса ящика получателя, делает DNS-запрос для получения списка MX-серверов домена получателя. Так вот: магия называется SMTP (esmtp, если быть точнее). Выглядит это примерно так для адреса support@habr.team:

Он указывает, на каком сервисе email находится электронная почта домена получателя. MX-сервер, дословно «сервер почтового обмена» (mail exchange). suite). То есть, на примере выше видно, что почтовые сервера для нашего домена habr.team находятся на серверах Google (g.

Большее, чем одно, количество серверов в списке сделано для обеспечения отказоустойчивости, так как связность в Интернете зачастую явление условное. После установления списка MX-серверов получателя выполняется обращение по протоколу esmtp(s) к серверу с наименьшим числом приоритета с целью передать почту пользователю.

Передача письма выглядит как-то так:

70. Мы стали разгребать почтовые логи и обнаружили, что соединения наших серверов с MX-серверами Protonmail (185. 101, 185. 40. 40. 70. Это выглядело странно по ряду причин и было похоже на использование механизма блокировок, практикуемых в России. 102) оканчиваются сетевыми тайм-аутами.

Я, конечно, дико извиняюсь, но тут ещё один спойлер: кратко про то, как работает Интернет, автономные системы и глобальная маршрутизация

По факту, у Интернета нет «технического центра» (в отличии от «организационного центра»), это объединение различных сетей, которые как бы равны между собой, хотя бывают сети «равнее» других, но это уже другая история. Вообще, термин «Интернет» переводится дословно примерно как «Между-Сеть», можно перевести как «Сеть сетей» и «Объединение сетей», как кому больше нравится. Каждая автономная система имеет уникальный номер, по которой её идентифицирует иная автономная система в интернете. Сети называются «Автономными системами» (AS) и связаны между собой стыками (пирами). Каждая сеть получает от соседней данные о топологии её соединений с её соседями, соединении её соседей с их соседями и так далее. Похоже на IP-адреса, но более «крупными мазками». Путь по данной карте от одной автономной системы до другой называется AS path. То есть карту соединений автономных систем между собой с точки зрения данного стыка.

У нас два стыка с различными поставщиками услуг Интернета, то есть два возможных AS path от нас до сети Neustar. Например, у нас номер автономной системы (ASN) 204671, сервера Protonmail расположены в сети одной из крупнейших американской сетевой корпорации Neustar, которая имеет ASN 19905. По ряду причин, стык с одним из операторов МГТС у нас приоритетнее, поэтому AS-path получается такой: 204671 (Мы) — 57681 (МГТС) — 8359 (МТС) — 22822 (Limelight) — 19905 (Neustar)

Карта выглядит примерно так:

Traceroute до любого из двух MX-серверов Protonmail оканчивался в сети МТС и выглядел примерно так:

GW-Core-R3#traceroute ip 185.70.40.101 probe 1 timeout 3
Type escape sequence to abort.
Tracing the route to 185.70.40.101
VRF info: (vrf in name/id, vrf out name/id) 1 185.2.126.73 [AS 57681] 2 msec 2 212.188.12.73 [AS 8359] 2 msec 3 195.34.50.73 [AS 8359] 3 msec 4 212.188.55.2 [AS 8359] 3 msec 5 * 6 * 7 * 8 *

Был найден альтернативный хост в сети Neustar и использован в качестве референсного с целью исключить возможные проблемы связности МТС с Limelight:

GW-Core-R3#traceroute ip 156.154.208.234 probe 1 timeout 3
Type escape sequence to abort.
Tracing the route to 156.154.208.234
VRF info: (vrf in name/id, vrf out name/id) 1 185.2.126.73 [AS 57681] 2 msec 2 212.188.12.73 [AS 8359] 2 msec 3 212.188.2.37 [AS 8359] 14 msec 4 212.188.54.2 [AS 8359] 20 msec 5 195.34.50.146 [AS 8359] 27 msec 6 195.34.38.54 [AS 8359] 37 msec 7 68.142.82.159 [AS 22822] 26 msec 8 * 9 156.154.208.234 [AS 19905] 26 msec

Был проведён успешный трэйс через альтернативного оператора до MX-сервера Protonmail (обрывается уже в сети Neustar, но там так и запланировано, соединение с хостом работает):

$ traceroute -a 185.70.40.101
traceroute to 185.70.40.101 (185.70.40.101), 64 hops max, 52 byte packets 1 [AS49063] hidden (hidden) 5.149 ms 268.571 ms 6.707 ms 2 [AS49063] 185.99.11.146 (185.99.11.146) 5.161 ms 6.317 ms 5.476 ms 3 [AS0] 10.200.16.128 (10.200.16.128) 5.588 ms [AS0] 10.200.16.176 (10.200.16.176) 5.225 ms [AS0] 10.200.16.130 (10.200.16.130) 5.001 ms 4 [AS0] 10.200.16.49 (10.200.16.49) 6.480 ms [AS0] 10.200.16.156 (10.200.16.156) 5.439 ms 7.469 ms 5 [AS20764] 80-64-98-234.rascom.as20764.net (80.64.98.234) 6.208 ms 9.301 ms 6.348 ms 6 [AS20764] 80-64-100-102.rascom.as20764.net (80.64.100.102) 24.281 ms [AS20764] 80-64-100-86.rascom.as20764.net (80.64.100.86) 54.632 ms 23.936 ms 7 [AS20764] 81-27-254-223.rascom.as20764.net (81.27.254.223) 27.589 ms 116.438 ms 27.348 ms 8 [AS22822] siteprotect.security.neustar (68.142.82.153) 28.683 ms 25.376 ms 41.489 ms

Вообще, зачастую traceroute штука не очень показательная, но был проведен ряд дополнительных исследований, например, через looking glass сервис МТС:

Однако запрос к специальному сервису РКН показал, что оба адреса не числятся в известном реестре ни по доменному имени, ни по IP-адресу: Стало очевидно, что дело пахнет керосином и похоже на блокировку сервиса по адресу в сети МТС.

Практикуемые иногда блокировки ресурсов без помещения по законной процедуре в реестр получили термин сообщества «внереестровые блокировки», они зачастую имеют сомнительные основания не выдерживающие нормальной юридической экспертизы. Оставим за скобками специфику регулирования Интернета в России и вспомним, что обязательным для исполнения оператором распоряжением о блокировке того или иного ресурса является так называемая «выгрузка из реестра», в которой присутствует заблокированный по той или иной более-менее законной причине ресурс.

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

Ответ был получен не сразу: «это не у нас, а у МТС, туда и идите». В техническую поддержку МГТС было направлено обращение с фиксацией данного факта и просьбой разобраться. Ответ был получен преинтереснейший: по словам сотрудников уполномоченного отдела МТС, к ним обратились уважаемые люди из известной организации ФСБ с письмом, где написано что-то, призывающее срочно заблокировать данные хосты. В МТС за разъяснениями мы, конечно не пошли, а заставили МГТС сделать свою работу и разобраться самостоятельно. 02. Данное письмо пока нам не предоставили, но известна его мета-информация: «исходящий номер 12/T/3/1-94 от 25. 2019».

Тут уже у всех задействованных в расследовании несчастного трабл-тикета от такой наглости пригорело окончательно и дальнейшее изучение пошло удвоенными темпами.

Был направлен запрос в ФСБ с вопросом о реальности существования такого письма и оснований распоряжения в нём:

Было направлено требование в МГТС предоставить основание блокировки:

В телеком-сообществе вопрос был воспринят достаточно вяло в стиле «у меня была практика общения с подобными ситуациями и никто из них не хочет использовать инструменты РКН. После чего уже сидеть на месте не хотелось и были заданы вопросы в профильных чатах одного известного и не используемого в России в силу Закона мессенжера. Могут написать "нужОн съемник" = попадос на кучу бабла), а могут и не написать, если оператор содействует в незаконной блокировке ресурсов)». Во-первых, это сложно, во-вторых, вывод проблемы на другое ведомство не есть решение проблемы текущим ведомством» и «короче там нужны схема, реквизиты, выписка, контакты, вроде все… и потом провернутся шестеренки, и учтутся все обидки, и родят план, которому надо будет следовать. Ну, тут сложно осуждать, в телекоме с этим головняком приходится работать часто, для людей из телекома слова «сорм», «узел связи», «выгрузки из реестра» не некие эфемерные штуки, а вполне себе реальная ежедневная головная боль.

Так или иначе, в чате Общества Защиты Интернета данный кейс был воспринят с энтузиазмом, и было проведено более масштабное исследование проблемы.

Мировое исследование показало проблемы в России, Украине и Иране (исследование доступности основного MX-сервера Protonmail со всего мира, запасного MX-сервера Protonmail со всего мира) Подсказали интересную идею — проверить, а насколько вообще доступны данные MX-сервера от разных операторов связи России и мира через сервис RIPE Atlas, что дало ожидаемый, даже более интересный ответ: по России блокировки соединений осуществляют МТС и Ростелеком, а также, соответсвенно, сети, имеющие соединение через этих провайдеров (исследование доступности основного MX-сервера Protonmail из России, запасного MX-сервера Protonmail из России).

Подробное исследование показало, что в сети Ростелекома блокировка осуществляется аналогичным способом:

В целом, коллега с канала ZaTelecom достаточно понятно объяснил суть: Собственно, почему это возмущает?

Они ненадёжные, постоянно меняющиеся и не всем очевидные. Повторимся, оставив за скобками всю законодательную инициативу, связанную с регулированием Интернета в отдельно взятой 1/6 части суши, отметим, что есть правила игры. Но даже в этом случае находятся желающие эти правила обойти и вытащить дурно пахнущий туз из рукава. Но они правила, хотя и дающие суровую фору мэйнтейнерам данных правил. Как раз данный случай показывает в действии механизм «без суда и следствия», даже Кафке тут поживиться нечем.

Web-доступ очень даже здравствует, что ставит под сомнение эффективность этих мероприятий. Причём, удивительное рядом: по этому письму заблокированы только SMTP-сервера сервиса.

Все запросы разосланы, ответы пока не получены. Итак, это вся фактология по этому кейсу на данный момент. Есть, конечно, слабая надежда, что это всё следствие кривых рук в МТС и РТ, но честно говоря, такая версия не выглядит состоятельной.

И, судя по всему, у МГТС тоже скоро станет на одного клиента меньше. Что касается наших пользователей, которые по совместительству пользователи Protonmail, то они могут продолжать пользоваться своими ящиками на Protonmail в связке с Хабром, так как мы перемаршрутизировали трафик от нас к серверам Protonmail через иного российского оператора, который такими штуками не занимается.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть