English version of the post

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

TL;DR

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

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

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

UPD: МТС предоставили скан письма ФСБ, по которому производится блокировка. Мотивировка: Универсиада и «телефонный терроризм». Чтобы письма с ProtonMail не попадали на тревожные адреса спацслужб и школ.

UPD: Protonmail удивились методам борьбы с фродом у «этих странных русских» и посоветовали более эффективный вид борьбы через abuse mailbox.

UPD: Бравая концепция борьбы ФСБ с ложными обращениями не выдержала критики: письмом поломали входящую почту на ProtonMail, а не исходящую.

UPD: Protonmail пожали плечами и сменили IP-адреса своих MX, таким образом уведя их из под блокировки по этому конкретному письму. Вопрос, что будет дальше открыт.

UPD: Судя по всему, такое письмо не одно и есть ещё набор IP-адресов VOIP-сервисов, которые внереестрово блокируются.

UPD: Так как история стала распространяться за пределы Рунета, подготовили перевод на английский язык, ссылка вверху.

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

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

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





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

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

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



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

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

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



Важное замечание: почта с определённого домена совсем не обязана уходить получателям с указанных в DNS MX-серверов, этот механизм используется только для входящей почты. Исходящая почта с домена может передаваться через иные сервера, примерный список которых указан, как правило, в иной, SPF-записи.

Мы стали разгребать почтовые логи и обнаружили, что соединения наших серверов с 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 со всего мира)

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

Спустя праздники МТС предоставили скан письма, на основании которого осуществляются мероприятия по блокировке. Конечно же виноваты «мамкины телефонные террористы», а резиновым основанием — Универсиада 2019:

Поступила реакция от представителей Protonmail в reddit, в Твиттере и на TechCrunch, как и ожидалось, они несколько удивились методам борьбы с фродом и посоветовали теснее сотрудничать с ними в деле поимки нарушителей общественного порядка:

We have a dedicated team at abuse@protonmail.ch that helps to combat illegal activities. We were never contacted. Blocking MX like this does not make sense for the given "explanation" so we suspect something else is going on. — ProtonMail (@ProtonMail) March 11, 2019

Хм, Протоны сказали, что у кейса может быть двойное дно. Что же, оно оказалось, хотя и слегка дырявое. Итак, под первым спойлером написано, как работает SMTP-взаимодействие между серверами и сказано, что MX-записи — механизм для входящей почты. В общем да, по факту ФСБ постановило сломать входящую почту на Протоне, а не исходящую, так что самоотверженный пассаж про сохранение нервных клеток директоров школ не выдерживает критики. Тут два варианта:

что попалось в руки, то и заблокировали (вариант для ленивых, но по принципу бритвы Оккама наиболее вероятный, кто-то прочитал статью «nslookup для чайников»);

протащили под видом геройства невозможность доставки писем с компроматом от неравнодушных граждан на интересные ящики врагов народа на протоне (очень сложно и не работает в подавляющем большинстве случаев);

Вариант про НЛО, на котором настаивает Вартан Хачатуров.

Пруф на скрине ниже: направленное письмо с ProtonMail на иной сервис показало, что для исходящих писем на этом сервисе используются другие IP-адреса, вполне не заблокированные. Кто тут видит 185.70.40.101 и 185.70.40.102, поднимите руку:

Глава ProtonMail подтвердил сетевому изданию TechCrunch данные заключения, посоветовав бороться с террористической деятельностью в коллаборации с иностранными правоохранительными органами, а не методом засовывания головы в песок, дополнив, что они решили уйти от блокировки:

ProtonMail chief executive Andy Yen called the block “particularly sneaky,” in an email to TechCrunch.



“ProtonMail is not blocked in the normal way, it’s actually a bit more subtle,” said Yen. “They are blocking access to ProtonMail mail servers. So Mail.ru — and most other Russian mail servers — for example, is no longer able to deliver email to ProtonMail, but a Russian user has no problem getting to their inbox,” he said.



“The wholesale blocking of ProtonMail in a way that hurts all Russian citizens who want greater online security seems like a poor approach,” said Yen. He said his service offers superior security and encryption to other mail providing rivals in the country.



“We have also implemented technical measures to ensure continued service for our users in Russia and we have been making good progress in this regard,” he explained. “If there is indeed a legitimate legal complaint, we encourage the Russian government to reconsider their position and solve problems by following established international law and legal procedures.”

— ProtonMail chief executive Andy Yen @ TechCrunch

Итак, Protonmail сменили IP-адреса одного из своих MX с 185.70.40.101 на 185.70.40.103, что исключает его из списка блокируемых ресурсов по данному конкретному письму. Что будет дальше — вопрос.

Как выяснилось, существует ряд доказательств, что подобная схема блокировок применяется к определённому списку иных иностранных email-сервисов и популярных сервисов IP-телефонии. Аналитика по кейсам пока разбирается.

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

Особенно чувствительным к нормальной речи здорового человека не ходить Внимание, тут всё, в целом, верно, но есть технические неточности: AS Neustar никто не блекхолил, в фильтрах исключительно /32 из списка.







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

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

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

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