Comments 216
Осталось догадаться, что надо научиться работать поверх вебсокета, тогда на хосте на все зондирующие запросы будет отвечать обычный nginx с обычным веб-сайтом. Причём для включения поддержки такой схемы на сервере достаточно обычного websockify.
Но это, видимо, слишком сложно.
Палка о двух концах — либо оно работает, но жрет чуть больше канала и дольше пингуется, либо не работает вообще из-за блокировочек. Проксирование через Tor помнится тоже было довольно небыстрым, однако доступ давало.
лишит Телеграм одного из ключевых преимуществ по сравнению с другими мессенджерами — неприхотливости к каналам связи.
С прокси он уже на EDGE ложится.
Вероятно в этой зоне вообще нет EDGE
Скорее всего проблема в том, что оператор вообще не даёт Интернета, т.к телеграм при хорошем EDGE вполне себе работает.
Так EDGE и не работает. В подавляющем большинстве случаев, когда на экране сияет EDGE даже пинги не проходят. В середине нулевых, помню, на EDGE фильмы с торрентов качал, за ночь 600Мб. А с появлением 3g, EDGE стал работать только там, где он и есть, в глухих деревнях.
Я представитель 34%. Не во всех странах иметь мобильный номер — бесплатная услуга. Для редких звонков в службы 19 века, которые до сих пор не освоили электронную почту, есть скайп с балансом и без абонентки. Для личной переписки — куча мессенджеров. В итоге симкарты с интернетом хватает для 99% задач. Заключать контракт с ОПСОСом и платить постоянную абонентку за сохранение номера только ради аккаунта в телеге? Нет, как-нибудь без меня.
В итоге симкарты с интернетом хватает для 99% задач.
так на нее и регайте, в чем проблема?
даже припейды живут примерно полгода без пополнения.
Наличие номера — не обязательно.
Получается что абонент есть, а номера у него нет?Номер у него, почти наверняка, есть. А вот доставка SMS на этот номер — не осуществляется.
мне казалось что симка это всего лишь ключ для авторизации на базовой станцииТак и есть, но ведь базовая станция — ещё не вся сеть. Есть роутинга SMS на данный номер и звонки не поддерживаются, то это его не нужно хранить в соответствующих таблицах и прочее. Хотя на практике это, скорее всего, всё равно всё происходит и отказ от поддержки SMS — просто способ предложить ещё один тариф.
Обычно это для IoT предлагается: теоретически IoT устройство может принять SMS… но что оно с ним будет делать?
Номинально номер есть. В свойствах девайса можно найти. Смс на него не приходит, звонки, естественно тоже. В контракте он тоже нигде не указ ан, так что я даже не уверен в его неизменяемости.
Припейд симки работают даже год а не пол года без пополнения баланса, но я пользуюсь припейд именно потому, что могу в любое время ее выкинуть. И не хочу вспоминать какие же сервисы были привязаны к ней? Тем более что в отличие от почты тел. номер будет 100% переиспользван другим человеком.
Для использования не припейд карты с тел номером надо заключать контракт минимум на год со штрафом при досорчном расторжении.
Я вообще не понимаю, как можно кичиться какой-то приватностью и безопасностью с такой дырой, как авторизация по телефонному номеру.
Уже сколько новостей было про угон инфы с помощью дубликата или угона номера, и при этом я не припомню не одну статью, где для угона или прослушки воспользовались бы самыми ужасными и нашумевшими poodle ssl или meltdown уязвимостями, неговоря уже про сотни других. Все только в теории
Коннект будет идти до вашего сервера (IP) а вот в заголовке будет передан домен Google.comВполне логично что если сопоставить домен с IP адресом, то он не будет совпадать, следовательно такой трафик может считаться неправильным и вполне может быть отброшен. Как вариант — подставить правильный домен, например из кучи бесплатных dyndns.
- использовать реальный домен, который пренадлежит вам
- использовать текущий вариант подождав введение eSNI тогда на какой домен идёт запрос будет не видно
Основной смысл технологии не прятатся за гуглом а прятатся в HTTPS, анализировать домены (SNI) а потом еще для каждого сопостовлять IP:SNI — очень дорогая операция при проверки блокировок
Зато, если уж сопоставилось, то сразу прописывать бан — явно же какое-то злонамеренное соединение :)
Тогда легко будет конкурентов блочить, шли ему на сервак такое вот не совпадение и все, его блочат. Это будет выстрел в ногу. Можно блочить ркн, тогда они точно введут белые списки
тогда они точно введут белые спискиПосле атак с использованием подставных IP на крупные сайты такой список уже есть, в котором находятся крупные домены/IP которые блочить нельзя.
РКН выстрелы в ногу не смущают нисколько, так как ноги — не их. Поднимется совсем уж буча (как во времена ковровых бомбардировок Телеграм, когда даже Гугл поломали) — исправят. А в остальном проблемы индейцев шерифа не волнуют.
Белые списки, кстати, уже есть, как отметили выше.
Тот же google.com резолвится далеко не в один адрес и его резолв зависит от многих факторов. Как DPI поймет правильный он или нет?
Например, запросы с личного компа во Владимире и с сервера в Москве
nslookup google.com
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: google.com
Address: 173.194.221.100
Name: google.com
Address: 173.194.221.113
Name: google.com
Address: 173.194.221.102
Name: google.com
Address: 173.194.221.138
Name: google.com
Address: 173.194.221.139
Name: google.com
Address: 173.194.221.101nslookup google.com
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: google.com
Address: 64.233.162.138
Name: google.com
Address: 64.233.162.101
Name: google.com
Address: 64.233.162.139
Name: google.com
Address: 64.233.162.113
Name: google.com
Address: 64.233.162.102
Name: google.com
Address: 64.233.162.100
1. Видим обращение к Google.com
2. Записываем увиденный IP
3. Проходимся по всем свежим IP, которые увидели, открываем по https. Если сайт не открылся — блокируем по IP.
Это легко настраивается — установкой типа nginx/Apache и проверкой SNI, если он другой — отправляем в веб сервер. Но тут нужен eSNI.
Если ключ неверный, то отправляем в веб-сервер
Тогда и eSNI не надо ждать. Кроме того, теоретически и с eSNI возможны варианты. Например, РосКомПозор под влиянием очередного обострения может начать сканировать «подозрительные адреса» по принципу «порт 443 открыт — разрешаем во все возможные домены и пытаемся соединиться, всё не соединившееся — в бан, а там Господь отделит своих от чужих». И вообще, поддельный SNI — бессмысленное усложнение.
Телега как раз должна корректный SNI передавать. Если прокси называется kotiki.ru, то и SNI должен быть именно такой, чтобы браузер открыл с ним тех же котиков.
Это позволит заблокировать только публичные адреса, не более, личные прокси будут невидимы.
Ну и самим себе обеспечить сносное существование на период смутного времени.
Это не значит, что нужно заниматься только этим, но и этим нужно заниматься тоже. Чем легче им даётся весь этот беспредел, тем быстрее он продвигается и растёт самоуверенность его инициаторов.
как только соединение рабочее, /16 сетку в блок
Было бы забавно, если бы при этом клиент телегама запрашивал, например, favicon.ico с сайта https://rkn.gov.ru/
Ну и с учётом наличия open source клиента, узнать правильный адрес сервера не представляет никакого труда.Он адреса в т.ч. через системные пуши получает, насколько я понимаю.
По поводу whitelist я согласен, это уже последний бастион.
А вот анализ исходников — это уже совсем не такая тривиальная задача, как поставить телеграм и блокировать все куда он ломиться.
Начнем с того, что только официальные клиенты могут быть разные для разных платформ. А по мимо этого, может быть и куча не официальных клиентов.
Тратить столько ресурсов, что бы заблокировать один единственный мессенджер? Я думаю вайтлист тут куда более вероятен.
Правда там есть еще GGC… Который не всегда принадлежит google…
DNS же можно прописать вручную.Не спорю. Но много ли вы видели обычных пользователей, прописывающих альтернативные DNS при подключении?
В телеграмме уже как год используется свои DNS через DNS OVER HTTS (google/Cloudflare) он не использует провайдерский
Проблема с телегой в т.ч. скачать её — ибо без VPN у меня даже в выдаче гугла telegram.org не появляется.
Поэтому чтобы скачать телегу УЖЕ должен быть работающий впн. Я уже замучился на каждый новый комп первым делом ставить openvpn, и ломиться генерировать очередной ключик.
P.S. Проверил, не все поддомены видит
У меня всегда паранойя, что это зеркало может быть не очень честным, а может даже и злонамеренно открытым, и там может быть на скачивание не совсем правильный телеграм клиент.
С гитхаба ещё можно.
Мобильные — с соответствующих сторов.
Сейчас оба прокси сервера используют домен Google.com при подключении, другими словами ваш провайдер или DPI будет видеть HTTPS коннект к Google.comЕсли мне не изменяет память, Telegram уже пытался использовать domain fronting, прикрываясь доменом Google. Это кончилось тем, что в России был заблокирован доступ к некоторым IP-адресам, в которые резолвился google.com, что приводило к периодической недоступности сервисов Google у абонентов.
eSNI
К сожалению, я навскидку могу придумать со стороны провайдера целых два способа легко заблокировать использование eSMI:
-заворачивать DNS-трафик абонента на свой сервер (как рекомендует Роскомнадзор) и блокировать запрос eSNI из DNS — вот вы используете eSNI, а сертификат у вас прописан? По умолчанию мало у кого прописан, а, допустим, в Firefox его даже и прописать некуда.
— тупо блокировать трафик, если он распознан как HTTPS, но в SNI не удалось заглянуть (с настройками по умолчанию всё тот же Firefox автоматически отключает eSNI, если видит проблемы).
- Telegram жил в облаке гугл
- Telegram запрашивал сайт А в облаке, а подключался к Б в том же облаке
Гугл был против такой схемы, сейчас же вы можете отправлять в заголовке Google а иметь сервер в Hetzner или Digital ocean, гугл может быть против, но сделать ничего не сможет. А сверка SNI:IP — очень дорогое занятие при проверки ресурса на блокировку.
делать ничего не сможетТеоретически может пригрозить удалением такого приложения из маркета.
Подумалось, насколько безумна идея указывать домен какого-нибудь сбера в этом случае.
У Сбера и подобных, IP-адреса весьма жёстко прибиты и будет довольно легко путём простейшего «детектора аномалий» и подобных методов вычислять владельцев таких прокси.
Единственный рабочий вариант это указание собственного домена, чтобы было максимально сложно находить такие прокси
То что сделали телеграмм сейчас (отправка google.com из клиента) это просто подарок для тех, кто занимается вычислением этих прокси. Без задания своего домена я бы не стал связываться.
Домен google.com берется из секрета. Его можно на что угодно заменить.
$ base64 -d <<< 7gAAAAAAAAAAAAAAAAAAAABnb29nbGUuY29t | hexdump -C
00000000 ee 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000010 00 67 6f 6f 67 6c 65 2e 63 6f 6d |.google.com|Раскодируете base64 секрет, берете первые 17 байт из того что получилось — это и есть сам секрет. Потом к ним в конец дописываете любой домен и кодируете обратно в base64.
Но имейте в виду что, например, в Erlang прокси есть опция ограничивающая домены с которыми можно подключаться .
upd: разметка поехала, не знаю как поправить
Вы предлагаете направить на DPI весь HTTPS трафик и во всем трафике проверять SNI, что очень дорого и медленно и есть шанс зацепить что то лишнее, если идёт общение без SNI как такового с намертво прибитым сертификатом у клиента (так делают банковские приложения и не только)
А смысл? Это не решит проблему нагрузки.
Окей, у вас не сошёлся SNI, если такое заблокировать — пострадают банки и любое приложение которое использует фиксированный сертификат прибитый гвоздями. (Ну и весь Энтерпрайз).
Я все ещё не понимаю что даст анализ, особенно если мы предполагаем все же переход на eSNI.
Проблема в том, что этот Fake TLS похож на настоящий примерно так же, как «билеты банка приколов» на настоящие деньги. То есть, если посмотреть, то видно сразу. У энтерпрайза же обычно TLS вполне себе нормальный.
Понятно, что не обязательно делать это для каждого соединения и «вот прям щас».
Ещё есть трафик вообще без TLS SNI. У кровавого энтэрпрайза и им сочувствующих такое случается повсеместно.
Ожидал такой реализации с самого начала.
После пустышки Mproxy, представленный как средство улучшения безопасности, доверия к протоколам телеграма нет (да и к самому телеграмму). Поэтому только VPN.
Для DPI fake TLS выглядит менее приметным чем VPN.
… такой сценарий почти не реалистичен ...Сколько раз за последние несколько лет мы произносили подобные фразы и каждый раз ошибались в определении границ, до которых может дойти.
В Казахстане уже развнедрили. Но никто не мешает сделать заход №2. Ну а в корпоративных сетях свой trust anchor де-факто стандарт, хотя в них, конечно, трафик к мессенжерам отдельно регулируется. Отдельно «белый» MITM любят устраивать всякие антивирусы, впихивая свой суррогатный рут в доверенные. Тоже, кто его знает, что они по факту собирают и в чьих интересах.
Главное чтобы в ответ на вот это вот обновление РКН не выступил с инициативой запретить вообще весь TLS. Для защиты детей разумеется. Впрочем не удивлюсь.
Конец немного предсказуем, из-за HSTS возврат в HTTP невозможен.
Главное чтобы в ответ на вот это вот обновление РКН не выступил с инициативой запретить вообще весь TLS.А зачем ему выступать? Я думаю этот вопрос уже давно прорабатывается на предмет технической реализуемости.
Так как это совершенно логичное решение для страны, которая хочет контролировать сеть в своих границах.
А зачем ему выступать?Ну кто-то же должен стать иницаитором процесса. Если не РКН, то придется «яжматерям» опять платить.
из-за HSTS возврат в HTTP невозможен.Завтра на законодательном уровне запретят сертификаты от заграничных CA и станет «невозможное возможно...» Кто-нибудь еще помнит linkedin?
Хром (и другие боаузеры) не будут ничего делать, можно хоть 10 законов принять.
Не поймите меня неправильно — я резко против, но вижу к чему идет и пока не вижу дна, от которого можно было бы оттолкнуться.
Из вашего списка прогнутся могут только: vk и ya. Остальные этого делать не будут по тем же самым коммерческим причинам, сохранение денег от «прогиба» — намного меньше чем потери от падения акций (и доверия) после такого решения.
не будут по тем же самым коммерческим причинамНу с тайной переписки то и удалением ссылок уже прогнулись. Вопрос в размере потерь и доходов.
В конце концов все в курсе истории с гуглом в Китае.
Я не вижу снижения активности среди моих контаков в линкеде.А я не вижу блокировок вообще (не скажу как). И ПР-ом меня и моих знакомых на выходных не дубасят. Значит ли это, что у нас соблюдается конституция?
Речь не о том, что часть целевой аудитории имеет доступ к линкедину, а о том, что он не общедоступен. И это печально.
Я не вижу снижения активности среди моих контаков в линкеде.
P.S. Работник моего круга, залогинься
Кто-нибудь еще помнит linkedin?Помню, пользуюсь. По ощущением, просадки среди целевой аудитории практически нет.
А зачем? Назначение протоколов разное.
А в TLS-ответе сертификат сервера шифруется или нет? Неужели его не видно, как SNI?..
Telegram притворяется TLSv1.3, а в нем сертификат сервера всегда зашифрован.
Но если мы пойдём медленным путём, повторив соединение от себя (пока eSNI ещё не в деле) — мы без проблем получим реальный сертификат сервера и увидим, что "царь-то ненастоящий"?
Ну да, в текущих реализациях прокси серверов реакция на не-телеграмный tls не такая же как у реального https. Но это поправимо.
1) https://habr.com/ru/post/461171/#comment_20497965
2) Всё-же замечу, что текущие реализации fake-TLS proxy деланы волонтёрами методом реверс-инженеринга. Возможно в официальном это будет как-то иначе решено
в будущем авторы прокси обещают сделать ввод других доменов и возможность не пускать клиентов, если они используют другой домен при согласовании подключения.
Для "ввода других доменов" от прокси ничего не требуется. Что вы положите в base64 секрет после 17го байта то и будет передано как домен.
Блокирование доступа по домену в Erlang прокси уже реализовано https://github.com/seriyps/mtproto_proxy/blob/b6565d23dc2bdafe68587c9b73dd130bb17f019e/src/mtproto_proxy.app.src#L63
Мне кажется, что следующим этапом будет честный SSL (в том числе с mitm), внутри которого уже будет стеганография. Веб-сокеты, вложенный коннект, обмен фотографиями, etc. Одним из интересных приёмов будет DoS атака на DPI, когда понять "телеграм или нет" можно будет только затратив ощутимые ресурсы. Например, bcrypt с большим числом раундов, внутри которого "telegram".
Что такое: “честный SSL с MITM” ?
TLS с настоящим (но, например, самоподписанным) сертификатом, который может перехватить mitm с предъявлением своего сертификата.
когда понять «телеграм или нет» можно будет только затратив ощутимые ресурсы
Такая ли большая проблема в вычислительных ресурсах? Ведь DPI может проверять не все пакеты, а сначала статистически выявлять пары абонент <-> ип, или даже абонент <-> кластер ип, собранный по всей базе абонентов. А потом уже по статистически подозрительным парам семплировать, скажем, анализируя каждый сотый пакет.
Окей, есть облако Google или Amazon или Azure — это 80% Интернета фактически, и что и как выделять кластер?
Во-первых бесполезно сэмплировать пакеты, надо начало сессии. Если у нас есть криптографически тяжёлая процедура ответа на вопрос "tg это или нет", то клиент за коннект платит n ресурсов, и dpi платит за это n ресурсов.
Однако, тут есть плот твист: если dpi начинает платить n ресурсов за проверку "tg или нет", то он начинает его платить и на false positive, т.е. на сессиях, которые не являются tg. Получается существенная амплификация, и если протокол достаточно подлый (т.е. специально сделанный), то понять "что это такое" получится только завершив рассчёт, т.е. честно потратив n ресурсов на каждую сессию.
1. Собрали статистику сессий. Абонент <-> ip
2. Выделили кластер Группа абонентов <-> группа ip, которые по поведению могут быть телеграмом (частота обращений, одновременные рассылки с сервера на много абонентов в моменты публикаций в группах с большим охватом).
3. Каждую n-ую сессию (с элементом рандома) между абонентом из этой группы и ip из этой группы проверяем, затрачивая ресурсы.
4. Если поймали, что таки тг, то заблокировали (в зависимости от отморожености блокирующих, ip, или пару ip<->абонент, или весь кластер, или еще каую-либо комбинацию). Чем сильнее блокировка, тем больше шанс, что кого-то специально подставят, имитируя тг трафик.
Для того, чтобы собрать эту статистику вам потребуется много сессий. А сессия у TG может устанавливаться один раз надолго (в контексте IM).
После того, как вы обнаружите, что IP такой-то кажется, TG и таки заблокируем его, мы переходим к предыдущей, успешно решённой задаче — заблокировать все IP у телеграма.
Ждем рейды по домам от бдительных граждан с повязками "Дружинник", которые будут смотреть, установлена ли телега на компе и телефоне.
На рабочем ПК, который не всегда «П» некоторый персональный софт спрятан в дебрях системных файлов и запускается мной из командной строки определённой командой.
Некоторые менее сознательные вполне могут и с лестницы спустить.
Это следующий уровень закручивания гаек. В принципе, верхняя достигнутая граница довольно высока — Красные Кхмеры убивали за очки на носу (ибо умный).
Это же не силовики с неплохой зарплатой и социальными гарантиями.
Ну а зачем люди в отряды путина вступают и портреты Обам\Трампов жгут?
Санкционированное насилие очень привлекательно для многих.
А тут на подходе мешап сети
А нельзя ли сделать в опросе чек-боксы? Я бы выбрал все варианты.
Или переформулировать вопрос на «какой метод обеспечения защиты следует добавить в первую очередь?»
Я тоже хотел сделать чекбоксы и ранее так можно было, однако сейчас я такого функционала не нашёл :(
А я и при первичной настройке что-то не нашёл :(
Я конечно сейчас (в рамках реалий судебной системы в РФ) наверное глупость скажу, но мне кажется телеграму стоит побороться и на правовом поле. Дело в том, что судебные решения, по которым блокируют прокси сфабрикованы: в них указано что с помощью прокси пррверяющее лицо смогло зайти в запрешённые группы, однако без пароля подключиться к прокси и проверить это невозможно. А такие решения есть даже в отношении тек прокси, пароля от которых заведомо ни у кого кроме владельца не было, и которые найдены тупо по длине пакета.
Расширение аудитории здесь не выгодно, но и не выгодна полная блокировка? Иначе ковровые блокировки целыми подсетями сохранялись бы.
Коовровые блокировки приносят убыток бизнесу и они не выгодны %username%
1.8.1 про этот режим ничего не знает.
Свежее на github не вижу.
Интересно что Signal запретили заниматься подобным когда они собрались обойти блокировку в Эмиратах. Тут у нас опять система двойных стандартов от американских интернет-гигантов или я что-то путаю?
А тут IP, которые Гуглу не принадлежат, так что Гугл ничего сделать не может. Придётся давить ISP и заставлять их подобных клиентов изгонять. Это сложнее.
Первая — TLS-обёртка для соединений. По сути аналог stunnel, но только скрадывает время на установление соединений: https://github.com/Snawoot/ptw. Ей удобно обернуть коннект до того же SOCKS-прокси, а так же можно использовать как прозрачный прокси на роутере. Поддерживается использование самоподписанных сертификатов и сертификатов с subject-ом, не соответствующим адресу хоста.
Вторая — быстрая реализация SOCKS-прокси, аналогичного встроенному в ssh (как
ssh -ND): https://github.com/Snawoot/rsp. По сути сразу предоставляет готовый SOCKS-прокси на стороне клиента, заворачивающий соединения внутрь SSH-туннеля. На стороне сервера требуется только работающий SSH. То есть типичный виртуальный сервер сразу готов к работе в качестве прокси после развёртывания из панели хостера. Преимуществом по сравнению со стандартной реализацией SOCKS в OpenSSH является отказ от мультиплексирования соединения внутри одного тоннеля, поэтому в типичных условиях скорость существенно выше (см. сравнение скорости).В телеграм можно задать свой SOCKS-прокси и добиться устойчивой и скрытой работы этого приложения.
Вот здесь: https://yvoinov.blogspot.com/2019/08/empire-will-strike-back.html интересная критика описанного в статье подхода.
Автор блога — один из соавторов форка nginx.
один из соавторов форкаЗвучит как «знакомый владельца Жигулей». Насколько я помню, форк опенсорс-проекта может сделать каждый желающий, а уж соавтором каждого желающего может быть вообще кто угодно.
Я имел в виду не набор регалий длиной с мою ногу, а специализацию автора, т. е. то, что, судя по блогу, он хорошо знаком с TLS, DPI, проксированием трафика и прочими подобными вещами.
Безотносительно к теме Telegram, блог интересный, рекомендую.
Не выгораживаю данного товарища, но он участвовал в разработке Squid (в плане кода и поддержки на внутреннем форуме).
Вот это сомнительно. Покажите хоть один клиентский серт, имеющий подпись от известного CA. Обычно клиенты как раз валидируются по сертификатам от собственного CA.
На самом деле автор блога прав — весь этот Fake TLS обнаруживается. Особенно в варианте «стучимся на левый айпи, а передаём SNI от google.com». Анализатор возьмёт этот липовый SNI, постучится туда сам, получит нестыковку и скажет «ну ок, следующий час все такие соединения туда дропаем» или отправит IP в РКН как кандидата на бан.
Гораздо правильнее было бы иметь полноценный мультиплексор, который устанавливает полноценную TLS-сессию на «сайт-с-котами.тк» и затем уже внутри неё перенаправляет трафик либо на МТПрото, либо на вебсервер, руководствуясь каким-то секретным ключом.
Что клиенты Телеги постоянно палятся — тоже плохо, так как можно вычислять прокси просто поведенчески, а потом уже никакое шифрование и стеганография не помогут.
В общем, Паша мог бы и чуть побольше напрячься.
Гораздо правильнее было бы иметь полноценный мультиплексор, который устанавливает полноценную TLS-сессию на «сайт-с-котами.тк» и затем уже внутри неё перенаправляет трафик либо на МТПрото, либо на вебсервер, руководствуясь каким-то секретным ключом.
Именно так я и сделал в своём решении. Серверная часть представляет собой haproxy, который разруливает полезную нагрузку для авторизованных клиентов и подключает неавторизованных клиентов на фэйковый HTTP-сервер.
/usr/bin/mtproto-proxy -p 1234 -H 443 -S <SECRET> -D www.google.com --aes-pwd /etc/mtproto/proxy-secret /etc/mtproto/proxy-multi.conf --http-statsто, собрав пользовательский ключ по схеме
ee+<SECRET>+<адрес сайта в HEX>Может, это конечно, очевидно, но я не сразу понял
Неочевидным для меня оказалось то, что к домену в --domain/-D прокси должна иметь доступ, иначе у меня не заработало.
Проверку домена кстати совсем недавно добавили в официальный MTProto. На момент написания комментария такой проверки не было
Или просто использовать TOX.
Telegram наносит ответный удар DPI и блокировкам — Fake TLS