Как Protonmail блокируется в России
Совершенно рутинный трабл-тикет в нашу техподдержку вскрыл очередную странную блокировку довольно значимого для уважающего свои интернет-свободы сообщества сервиса Protonmail в некоторых сетях России. Не хотелось бы эксплуатировать «жёлтый заголовок», но история странная и несколько возмутительная.
TL; DR
Важное замечание: разбор продолжается и пока всё в процессе. Может «мальчика и нет», но скорее всего есть. Будет дополняться по мере появления новой информации.
Крупнейшие российские операторы связи МТС и Ростелеком внереестрово блокируют трафик на SMTP-сервера сервиса защищённой электронной почты Protonmail по некому письму из ФСБ. Судя по всему, уже достаточно долго, но никто особого внимания пока не обращал. А мы вот обратили.
WTF и пригорание продолжается, все участники получили соответствующие запросы и должны предоставить мотивированные ответы.
Мы любим наших хабрапользователей за то, что они технически подкованы. Технически подкованные пользователи знают, что такое «компьютерная гигиена». Некоторые из наших пользователей решили воспользоваться сервисом «защищённого email» Protonmail. Оставим в стороне обсуждение самого сервиса, их продукта и бизнес-модели, обсудим только значимые технические моменты.
Мы ежедневно рассылаем достаточно много электронной почты нашим пользователям, а так как мы беспокоимся о своей независимости и об их приватности, мы не используем сторонние сервисы рассылки email (ESP) для рассылки большинства типов сообщений. Для этого мы используем свои мощности, начиная от bare-metal серверов и контролируемых нами MX-серверов, заканчивая шифрованием соединений и владением своими независимыми IP-адресами.
К нам в тикет-систему технической поддержки на прошлой неделе поступило достаточно много обращений от пользователей Protonmail о том, что наши письма до них не доходят.
Конечно, базовым ответом нашей техподдержки было предложение поискать в спаме и прочие типовые решения типовых проблем, но объём обращений побудил разобраться в вопросе подробнее. И тут всё заверте…
Для большинства современных пользователей Интернета пользование электронной почтой состоит из захода браузером в «личный ящик» на сайте поставщика услуг email, составления и отправки письма получателю через тот же web-интерфейс. С помощью какой-то магии через мгновение письмо появляется в веб-интерфейсе сервиса email получателя.
Так вот: магия называется SMTP (esmtp, если быть точнее). Сервер отправителя отрезает доменную часть (после @) от адреса ящика получателя, делает DNS-запрос для получения списка MX-серверов домена получателя. Выглядит это примерно так для адреса support@habr.team:
MX-сервер, дословно «сервер почтового обмена» (mail exchange). Он указывает, на каком сервисе email находится электронная почта домена получателя. То есть, на примере выше видно, что почтовые сервера для нашего домена habr.team находятся на серверах Google (g. suite).
После установления списка MX-серверов получателя выполняется обращение по протоколу esmtp (s) к серверу с наименьшим числом приоритета с целью передать почту пользователю. Большее, чем одно, количество серверов в списке сделано для обеспечения отказоустойчивости, так как связность в Интернете зачастую явление условное.
Передача письма выглядит как-то так:
Мы стали разгребать почтовые логи и обнаружили, что соединения наших серверов с MX-серверами Protonmail (185.70.40.101, 185.70.40.102) оканчиваются сетевыми тайм-аутами. Это выглядело странно по ряду причин и было похоже на использование механизма блокировок, практикуемых в России.
Вообще, термин «Интернет» переводится дословно примерно как «Между-Сеть», можно перевести как «Сеть сетей» и «Объединение сетей», как кому больше нравится. По факту, у Интернета нет «технического центра» (в отличии от «организационного центра»), это объединение различных сетей, которые как бы равны между собой, хотя бывают сети «равнее» других, но это уже другая история. Сети называются «Автономными системами» (AS) и связаны между собой стыками (пирами). Каждая автономная система имеет уникальный номер, по которой её идентифицирует иная автономная система в интернете. Похоже на IP-адреса, но более «крупными мазками». Каждая сеть получает от соседней данные о топологии её соединений с её соседями, соединении её соседей с их соседями и так далее. То есть карту соединений автономных систем между собой с точки зрения данного стыка. Путь по данной карте от одной автономной системы до другой называется AS path.
Например, у нас номер автономной системы (ASN) 204671, сервера Protonmail расположены в сети одной из крупнейших американской сетевой корпорации Neustar, которая имеет ASN 19905. У нас два стыка с различными поставщиками услуг Интернета, то есть два возможных AS path от нас до сети Neustar. По ряду причин, стык с одним из операторов МГТС у нас приоритетнее, поэтому 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-адресу:
Оставим за скобками специфику регулирования Интернета в России и вспомним, что обязательным для исполнения оператором распоряжением о блокировке того или иного ресурса является так называемая «выгрузка из реестра», в которой присутствует заблокированный по той или иной более-менее законной причине ресурс. Практикуемые иногда блокировки ресурсов без помещения по законной процедуре в реестр получили термин сообщества «внереестровые блокировки», они зачастую имеют сомнительные основания не выдерживающие нормальной юридической экспертизы.
Но на тот момент было подозрение просто на техническое недоразумение или неудачную разблокировку ранее осуществляемой блокировки. Да, мы такие, долго проверяем и не хайпим без тщательного фактчекинга.
В техническую поддержку МГТС было направлено обращение с фиксацией данного факта и просьбой разобраться. Ответ был получен не сразу: «это не у нас, а у МТС, туда и идите». В МТС за разъяснениями мы, конечно не пошли, а заставили МГТС сделать свою работу и разобраться самостоятельно. Ответ был получен преинтереснейший: по словам сотрудников уполномоченного отдела МТС, к ним обратились уважаемые люди из известной организации ФСБ с письмом, где написано что-то, призывающее срочно заблокировать данные хосты. Данное письмо пока нам не предоставили, но известна его мета-информация: «исходящий номер 12/T/3/1–94 от 25.02.2019».
Тут уже у всех задействованных в расследовании несчастного трабл-тикета от такой наглости пригорело окончательно и дальнейшее изучение пошло удвоенными темпами.
Был направлен запрос в ФСБ с вопросом о реальности существования такого письма и оснований распоряжения в нём:
Было направлено требование в МГТС предоставить основание блокировки:
После чего уже сидеть на месте не хотелось и были заданы вопросы в профильных чатах одного известного и не используемого в России в силу Закона мессенжера. В телеком-сообществе вопрос был воспринят достаточно вяло в стиле «у меня была практика общения с подобными ситуациями и никто из них не хочет использовать инструменты РКН. Во-первых, это сложно, во-вторых, вывод проблемы на другое ведомство не есть решение проблемы текущим ведомством» и «короче там нужны схема, реквизиты, выписка, контакты, вроде все… и потом провернутся шестеренки, и учтутся все обидки, и родят план, которому надо будет следовать. Могут написать «нужОн съемник» = попадос на кучу бабла), а могут и не написать, если оператор содействует в незаконной блокировке ресурсов)». Ну, тут сложно осуждать, в телекоме с этим головняком приходится работать часто, для людей из телекома слова «сорм», «узел связи», «выгрузки из реестра» не некие эфемерные штуки, а вполне себе реальная ежедневная головная боль.
Так или иначе, в чате Общества Защиты Интернета данный кейс был воспринят с определённым энтузиазмом и было проведено более масштабное исследование проблемы.
Была подсказана интересная идея проверить, а насколько вообще доступны данные MX-сервера от разных операторов связи России и мира через сервис RIPE Atlas, что дало ожидаемый, даже более интересный ответ: по России блокировки соединений осуществляют МТС и Ростелеком, а также, соответсвенно, сети, имеющие соединение через этих провайдеров (исследование доступности основного MX-сервера Protonmail из России, запасного MX-сервера Protonmail из России). Мировое исследование показало проблемы в России, Украине и Иране (исследование доступности основного MX-сервера Protonmail со всего мира, запасного MX-сервера Protonmail со всего мира)
Подробное исследование показало, что в сети Ростелекома блокировка осуществляется аналогичным способом:
Собственно, почему это возмущает? В целом, коллега с канала ZaTelecom достаточно понятно объяснил суть:
Повторимся, оставив за скобками всю законодательную инициативу, связанную с регулированием Интернета в отдельно взятой 1/6 части суши, отметим, что есть правила игры. Они ненадёжные, постоянно меняющиеся и не всем очевидные. Но они правила, хотя и дающие суровую фору мэйнтейнерам данных правил. Но даже в этом случае находятся желающие эти правила обойти и вытащить дурно пахнущий туз из рукава. Как раз данный случай показывает в действии механизм «без суда и следствия», даже Кафке тут поживиться нечем.
Причём, удивительное рядом: по этому письму заблокированы только SMTP-сервера сервиса. Web-доступ очень даже здравствует, что ставит под сомнение эффективность данных мероприятий.
Итак, это вся фактология по данному кейсу на данный момент. Все запросы разосланы, ответы пока не получены. Есть, конечно, слабая надежда, что это всё следствие кривых рук в МТС и РТ, но честно говоря, данная версия не выглядит состоятельной.
Что касается наших пользователей, которые по совместительству пользователи Protonmail, то они могут продолжать пользоваться своими ящиками на Protonmail в связке с Хабром, так как мы перемаршрутизировали трафик от нас к серверам Protonmail через иного российского оператора, который такими штуками не занимается. И, судя по всему, у МГТС тоже скоро станет на одного клиента меньше.
