Как Protonmail блокируется в России.
Совершенно рутинный трабл-тикет в нашу техподдержку вскрыл очередную странную блокировку довольно значимого для уважающего свои интернет-свободы сообщества сервиса Protonmail в некоторых сетях России. Не хотелось бы эксплуатировать «жёлтый заголовок», но история странная и несколько возмутительная.
Важное замечание: разбор продолжается и пока всё в процессе. Может «мальчика и нет», но скорее всего есть. Будет дополняться по мере появления новой информации.
Крупнейшие российские операторы связи МТС и Ростелеком внереестрово блокируют трафик на SMTP-сервера сервиса защищённой электронной почты Protonmail по письму из ФСБ. Судя по всему, уже достаточно долго, но никто особого внимания пока не обращал. А мы вот обратили.
WTF и пригорание продолжается, все участники получили соответствующие запросы и должны предоставить мотивированные ответы.
UPD: МТС предоставили скан письма ФСБ, по которому производится блокировка. Мотивировка: Универсиада и «телефонный терроризм».
UPD: Protonmail удивились методам борьбы с фродом у «этих странных русских» и посоветовали более эффективный вид борьбы через abuse mailbox.
Мы любим наших хабрапользователей за то, что они технически подкованы. Технически подкованные пользователи знают, что такое «компьютерная гигиена». Некоторые из наших пользователей решили воспользоваться сервисом «защищённого email» Protonmail. Оставим в стороне обсуждение самого сервиса, их продукта и бизнес-модели, обсудим только значимые технические моменты.
Мы ежедневно рассылаем достаточно много электронной почты нашим пользователям, а так как мы беспокоимся о своей независимости и об их приватности, мы не используем сторонние сервисы рассылки email (ESP) для рассылки большинства типов сообщений. Для этого мы используем свои мощности, начиная от bare-metal серверов и контролируемых нами MX-серверов, заканчивая шифрованием соединений и владением своими независимыми IP-адресами.
К нам в тикет-систему технической поддержки на прошлой неделе поступило достаточно много обращений от пользователей Protonmail о том, что наши письма до них не доходят.
Конечно, базовым ответом нашей техподдержки было предложение поискать в спаме и прочие типовые решения типовых проблем, но объём обращений побудил разобраться в вопросе подробнее. И тут всё заверте…
Мы стали разгребать почтовые логи и обнаружили, что соединения наших серверов с MX-серверами Protonmail (185.70.40.101, 185.70.40.102) оканчиваются сетевыми тайм-аутами. Это выглядело странно по ряду причин и было похоже на использование механизма блокировок, практикуемых в России.
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, где написано что-то, призывающее срочно заблокировать данные хосты.
Тут уже у всех задействованных в расследовании несчастного трабл-тикета от такой наглости пригорело окончательно и дальнейшее изучение пошло удвоенными темпами.
Был направлен запрос в ФСБ с вопросом о реальности существования такого письма и оснований распоряжения в нём.
Было направлено требование в МГТС предоставить основание блокировки.
После чего уже сидеть на месте не хотелось и были заданы вопросы в профильных чатах одного известного и не используемого в России в силу Закона мессенжера. В телеком-сообществе вопрос был воспринят достаточно вяло в стиле «у меня была практика общения с подобными ситуациями и никто из них не хочет использовать инструменты РКН. Во-первых, это сложно, во-вторых, вывод проблемы на другое ведомство не есть решение проблемы текущим ведомством» и «короче там нужны схема, реквизиты, выписка, контакты, вроде все… и потом провернутся шестеренки, и учтутся все обидки, и родят план, которому надо будет следовать. Могут написать «нужОн съемник» = попадос на кучу бабла), а могут и не написать, если оператор содействует в незаконной блокировке ресурсов)». Ну, тут сложно осуждать, в телекоме с этим головняком приходится работать часто, для людей из телекома слова «сорм», «узел связи», «выгрузки из реестра» не некие эфемерные штуки, а вполне себе реальная ежедневная головная боль.
Подробное исследование показало, что в сети Ростелекома блокировка осуществляется аналогичным способом.
Спустя праздники МТС предоставили скан письма, на основании которого осуществляются мероприятия по блокировке. Конечно же виноваты «мамкины телефонные террористы», а резиновым основанием — Универсиада 2019:
Поступила реакция от представителей Protonmail в reddit и в Твиттере, как и ожидалось, они несколько удивились методам борьбы с фродом и посоветовали теснее сотрудничать с ними в деле поимки нарушителей общественного порядка.
Повторимся, оставив за скобками всю законодательную инициативу, связанную с регулированием Интернета в отдельно взятой 1/(8+) части суши, отметим, что есть правила игры. Они ненадёжные, постоянно меняющиеся и не всем очевидные. Но они правила, хотя и дающие суровую фору мэйнтейнерам данных правил. Но даже в этом случае находятся желающие эти правила обойти и вытащить дурно пахнущий туз из рукава. Как раз данный случай показывает в действии механизм «без суда и следствия», даже Кафке тут поживиться нечем.
Причём, удивительное рядом: по этому письму заблокированы только SMTP-сервера сервиса. Web-доступ очень даже здравствует, что ставит под сомнение эффективность этих мероприятий.
Итак, это вся фактология по этому кейсу на данный момент. Все запросы разосланы, ответы пока не получены. Есть, конечно, слабая надежда, что это всё следствие кривых рук в МТС и РТ, но честно говоря, такая версия не выглядит состоятельной.
Что касается наших пользователей, которые по совместительству пользователи Protonmail, то они могут продолжать пользоваться своими ящиками на Protonmail в связке с Хабром, так как мы перемаршрутизировали трафик от нас к серверам Protonmail через иного российского оператора, который такими штуками не занимается. И, судя по всему, у МГТС тоже скоро станет на одного клиента меньше.
