Information Security
Instant Messaging Systems
Open source
Network technologies
Comments 215
+13

Осталось догадаться, что надо научиться работать поверх вебсокета, тогда на хосте на все зондирующие запросы будет отвечать обычный nginx с обычным веб-сайтом. Причём для включения поддержки такой схемы на сервере достаточно обычного websockify.


Но это, видимо, слишком сложно.

+10
Новая веб-версия телеграмм (tdweb) которая пишется на WebAssembly работает через WebSocket напрямую с серверами TG, вполне логично, допускаю, что другие клиенты (десктоп, мобильные) получат поддержку WSS серверов и WSS прокси.
+4
Вебсокеты — значит, (пере)подключение с использованием полноценного тяжелого TLS-протокола, а потом еще и HTTP с Connection-Upgrade, что сделает практически невозможным использование соединений с низкой скоростью соединения и/или высокой латентностью, то есть лишит Телеграм одного из ключевых преимуществ по сравнению с другими мессенджерами — неприхотливости к каналам связи.
+9

Палка о двух концах — либо оно работает, но жрет чуть больше канала и дольше пингуется, либо не работает вообще из-за блокировочек. Проксирование через Tor помнится тоже было довольно небыстрым, однако доступ давало.

0
А почему в прошедшем времени о проксировании через Тор?
0

Потому, что после следующего (с начала блокировок) апдейта и чистки реестра IP все заработало без проксирования.

-6
Да, есть такое впечатление, что на вопрос «что это было?» следует отвечать — просто PR-кампания телеграма с задействованиием админ. ресурса РФ.
Конечно не я первый это придумал.
0
лишит Телеграм одного из ключевых преимуществ по сравнению с другими мессенджерами — неприхотливости к каналам связи.

С прокси он уже на EDGE ложится.
0
Странно, у меня через MTPROTO-прокси работает даже после исчерпания лимита мобильного трафика, когда оператор урезает до 64 кбит/с скорость соединения. А на другом операторе ТГ работает даже на неактивированной сим-карте. ) Правда, переподключается постоянно, но сообщения ходят.
0
на палкометре телефона обычно светится E. насколько плохо на самом деле, я не заморачивался, т.к. корреляции были однозначные: E или G — и все, имеем «connecting to proxy ...», минимальная работоспособность обеспечивалась на 3G.
0

Скорее всего проблема в том, что оператор вообще не даёт Интернета, т.к телеграм при хорошем EDGE вполне себе работает.

+2

Звонил из самолёта через mtproxy через спутник(скорость что-то типа 64 кбит) — всё отлично работало, другие мессенджеры, особенно slack даже подключиться не могли

+1
Очень рекомендую вывести в строку статуса скорость передачи данных. Там, скорее всего, будут нули.
0
У 2G сравнительно малая ёмкость сотовой базы, а тайм-слоты на GPRS/EDGE выдаются по остаточному принципу. Так что в городах, в зонах, где ничего кроме 2G не ловит, эта ёмкость моментально выбирается звонящими. В местах, где абонентов немного — там есть шанс получить слот-другой.
+1

Так EDGE и не работает. В подавляющем большинстве случаев, когда на экране сияет EDGE даже пинги не проходят. В середине нулевых, помню, на EDGE фильмы с торрентов качал, за ночь 600Мб. А с появлением 3g, EDGE стал работать только там, где он и есть, в глухих деревнях.

0
Год назад я перешёл на Теле-2, а до этого был на МТС и пользовался исключительно 2G. В Москве и области EDGE работал без нареканий.
0
Это было в 2018 :)
Для текстового контента хватает, и бережет батарею.
-3
А зачем они делают обязательную привязку мобильного номера? Пользователи что? Не могут сами решить проблему спама? Пусть сделаю аккаунты по электронной почте с блокированием всех сообщений вне контактов, с бесплатным местом до 1 гига. тогда спамщиков не будет а телеграмм будет по настоящему доступным. 90% жителей планеты, не имеют мобильной связи.
UFO landed and left these words here
+2

Я представитель 34%. Не во всех странах иметь мобильный номер — бесплатная услуга. Для редких звонков в службы 19 века, которые до сих пор не освоили электронную почту, есть скайп с балансом и без абонентки. Для личной переписки — куча мессенджеров. В итоге симкарты с интернетом хватает для 99% задач. Заключать контракт с ОПСОСом и платить постоянную абонентку за сохранение номера только ради аккаунта в телеге? Нет, как-нибудь без меня.

+3
В итоге симкарты с интернетом хватает для 99% задач.

так на нее и регайте, в чем проблема?
даже припейды живут примерно полгода без пополнения.
0
У вас в телефоне симка с интернетом, но без телефонного номера? Так бывает?
-3
Бывают такие, которые не поддерживают приём SMS, вроде…
0
Первый раз слышу, честно говоря. Я очень поверхностно представляю как работают телефонные сети, но мне казалось что симка это всего лишь ключ для авторизации на базовой станции, и этот ключ сопоставляется с определенным телефонным номером (конкретным абонентом), а весь прием и передача обрабатываются радиомодулем телефона, и симка не может помешать ему принимать смс, но при этом получать данные. Получается что абонент есть, а номера у него нет?
0
Получается что абонент есть, а номера у него нет?
Номер у него, почти наверняка, есть. А вот доставка SMS на этот номер — не осуществляется.

мне казалось что симка это всего лишь ключ для авторизации на базовой станции
Так и есть, но ведь базовая станция — ещё не вся сеть. Есть роутинга SMS на данный номер и звонки не поддерживаются, то это его не нужно хранить в соответствующих таблицах и прочее. Хотя на практике это, скорее всего, всё равно всё происходит и отказ от поддержки SMS — просто способ предложить ещё один тариф.

Обычно это для IoT предлагается: теоретически IoT устройство может принять SMS… но что оно с ним будет делать?
0
Проверять на соответствие шаблону и выполнять заранее определенные команды или сценарии? Мне казалось это в целом популярный вариант.
0
Возможно случаи разные. Но была симка — только для интернета. СМСки приходили, даже входящие вызовы работали. Но вот позвонить нельзя — да
+2

Номинально номер есть. В свойствах девайса можно найти. Смс на него не приходит, звонки, естественно тоже. В контракте он тоже нигде не указ ан, так что я даже не уверен в его неизменяемости.


Припейд симки работают даже год а не пол года без пополнения баланса, но я пользуюсь припейд именно потому, что могу в любое время ее выкинуть. И не хочу вспоминать какие же сервисы были привязаны к ней? Тем более что в отличие от почты тел. номер будет 100% переиспользван другим человеком.
Для использования не припейд карты с тел номером надо заключать контракт минимум на год со штрафом при досорчном расторжении.


Я вообще не понимаю, как можно кичиться какой-то приватностью и безопасностью с такой дырой, как авторизация по телефонному номеру.


Уже сколько новостей было про угон инфы с помощью дубликата или угона номера, и при этом я не припомню не одну статью, где для угона или прослушки воспользовались бы самыми ужасными и нашумевшими poodle ssl или meltdown уязвимостями, неговоря уже про сотни других. Все только в теории

0
Уже сколько новостей было про угон инфы с помощью дубликата или угона номера

2ФА вас спасет
+1
А я у себя настроил SSLH (см. habr.com/post/412779). И в итоге у меня открыты два порта: 80 (редиректит на 443) и 443. А уже через 443 идёт и телеграм, и openvpn, и ssh. И да, на «обычные» запросы отвечает nginx, раздаёт зеркало одного из моих проектов.
+5
Коннект будет идти до вашего сервера (IP) а вот в заголовке будет передан домен Google.com
Вполне логично что если сопоставить домен с IP адресом, то он не будет совпадать, следовательно такой трафик может считаться неправильным и вполне может быть отброшен. Как вариант — подставить правильный домен, например из кучи бесплатных dyndns.
+3
вам никто не мешает:
  1. использовать реальный домен, который пренадлежит вам
  2. использовать текущий вариант подождав введение eSNI тогда на какой домен идёт запрос будет не видно


Основной смысл технологии не прятатся за гуглом а прятатся в HTTPS, анализировать домены (SNI) а потом еще для каждого сопостовлять IP:SNI — очень дорогая операция при проверки блокировок
0
А всё сопоставлять и не надо. Можно выборочно.
Зато, если уж сопоставилось, то сразу прописывать бан — явно же какое-то злонамеренное соединение :)
0

Тогда легко будет конкурентов блочить, шли ему на сервак такое вот не совпадение и все, его блочат. Это будет выстрел в ногу. Можно блочить ркн, тогда они точно введут белые списки

0
тогда они точно введут белые списки
После атак с использованием подставных IP на крупные сайты такой список уже есть, в котором находятся крупные домены/IP которые блочить нельзя.
+2
То есть существует список доменов за которыми можно прятаться? Или там для каждого жестко прописаны IP и можно быстро сопоставлять?
0
Так это уже происходит. Сейчас есть масса заблокированных доменов, которые уже прекратили своё существование и доступны для регистрации кем угодно. Можно зарегистрировать, прописать в DNS айпишники конкурента и у многих провайдеров они автоматом попадут в бан, так как блокировки у них работают по IP.

РКН выстрелы в ногу не смущают нисколько, так как ноги — не их. Поднимется совсем уж буча (как во времена ковровых бомбардировок Телеграм, когда даже Гугл поломали) — исправят. А в остальном проблемы индейцев шерифа не волнуют.

Белые списки, кстати, уже есть, как отметили выше.
0
>очень дорогая операция при проверки блокировок

Это совершенно рядовая операция на DPI в Китае, где файрвол чуть что сам пытается установить соединение на удалённый IP: порт и посмотреть что там. Без наличия реально функционирующего сайта мимикрирование под HTTPS вообще смысла не имеет — всё это будет работать несколько минут от силы а потом скорость урежется до 100байт/c. Выходом из этой ситуации может быть предварительный port knocking: правильному IP на MTproxy даём Телеграм, остальных через NAT пробрасываем на гугль или куда ёщё.
+1
Выходом из этой ситуации может быть предварительный port knocking: правильному IP на MTproxy даём Телеграм, остальных через NAT пробрасываем на гугль или куда ёщё.
По идее лучше не port knocking, а https knocking, раз уж мы маскируемся под валидный HTTPS сайт.
Я специально для такого штуку делал некоторое время назад github.com/uprt/labean
+3

Тот же 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.101

nslookup 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
Кмк провайдеры будут поступать проще:
1. Видим обращение к Google.com
2. Записываем увиденный IP
3. Проходимся по всем свежим IP, которые увидели, открываем по https. Если сайт не открылся — блокируем по IP.
+4
Так и будут делать. Поэтому надо проксировать оригинальный гугл в случае отсутствия секрета.
0
Может проще, ч-з translate.google.com получать bootstrap-лист? А там HTTPS/Websockets и страничка шаблонная. Хотя тоже научатся понимать, что эта страничка не спроста, и траффика многовато.
0
Угу, и размер пакетов подгонять.
Все интереснее наблюдать за происходящим.
+2

Это легко настраивается — установкой типа nginx/Apache и проверкой SNI, если он другой — отправляем в веб сервер. Но тут нужен eSNI.

+2
Здесь нужен не SNI или eSNI, а проверка по ключу.
Если ключ неверный, то отправляем в веб-сервер

Тогда и eSNI не надо ждать. Кроме того, теоретически и с eSNI возможны варианты. Например, РосКомПозор под влиянием очередного обострения может начать сканировать «подозрительные адреса» по принципу «порт 443 открыт — разрешаем во все возможные домены и пытаемся соединиться, всё не соединившееся — в бан, а там Господь отделит своих от чужих». И вообще, поддельный SNI — бессмысленное усложнение.

Телега как раз должна корректный SNI передавать. Если прокси называется kotiki.ru, то и SNI должен быть именно такой, чтобы браузер открыл с ним тех же котиков.
UFO landed and left these words here
+1

Это позволит заблокировать только публичные адреса, не более, личные прокси будут невидимы.

UFO landed and left these words here
0
Можно для Васи сделать платную услугу на зарубежном сайте по покупке личного замаскированного под TLS прокси на уникальном IP. И можно не только для телеги, а вообще. Достаточно ему самому или попросив Петю один раз купить себе такой прокси и единолично потом пользоваться сколько угодно, всем кроме Васи он будет просто сайтом. Товарищ майор можно покупать тоже и блокировать полученные IP — но пространство IP большое. Сам сайт по продаже можно конечно блокировать, но достаточно один раз хоть как-то получить туда доступ (например из отеля в Турции) и дальше у тебя свободный инет через прокси. Придется вводить белые списки…
UFO landed and left these words here
0
Ну так такой прокси можно не только для месенеджеров использовать.
Продолжат такими темпами блокировать все подряд — Васи могут и платным заинтересоваться.
Но это скорее интеллектуальное упражнение продемонстрировать что без белых списков блокировки даже Васю не остановят.
UFO landed and left these words here
0
Да, сейчас задача — потянуть время и повысить ставку. Показать, что «контролировать Интернет» дорого, сложно и проще заработать политический капитал и попилить деньги на чём-нибудь другом.

Ну и самим себе обеспечить сносное существование на период смутного времени.

Это не значит, что нужно заниматься только этим, но и этим нужно заниматься тоже. Чем легче им даётся весь этот беспредел, тем быстрее он продвигается и растёт самоуверенность его инициаторов.
+1
как только соединение рабочее, /16 сетку в блок

Было бы забавно, если бы при этом клиент телегама запрашивал, например, favicon.ico с сайта https://rkn.gov.ru/

UFO landed and left these words here
0
Ну и с учётом наличия open source клиента, узнать правильный адрес сервера не представляет никакого труда.
Он адреса в т.ч. через системные пуши получает, насколько я понимаю.
UFO landed and left these words here
0

Вы похоже не знаете как работают пуши — их рассылается Google или Apple а не каждое приложение само. Заблокировать пуши только от одного приложения — нельзя.

0

Так речь не про пуши. Клиент получил новый адрес, соединение установилось — в бан всю подсеть.

0

Так это уже проходили — банили Амазон, Гугл, других хостеров, сменить локацию сервера и отправить новый IP — дело 2 минут.

0
На API Амазона даже и двух минут не надо, всё это делается через пару https запросов из скрипта.
0

По поводу whitelist я согласен, это уже последний бастион.


А вот анализ исходников — это уже совсем не такая тривиальная задача, как поставить телеграм и блокировать все куда он ломиться.


Начнем с того, что только официальные клиенты могут быть разные для разных платформ. А по мимо этого, может быть и куча не официальных клиентов.


Тратить столько ресурсов, что бы заблокировать один единственный мессенджер? Я думаю вайтлист тут куда более вероятен.

0
ну сделают вам что «сайт» будет открыватся… че сложного-то?
0

эээ… а что, виртуал хост уже отменили?…
сайт по ип и сайцт по имени на том же ип могут быть совсем разными, и сайт по ип — вполне себе может вообще не работать. (хотя обычно по ИП отдаю — форбидден)

0
DPI же используется у оператора, к которому подключены абоненты, поэтому практически всегда используется один и тот же DNS.
+2
В смысле? DNS же можно прописать вручную. А еще можно использовать DNS-over-HTTPS (он недавно в Firefox появился, в Google Chrome тоже грозятся скоро реализовать). И тогда неважно, есть ли DNS-сервер у оператора — все DNS-запросы будут идти мимо него.
+1
DNS же можно прописать вручную.
Не спорю. Но много ли вы видели обычных пользователей, прописывающих альтернативные DNS при подключении?
+2

В телеграмме уже как год используется свои DNS через DNS OVER HTTS (google/Cloudflare) он не использует провайдерский

0

Проблема с телегой в т.ч. скачать её — ибо без VPN у меня даже в выдаче гугла telegram.org не появляется.


Поэтому чтобы скачать телегу УЖЕ должен быть работающий впн. Я уже замучился на каждый новый комп первым делом ставить openvpn, и ломиться генерировать очередной ключик.

0
Есть зеркало (официальное или нет не могу сказать) — telega.one

P.S. Проверил, не все поддомены видит
0

У меня всегда паранойя, что это зеркало может быть не очень честным, а может даже и злонамеренно открытым, и там может быть на скачивание не совсем правильный телеграм клиент.

0
Десктопную — с гитхаба, как выше советуют.
Мобильные — с соответствующих сторов.
0
Вообще-то тут mozilla проводит Study trusted resolver-a в firefox. Так что, пользуюясь firefox, запросы сейчас у многих идут в обход провайдера.
0
DNS-over-HTTPS в Firefox включаешь и можно забыть про вайфай хотспоты в метро итд. Для рядового пользователя не очень приемлемо.
+2
Сейчас оба прокси сервера используют домен 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, если видит проблемы).
+3
И тогда это использовал именно сам телеграм, сейчас метод будет доступен обычным пользователям. Ранее правда было вот так:
  1. Telegram жил в облаке гугл
  2. Telegram запрашивал сайт А в облаке, а подключался к Б в том же облаке


Гугл был против такой схемы, сейчас же вы можете отправлять в заголовке Google а иметь сервер в Hetzner или Digital ocean, гугл может быть против, но сделать ничего не сможет. А сверка SNI:IP — очень дорогое занятие при проверки ресурса на блокировку.
0
делать ничего не сможет
Теоретически может пригрозить удалением такого приложения из маркета.
+1
А сверка SNI:IP — очень дорогое занятие при проверки ресурса на блокировку.
Ничто не мешает делать это отложенно, видим коннект с новой парой (искать можно быстро по хэшам) — отправляем его в очередь на проверку и ждём результат, если по результату выявлено несовпадение, добавляем в блок на будущее. Правда, следующим шагом клиенты научатся автоматически генерировать уникальные рандомные доменные имена по шаблону :)
+3
Или вместо Гугл указывать свой домен i_love.cats который вполне реальный и на котором есть веб-страничка с котиками.
+1

Подумалось, насколько безумна идея указывать домен какого-нибудь сбера в этом случае.

+1
Блокировать будут не домен, а ip вашего сервера, поэтому в целом бессмыслено. Но тут есть вариант с белыми списками (вроде такой составлялся Роскомнадзором), возможно, указав домен из белого списка, дальнешийх проверок не последует.
+2
блокировать только IP бессмыслено, сменить айпи на новый… делается автоматом как только старый заблочен. Каждый раз проверять автоматом и обновлять список айпишников на кторые домен резолвится добавляя их в бан черевато граблями которые уже проходили, кто-то из владельцев домена елементарно зарезолвится на айпишники правительственных сайтов и РКН с гигиканьем заблочит госуслуги на полстраны ))
0
ну я отвечал по ветке проверки SNI:IP для телеграмма, в данном случае вряд ли даже в Роскомнадзоре догадаются банить заведомо фейковые домены типа «google.com».
0
Нет смысла. Указывать домен гугла имеет хоть какой-то смысл, т.к. google.com может резолвится во что угодно, в том числе в IP-адреса, которые гуглу не принадлежат (в случае направления на GGC)
У Сбера и подобных, IP-адреса весьма жёстко прибиты и будет довольно легко путём простейшего «детектора аномалий» и подобных методов вычислять владельцев таких прокси.
Единственный рабочий вариант это указание собственного домена, чтобы было максимально сложно находить такие прокси

То что сделали телеграмм сейчас (отправка google.com из клиента) это просто подарок для тех, кто занимается вычислением этих прокси. Без задания своего домена я бы не стал связываться.
0

Домен google.com берется из секрета. Его можно на что угодно заменить.

0
$ 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: разметка поехала, не знаю как поправить

+2

Вы предлагаете направить на DPI весь HTTPS трафик и во всем трафике проверять SNI, что очень дорого и медленно и есть шанс зацепить что то лишнее, если идёт общение без SNI как такового с намертво прибитым сертификатом у клиента (так делают банковские приложения и не только)

0
Зачем направлять? Просто зеркалировать первые пакеты соединений.
0
Смысл? Для выявления новых IP поиском по хэштаблицам, а потом проверки SNI, сертов и т.п.
+3

Окей, у вас не сошёлся SNI, если такое заблокировать — пострадают банки и любое приложение которое использует фиксированный сертификат прибитый гвоздями. (Ну и весь Энтерпрайз).


Я все ещё не понимаю что даст анализ, особенно если мы предполагаем все же переход на eSNI.

0
Достаточно просто постучаться туда и попробовать установить соединение.

Проблема в том, что этот Fake TLS похож на настоящий примерно так же, как «билеты банка приколов» на настоящие деньги. То есть, если посмотреть, то видно сразу. У энтерпрайза же обычно TLS вполне себе нормальный.

Понятно, что не обязательно делать это для каждого соединения и «вот прям щас».
+5

Ещё есть трафик вообще без TLS SNI. У кровавого энтэрпрайза и им сочувствующих такое случается повсеместно.

0
Есть вообще трафик по самописным протоколам, на левые порты, по непонятным IP-адресам. Поди разберись что там стоит на сервере: самописная CRM-система, или неведомый тип Telegram-прокси для кастомного клиента.
0
Этот SNI только и нужен когда много доменов на одном IP. На корпоративном/личном прокси вообще лишняя сущность.
-4

Ожидал такой реализации с самого начала.
После пустышки Mproxy, представленный как средство улучшения безопасности, доверия к протоколам телеграма нет (да и к самому телеграмму). Поэтому только VPN.

+1
MTProto решает один очень важный момент — при сценарии «гос-сертификата» соединение не установится из-за того, что MTProto не используем привычные сертификаты как следствие установка корпоративного или иного корневого сертификата не позволяет расшифровать трафик.
0
При этом такие «гос-сертификаты» еще нигде кроме Казахстана не внедрили (да и то безуспешно), поэтому такой сценарий почти не реалистичен. А вот DPI уже давно у всех есть и все его применяют.
+24
… такой сценарий почти не реалистичен ...
Сколько раз за последние несколько лет мы произносили подобные фразы и каждый раз ошибались в определении границ, до которых может дойти.
+2
Я имел ввиду, что можно конечно делать крутой супер-протокол, который будет работать, если упадет метеорит, и затратить на это 2 года, и ждать неизвестно сколько падения метеорита. А можно прямо сейчас внедрить fake TLS, и уже обойти все существующие блокировки, при уже осуществлённом сценарии.
+3

В Казахстане уже развнедрили. Но никто не мешает сделать заход №2. Ну а в корпоративных сетях свой trust anchor де-факто стандарт, хотя в них, конечно, трафик к мессенжерам отдельно регулируется. Отдельно «белый» MITM любят устраивать всякие антивирусы, впихивая свой суррогатный рут в доверенные. Тоже, кто его знает, что они по факту собирают и в чьих интересах.

+1
Во-во. Поэтому я всегда отказываюсь от настойчивых попыток бесплатных антивирусов защитить меня в Интернете.
0
Это как всегда борьба снаряда и брони. Т.к. по сути, только телега препирается с РКН (оставим споры о том, по-настоящему или нет), то внедрение MTProto тормознуло тот маразм, который попытались внедрить в РК. Возможно теперь в РФ и не внедрят из-за безсмысленности затеи.

Главное чтобы в ответ на вот это вот обновление РКН не выступил с инициативой запретить вообще весь TLS. Для защиты детей разумеется. Впрочем не удивлюсь.
0
Главное чтобы в ответ на вот это вот обновление РКН не выступил с инициативой запретить вообще весь TLS.
А зачем ему выступать? Я думаю этот вопрос уже давно прорабатывается на предмет технической реализуемости.

Так как это совершенно логичное решение для страны, которая хочет контролировать сеть в своих границах.
0
А зачем ему выступать?
Ну кто-то же должен стать иницаитором процесса. Если не РКН, то придется «яжматерям» опять платить.
из-за HSTS возврат в HTTP невозможен.
Завтра на законодательном уровне запретят сертификаты от заграничных CA и станет «невозможное возможно...» Кто-нибудь еще помнит linkedin?
+3

Хром (и другие боаузеры) не будут ничего делать, можно хоть 10 законов принять.

0
Хром спокойно открывает сайты без шифрования. Просто обяжут эти самые сайты использовать только простой http. FB, VK, YA, G и прочие гиганты просто прогнутся (т.к. деньги не пахнут — практика уже показала), а всякие там мелкие субкультурные ресурсы можно и заблокировать безболезненно, как это было с linkedin.

Не поймите меня неправильно — я резко против, но вижу к чему идет и пока не вижу дна, от которого можно было бы оттолкнуться.
+1

Из вашего списка прогнутся могут только: vk и ya. Остальные этого делать не будут по тем же самым коммерческим причинам, сохранение денег от «прогиба» — намного меньше чем потери от падения акций (и доверия) после такого решения.

0
не будут по тем же самым коммерческим причинам
Ну с тайной переписки то и удалением ссылок уже прогнулись. Вопрос в размере потерь и доходов.
В конце концов все в курсе истории с гуглом в Китае.
Я не вижу снижения активности среди моих контаков в линкеде.
А я не вижу блокировок вообще (не скажу как). И ПР-ом меня и моих знакомых на выходных не дубасят. Значит ли это, что у нас соблюдается конституция?
Речь не о том, что часть целевой аудитории имеет доступ к линкедину, а о том, что он не общедоступен. И это печально.
+2
В линкедин сидят HR-ы почти всех IT-компаний и их активность не стала ниже после блокировок. Да и вообще, большинство ИТ-специалистов вынуждены иметь средства обхода блокировок (т.к. из гугла часто попадаешь на заблокированные страницы по технической тематике), а следовательно, ИТ-шники там продолжили сидеть.
Я не вижу снижения активности среди моих контаков в линкеде.

P.S. Работник моего круга, залогинься
+2
Кто-нибудь еще помнит linkedin?
Помню, пользуюсь. По ощущением, просадки среди целевой аудитории практически нет.
+1
Пишут оттуда регулярно, и даже из Касперского (да-да, те самые которые vpn дают с фильтром от роскомпозора)
0
Когда уже можно будет использовать Telegram/MTProto в качестве транспорта, например как в tuntox.
0
Нунапример у некоторых оперторов Телега бесплатная и безлимитная
0
У тех операторов, у кого она бесплатная идёт определение не по DPI а через белый список сетей телеграм. DPI очень не надёжен и позволяет делать Фрод, который вы собственно и описали. При белом IP списке — такого не будет.
0
Как только появится популярная реализация транспорта, Телега бесплатной и безлимитной у них быть перестанет :)
0
Может кому-то пригодится: здесь в статье на Хабре можно почитать статью про официальный халявный MTProxy, и в комментах кучу живых вариантов реализации MTProxy от python… разных docker образов и пд., которые уже успешно и давно используются в Telegram.
0

А в TLS-ответе сертификат сервера шифруется или нет? Неужели его не видно, как SNI?..

0

Telegram притворяется TLSv1.3, а в нем сертификат сервера всегда зашифрован.

+2

Но если мы пойдём медленным путём, повторив соединение от себя (пока eSNI ещё не в деле) — мы без проблем получим реальный сертификат сервера и увидим, что "царь-то ненастоящий"?

0

Ну да, в текущих реализациях прокси серверов реакция на не-телеграмный tls не такая же как у реального https. Но это поправимо.

0
Без проработки этого момента начинать продвигать fake TLS вообще смысла не имело. Китайские DPI уже много лет сами соединяются с сервером в любых непонятных ситуациях.
+1
в будущем авторы прокси обещают сделать ввод других доменов и возможность не пускать клиентов, если они используют другой домен при согласовании подключения.

Для "ввода других доменов" от прокси ничего не требуется. Что вы положите в base64 секрет после 17го байта то и будет передано как домен.


Блокирование доступа по домену в Erlang прокси уже реализовано https://github.com/seriyps/mtproto_proxy/blob/b6565d23dc2bdafe68587c9b73dd130bb17f019e/src/mtproto_proxy.app.src#L63

+1
Я что-то не понял, а свой домен подложить, да ещё и с настоящим сертом от того же Let's Encrypt, пока нельзя?
+1

Мне кажется, что следующим этапом будет честный SSL (в том числе с mitm), внутри которого уже будет стеганография. Веб-сокеты, вложенный коннект, обмен фотографиями, etc. Одним из интересных приёмов будет DoS атака на DPI, когда понять "телеграм или нет" можно будет только затратив ощутимые ресурсы. Например, bcrypt с большим числом раундов, внутри которого "telegram".

+1
Как я понял автора комментария: Использовать HTTPS протокол, видимый для DPI, который будет инкапсулировать уже протокол MTProxy. В таком случае нужен будет свой TLS сертификат для HTTPS трафика (Например, lets encrypt), на который государство может осуществлять бессмысленную MITM атаку с подменой сертификата, как в Казахстане. Бессмысленную — потому что внутри первого слоя будет уже MTProxy.
+2

TLS с настоящим (но, например, самоподписанным) сертификатом, который может перехватить mitm с предъявлением своего сертификата.

0
когда понять «телеграм или нет» можно будет только затратив ощутимые ресурсы

Такая ли большая проблема в вычислительных ресурсах? Ведь DPI может проверять не все пакеты, а сначала статистически выявлять пары абонент <-> ип, или даже абонент <-> кластер ип, собранный по всей базе абонентов. А потом уже по статистически подозрительным парам семплировать, скажем, анализируя каждый сотый пакет.
+1

Окей, есть облако Google или Amazon или Azure — это 80% Интернета фактически, и что и как выделять кластер?

+3

Во-первых бесполезно сэмплировать пакеты, надо начало сессии. Если у нас есть криптографически тяжёлая процедура ответа на вопрос "tg это или нет", то клиент за коннект платит n ресурсов, и dpi платит за это n ресурсов.


Однако, тут есть плот твист: если dpi начинает платить n ресурсов за проверку "tg или нет", то он начинает его платить и на false positive, т.е. на сессиях, которые не являются tg. Получается существенная амплификация, и если протокол достаточно подлый (т.е. специально сделанный), то понять "что это такое" получится только завершив рассчёт, т.е. честно потратив n ресурсов на каждую сессию.

0
Снова таки, если действуем следующим образом:
1. Собрали статистику сессий. Абонент <-> ip
2. Выделили кластер Группа абонентов <-> группа ip, которые по поведению могут быть телеграмом (частота обращений, одновременные рассылки с сервера на много абонентов в моменты публикаций в группах с большим охватом).
3. Каждую n-ую сессию (с элементом рандома) между абонентом из этой группы и ip из этой группы проверяем, затрачивая ресурсы.
4. Если поймали, что таки тг, то заблокировали (в зависимости от отморожености блокирующих, ip, или пару ip<->абонент, или весь кластер, или еще каую-либо комбинацию). Чем сильнее блокировка, тем больше шанс, что кого-то специально подставят, имитируя тг трафик.
0

Для того, чтобы собрать эту статистику вам потребуется много сессий. А сессия у TG может устанавливаться один раз надолго (в контексте IM).


После того, как вы обнаружите, что IP такой-то кажется, TG и таки заблокируем его, мы переходим к предыдущей, успешно решённой задаче — заблокировать все IP у телеграма.

0
TG и таки заблокируем его, мы переходим к предыдущей, успешно решённой задаче — заблокировать все IP у телеграма

С сильным упрощением — уже есть статистика по тем, кто на забаненный ip ходил. Теперь ищем ip, на которые абоненты из этого кластера вдруг начали ходить. Проверяем только сессии туда
0

Умрёте на первом же youtube'е/твитче с кастомным протоколом стриминга.

0

Ждем рейды по домам от бдительных граждан с повязками "Дружинник", которые будут смотреть, установлена ли телега на компе и телефоне.

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

Это следующий уровень закручивания гаек. В принципе, верхняя достигнутая граница довольно высока — Красные Кхмеры убивали за очки на носу (ибо умный).

0
А гражданам-то это зачем?
Это же не силовики с неплохой зарплатой и социальными гарантиями.
0

Ну а зачем люди в отряды путина вступают и портреты Обам\Трампов жгут?


Санкционированное насилие очень привлекательно для многих.

+1
Обама/Трамп где-то далеко за океаном, это больше мифический образ. А здесь придется вступать в открытую борьбу со своими же соседями.
+3
Если у них будет поддержка от государства, займутся. Были же полицаи из местных во время второй мировой.
0
Полицаи опирались на чужую армию оккупанта, которой не трудно спалить деревню бунтовщиков. Родная армия не пойдёт против своего народа. У современных полицаев опора только на режим, который стоит на плечах МВД, ФСБ, росгвардии.
+2
Армия может и нет (есть сомнения), но МВД и ФСБ — как раз и есть армия против своего народа (пруфы — ну например недавние события в Москве). Если спустить с лестницы дружинника будет примерно равняться спуску с лестницы полицейского, то дружинники будут вести себя как полицаи во время войны.
+1
Угу. И если использовать полный TLS с запросом пользовательского сертификата, то понять, что на домене private.supersite.com живет реальный сайт доступный только избранным с сертификатами или прокси телеграма нереально
+1
V2ray примерно так и работает в режиме вебсокетов. Его же средствами их можно обернуть в HTTPS-соединение c полноценным сертификатом.
0
В Китае это никогда и не было проблемой. Есть множество VPN сервисов, которые прекрасно работают. Проблема в другом — в узких каналах между Китаем и остальным миром. Из-за этого youtube нормально не посмотреть, только в 360p качестве.
0
Хз, в Шенчжене через впн прекрасно смотрел (2015-2017 годы) в 1080@60, через впн в ГК/Японии/Корее.
Хотя многие иностранные сайты, которые не были заблокированы, действительно плоховато грузились.
С другой стороны, с MEGA большие файлы прекрасно качались во весь канал в 300Мбит.
0
shifttstas,
А нельзя ли сделать в опросе чек-боксы? Я бы выбрал все варианты.
Или переформулировать вопрос на «какой метод обеспечения защиты следует добавить в первую очередь?»
0

Я тоже хотел сделать чекбоксы и ранее так можно было, однако сейчас я такого функционала не нашёл :(

0
Это настраивается до публикации опроса — после публикации сменить тип ответов уже нельзя (
+5

Я конечно сейчас (в рамках реалий судебной системы в РФ) наверное глупость скажу, но мне кажется телеграму стоит побороться и на правовом поле. Дело в том, что судебные решения, по которым блокируют прокси сфабрикованы: в них указано что с помощью прокси пррверяющее лицо смогло зайти в запрешённые группы, однако без пароля подключиться к прокси и проверить это невозможно. А такие решения есть даже в отношении тек прокси, пароля от которых заведомо ни у кого кроме владельца не было, и которые найдены тупо по длине пакета.

+4
Уже борются, Агора представляет Телеграм, но, как я понимаю, результатов пока никаких. Политическое решение.
0
Борьба с телегой какая-то странная. Вроде бы как есть, но эффективность здесь относительно других стран ниже? Т.е. телега здесь и сейчас получается таргетирована на аудиторию, которой можно впаривать контролируемые каналы. А относительно тех стран, где блокировками озабочены куда серьезнее, где более массовая аудитория. Например Иран.

Расширение аудитории здесь не выгодно, но и не выгодна полная блокировка? Иначе ковровые блокировки целыми подсетями сохранялись бы.

0

Коовровые блокировки приносят убыток бизнесу и они не выгодны %username%

0
Победа в борьбе с блокировками Телеграму больших ресурсов стоит. А где с Телеграмом борятся эффективней? В Китае он работает нормально без проксей (правда картинки не грузятся). В Иране куча прокси, и они наводнены рекламой, стало быть не оскудеет рука их дающая :)

0
> Бета версии Telegram Desktop
1.8.1 про этот режим ничего не знает.

image

Свежее на github не вижу.
0
Десктоп-клиент сильно отстаёт по фичам от мобильных, как правило. Это нормальное положение дел, через несколько дней-недель приедет.
0

Не соглашусь. Есть mobile-only фичи, типа InstantView, тогда да. В остальном TDesktop последнее время одним из первых релизит очередное обновление.

-1
> Сейчас оба прокси сервера используют домен Google.com

Интересно что Signal запретили заниматься подобным когда они собрались обойти блокировку в Эмиратах. Тут у нас опять система двойных стандартов от американских интернет-гигантов или я что-то путаю?
+2
«Что-то путаете». Они хотели прокси на настоящих гугловых IP размещать.

А тут IP, которые Гуглу не принадлежат, так что Гугл ничего сделать не может. Придётся давить ISP и заставлять их подобных клиентов изгонять. Это сложнее.
0
Нет. Есть способы дающие ответ «с хорошей вероятностью». Скажем известно, что Google свой контент раздаёт только из «своих» автономных систем.

Но про какой-нибудь сайт «рога и копыта» — этого узнать нельзя. Пока нельзя.
0
>Скажем известно, что Google свой контент раздаёт только из «своих» автономных систем.

Это не так. У гугла тысячи GGC-шек, которые висят на IP-адресах операторов, которые их себе ставят
+6
Пожалуй, предложу тут две своих утилиты в тему.

Первая — TLS-обёртка для соединений. По сути аналог stunnel, но только скрадывает время на установление соединений: https://github.com/Snawoot/ptw. Ей удобно обернуть коннект до того же SOCKS-прокси, а так же можно использовать как прозрачный прокси на роутере. Поддерживается использование самоподписанных сертификатов и сертификатов с subject-ом, не соответствующим адресу хоста.

Вторая — быстрая реализация SOCKS-прокси, аналогичного встроенному в ssh (как ssh -ND): https://github.com/Snawoot/rsp. По сути сразу предоставляет готовый SOCKS-прокси на стороне клиента, заворачивающий соединения внутрь SSH-туннеля. На стороне сервера требуется только работающий SSH. То есть типичный виртуальный сервер сразу готов к работе в качестве прокси после развёртывания из панели хостера. Преимуществом по сравнению со стандартной реализацией SOCKS в OpenSSH является отказ от мультиплексирования соединения внутри одного тоннеля, поэтому в типичных условиях скорость существенно выше (см. сравнение скорости).

В телеграм можно задать свой SOCKS-прокси и добиться устойчивой и скрытой работы этого приложения.
0
В голосовалке очень правильная тема затронута. Давно пора закопать все эти дурацкие SMS, доступ к которым могут получить не только спецслужбы, но и любой мошенник с улицы…
0
ЧСХ, преподносится это как защита безопасности. А сама телега, как приватный IM.
+1
один из соавторов форка
Звучит как «знакомый владельца Жигулей». Насколько я помню, форк опенсорс-проекта может сделать каждый желающий, а уж соавтором каждого желающего может быть вообще кто угодно.
0

Я имел в виду не набор регалий длиной с мою ногу, а специализацию автора, т. е. то, что, судя по блогу, он хорошо знаком с TLS, DPI, проксированием трафика и прочими подобными вещами.


Безотносительно к теме Telegram, блог интересный, рекомендую.

0

Не выгораживаю данного товарища, но он участвовал в разработке Squid (в плане кода и поддержки на внутреннем форуме).

+1
> Клиент предъявляет серт, вы говорите? Прекрасно, клиент, ну-ка, покажи-ка легитимный серт, подписанный рутами! Что, нету? TCP RST!

Вот это сомнительно. Покажите хоть один клиентский серт, имеющий подпись от известного CA. Обычно клиенты как раз валидируются по сертификатам от собственного CA.
+2
Ну так, насколько я понимаю, здесь-то никакого нет, даже самоподписанного.

На самом деле автор блога прав — весь этот Fake TLS обнаруживается. Особенно в варианте «стучимся на левый айпи, а передаём SNI от google.com». Анализатор возьмёт этот липовый SNI, постучится туда сам, получит нестыковку и скажет «ну ок, следующий час все такие соединения туда дропаем» или отправит IP в РКН как кандидата на бан.

Гораздо правильнее было бы иметь полноценный мультиплексор, который устанавливает полноценную TLS-сессию на «сайт-с-котами.тк» и затем уже внутри неё перенаправляет трафик либо на МТПрото, либо на вебсервер, руководствуясь каким-то секретным ключом.

Что клиенты Телеги постоянно палятся — тоже плохо, так как можно вычислять прокси просто поведенчески, а потом уже никакое шифрование и стеганография не помогут.

В общем, Паша мог бы и чуть побольше напрячься.
0
С остальным-то я в целом согласен.

Гораздо правильнее было бы иметь полноценный мультиплексор, который устанавливает полноценную TLS-сессию на «сайт-с-котами.тк» и затем уже внутри неё перенаправляет трафик либо на МТПрото, либо на вебсервер, руководствуясь каким-то секретным ключом.

Именно так я и сделал в своём решении. Серверная часть представляет собой haproxy, который разруливает полезную нагрузку для авторизованных клиентов и подключает неавторизованных клиентов на фэйковый HTTP-сервер.
+1
Вставлю свои пять копеек. Собрал на днях из исходников официальный MTProxy, там поддержка FakeTLS, как я понял, присутствует. В параметрах запуска указывается все тот же 32-символьный secret, + добавляется ключ -D. Если запустить mtproxy -h, то в выводе можно увидеть следующее: --domain/-D . adds allowed domain for TLS-transport mode, disables other transports; can be specified more than once. Если запустить mtproxy, например, так
/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>
, всё работает.
Может, это конечно, очевидно, но я не сразу понял
0
Спасибо за наводку! В новостях про это почему-то почти не говорят, собирался уже менять прокси, а достаточно было обновиться.

Неочевидным для меня оказалось то, что к домену в --domain/-D прокси должна иметь доступ, иначе у меня не заработало.
0

Проверку домена кстати совсем недавно добавили в официальный MTProto. На момент написания комментария такой проверки не было

0
Идея в том, что домен под который маскируешься, должен существовать, иначе твои запросы выглядят странно. Хотя по моему, это не совсем оправдано: выгоднее реализовать такое поведение, когда MTProto показывал бы какой-нибудь простенький лендинг, или даже заглушку nginx, если идет запрос на 443 порт (в нашем случае на нем сидит MTProto) без предоставления валидного secret. С одной стороны, повышается сложность настройки, ведь нужно тогда «раскатывать» у себя лендинг для отвлечения внимания, с другой стороны — при такой конфигурации правдоподобное отрицание того факта, что у нас не MTProto Proxy, а обычный сайт-визитка становится очень убедительным.
Only those users with full accounts are able to leave comments., please.