Telegram тестирует новый вариант обхода блокировок — маскировка трафика под обычный TLS (https).
Предистория: Попытки заблокировать Telegram происходят в разных странах, первый вариант блокировки был простым — блокировка IP адресов серверов Telegram.Сейчас мы переходим на следующий этап (похоже финальный или пред-финальный) — стеганография.
Telegram достаточно успешно отбивается от этой атаки, переодически меняя IP с которых он доступен, однако это вызывает долгий первичный Connecting…
Чуть позднее стали доступны Socks прокси, однако протокол не подразумевает шифрования и это позволяло достаточно просто смотреть «внутрь» socks туннеля определяя, что внутри него — Telegram, блокируя прокси.
Следующим раундом стал — выпуск MTProto Proxy — прокси сервера от Telegram, который использует свой протокол MTProto, однако и он обладал некоторыми проблемами — размер пакетов достаточно характерный и специфичный, и многие DPI начали определять Telegram уже после первого пакета — блокируя доступ.
Ответом на такое поведение стало введение новой версии протокола MTProto — с случайной длиной, теперь определить что перед нами Telegram туннель — сложнее, часть DPI начали классифицировать трафик как «другое» часть все же научились выявлять характерный паттерн и с некоторой вероятностью (не 100%) определять, что трафик относится к Telegram
Стеганогра?фия (от греч. ???????? «скрытый» + ????? «пишу»; букв. «тайнопись») — способ передачи или хранения информации с учётом сохранения в тайне самого факта такой передачи (хранения).Другими словами — теперь Telegram будет притворяться обычным TLS (https) трафиком.
Зачем притворяться?
Ответ лежит на поверхности — в нынешнее время, большая часть трафика — TLS (https), при использовании данного протокола вот что увидит ваш провайдер или DPI:
- Ваш IP
- IP Сервера
- Домен подключения (URL не увидит)
Причем над последним пунктом ведется активная работа, чтобы его убрать и помимо двух IP был просто шифрованный туннель с неизвестным содержимым.
В такой ситуации все нестандартные протоколы начинают привлекать к себе дополнительное внимание и решение этой проблемы — одно — если ты выглядишь как TLS (https) то вопросов становится меньше.
Техническая реализация
При использовании нового протокола, поток MTProto оборачивается в стандартный HTTPS (первые сообщения о согласовании туннеля) в котором идет передача домена (ненастоящего). После согласования протокола MTProto — Fake-TLS не используется, далее трафик начинает ходить привычным нам MTProto протоколом со случайной длинной (dd — ключи).
Справочно: Telegram использует 3 вида ключей для MTProto Proxy:
- Обычные ключи (Легко определяется DPI)
- Первые две буквы — dd — случайная длина сообщений (DPI может определить протокол только по первым пакетам согласования подключения — далее выглядит как обычный https/TLS)
- Первые две буквы — ee — Fake TLS + случайная длина сообщений (DPI не может определить протокол, первое сообщение и все последующие выглядят как HTTPS/TLS)
Где попробовать?
Уже есть два Proxy-сервера, которые поддерживают новый стандарт (официального прокси сервера всё еще нет, хотя он и в прошлый раз достаточно долго добавлял поддержку dd ключей)
Поддерживающие режим Fake TLS Proxy:
Обратите внимание: на момент написания статья — функционал fake tls — экспериментальный, следовательно надо использовать Beta- или Alpha-версии ПО (как прокси, так и клиентов)
Какие клиенты поддерживают новый режим?
Бета версии Telegram Desktop, Telegram iOS и говорят, стабильная версия на Android.
Как попробовать?
- Для примера будет использован прокси на Python:
- Устанавливаем Proxy:
git clone https://github.com/alexbers/mtprotoproxy.git; cd mtprotoproxy - Запускаем:
python3 mtprotoproxy.py - В консоль будет выведен ключ с припиской (experimental) — он нам и нужен:
tg: tg://proxy?server=8.8.8.8&port=443&secret=7gAAAAAAAAAAAAAAAAAAAABnb29nbGUuY29t (experimental) - Вводим данные в клиент как обычно — поздравляю, теперь вы используете новый режим Fake TLS.
Что происходит за кулисами?
Сейчас оба прокси сервера используют домен Google.com при подключении, другими словами ваш провайдер или DPI будет видеть HTTPS коннект к Google.com но IP будет — вашего сервера, в будущем авторы прокси обещают сделать ввод других доменов и возможность не пускать клиентов, если они используют другой домен при согласовании подключения.
Обратите внимание! Коннект будет идти до вашего сервера (IP) а вот в заголовке будет передан домен Google.com
Почему Fake TLS — это хорошо ?
Как уже ранее было сказано — при использовании HTTPS протокола ваш провайдер или DPI может руководствоваться только двумя критериями при блокировке соединения:
- IP Сервера
- Домен
Причем последний пункт скоро пропадет (спасибо eSNI).
Переход прокси на Fake TLS делает его невидимым для вашего провайдера, а если сервер стоит в облаке от, скажем, Google и при согласовании используется какой-то домен Google — тогда и эвистический анализ не поможет, со стороны все будет выглядеть так, как буд-то какой-то сервис Google работает по HTTPS/TLS протоколу.
Минусы есть?
Небольшие, но есть — если мы будем обращатся к прокси используя браузер — соединение ожидаемо не установится (секрета то нет). Со стороны это будет выглядеть, как некорректно настроенный HTTPS сервер. Может ли это быть критерием для блокировки? — нет, сервер може ожидать например личного сертификата или другой информации.
Помимо этого — в будущем можно будет помимо секрета использовать связку секрет+домен (ненастоящий) в качестве поля аутентификации и если к серверу будет обращение с другим доменом — показывать вполне обычный сайт, а вот если с доменом который известен только вам — поднимать туннель MTProto.
Однако это станет возможным только после внедрения eSNI (шифрованного заголовка домена) — сейчас он передается без шифрования.
Есть куда расти ?
Конечно есть, на мой взгляд Telegram еще не использовал все средства для скрытия, помимо https/TLS имеет смысл использовать WebSocket для скрытия трафика — это еще сильнее усложнит идентификацию и классификацию трафика.
Заключение
Если у вас есть свой MTProto прокси сервер — изучите новый его стандарт, как только во всех публичных версиях Telegram клиентов он станет доступным — переведите всех пользователей на него.
Да, есть небольшая проблема — придётся обновить строку подключения у всех (секрет) он меняется, однако это позволит повысить успешность скрытия прокси.
Помимо перевода на новый стандарт — стоит перевести прокси на 443 порт (стандартный для HTTPS) и заблокировать не шифрованные подключения (ключи без dd и ee), а после миграции всех на ee вариант и dd ключи в том числе, благо прокси это умеют.
Так же не лишним будет установить перед прокси балансировщик с определением домена и при запросе домена отличного от настроенного в прокси — показывать вполне настоящий сайт, как только будет внедрён стандарт eSNI — это бесплатно для вас усилит защиту.
Вам также может быть интересно
Комментарии (198)
GennPen
12.08.2019 08:42Коннект будет идти до вашего сервера (IP) а вот в заголовке будет передан домен Google.com
Вполне логично что если сопоставить домен с IP адресом, то он не будет совпадать, следовательно такой трафик может считаться неправильным и вполне может быть отброшен. Как вариант — подставить правильный домен, например из кучи бесплатных dyndns.
shifttstas Автор
12.08.2019 08:54вам никто не мешает:
- использовать реальный домен, который пренадлежит вам
- использовать текущий вариант подождав введение eSNI тогда на какой домен идёт запрос будет не видно
Основной смысл технологии не прятатся за гуглом а прятатся в HTTPS, анализировать домены (SNI) а потом еще для каждого сопостовлять IP:SNI — очень дорогая операция при проверки блокировок
AlxDr
12.08.2019 12:13А всё сопоставлять и не надо. Можно выборочно.
Зато, если уж сопоставилось, то сразу прописывать бан — явно же какое-то злонамеренное соединение :)
easty
12.08.2019 18:44Тогда легко будет конкурентов блочить, шли ему на сервак такое вот не совпадение и все, его блочат. Это будет выстрел в ногу. Можно блочить ркн, тогда они точно введут белые списки
GennPen
13.08.2019 00:07тогда они точно введут белые списки
После атак с использованием подставных IP на крупные сайты такой список уже есть, в котором находятся крупные домены/IP которые блочить нельзя.
dimm_ddr
13.08.2019 13:13То есть существует список доменов за которыми можно прятаться? Или там для каждого жестко прописаны IP и можно быстро сопоставлять?
AlxDr
13.08.2019 10:34Так это уже происходит. Сейчас есть масса заблокированных доменов, которые уже прекратили своё существование и доступны для регистрации кем угодно. Можно зарегистрировать, прописать в DNS айпишники конкурента и у многих провайдеров они автоматом попадут в бан, так как блокировки у них работают по IP.
РКН выстрелы в ногу не смущают нисколько, так как ноги — не их. Поднимется совсем уж буча (как во времена ковровых бомбардировок Телеграм, когда даже Гугл поломали) — исправят. А в остальном проблемы индейцев шерифа не волнуют.
Белые списки, кстати, уже есть, как отметили выше.
konchok
13.08.2019 10:16>очень дорогая операция при проверки блокировок
Это совершенно рядовая операция на DPI в Китае, где файрвол чуть что сам пытается установить соединение на удалённый IP: порт и посмотреть что там. Без наличия реально функционирующего сайта мимикрирование под HTTPS вообще смысла не имеет — всё это будет работать несколько минут от силы а потом скорость урежется до 100байт/c. Выходом из этой ситуации может быть предварительный port knocking: правильному IP на MTproxy даём Телеграм, остальных через NAT пробрасываем на гугль или куда ёщё.
F0iL
13.08.2019 11:04+1Выходом из этой ситуации может быть предварительный port knocking: правильному IP на MTproxy даём Телеграм, остальных через NAT пробрасываем на гугль или куда ёщё.
По идее лучше не port knocking, а https knocking, раз уж мы маскируемся под валидный HTTPS сайт.
Я специально для такого штуку делал некоторое время назад github.com/uprt/labean
levchick
12.08.2019 08:57+1Тот же 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
ainu
12.08.2019 09:09Кмк провайдеры будут поступать проще:
1. Видим обращение к Google.com
2. Записываем увиденный IP
3. Проходимся по всем свежим IP, которые увидели, открываем по https. Если сайт не открылся — блокируем по IP.
istepan
12.08.2019 09:35Так и будут делать. Поэтому надо проксировать оригинальный гугл в случае отсутствия секрета.
thatsme
12.08.2019 21:36Может проще, ч-з translate.google.com получать bootstrap-лист? А там HTTPS/Websockets и страничка шаблонная. Хотя тоже научатся понимать, что эта страничка не спроста, и траффика многовато.
shifttstas Автор
12.08.2019 09:50Это легко настраивается — установкой типа nginx/Apache и проверкой SNI, если он другой — отправляем в веб сервер. Но тут нужен eSNI.
AlxDr
12.08.2019 12:21Здесь нужен не SNI или eSNI, а проверка по ключу.
Если ключ неверный, то отправляем в веб-сервер
Тогда и eSNI не надо ждать. Кроме того, теоретически и с eSNI возможны варианты. Например, РосКомПозор под влиянием очередного обострения может начать сканировать «подозрительные адреса» по принципу «порт 443 открыт — разрешаем во все возможные домены и пытаемся соединиться, всё не соединившееся — в бан, а там Господь отделит своих от чужих». И вообще, поддельный SNI — бессмысленное усложнение.
Телега как раз должна корректный SNI передавать. Если прокси называется kotiki.ru, то и SNI должен быть именно такой, чтобы браузер открыл с ним тех же котиков.SemenPV
12.08.2019 16:37+2Обяжут всех провайдеров иметь по нескольку мобильных клиентов телеграмма которые будут симулировать работу обычного пользователя, как только соединение рабочее, /16 сетку в блок. Дёшево и сердито, не нужны DPI и т.п. Сам факт успешной работы клиента достаточен для блокировки. Оставят только whitelist сетки, а остальные как правильно сказали — «Kill them all and let God sort them out»
Государство неповоротливая машина, но если оно всё таки повернётся — то шансов нету. Понятно что останутся лазейки, но задача отрезать основную часть от сервисов и при наличии политической воли, это делается легко.
Основная надежда что им на самом деле это не надо, а нужен процесс в течении которого можно денег срубить и электоральной базе показать что борьба идёт.shifttstas Автор
12.08.2019 16:50Это позволит заблокировать только публичные адреса, не более, личные прокси будут невидимы.
SemenPV
12.08.2019 17:01+3Задача заблокировать условного Васю который установил приложение на телефон и хочет его использовать. Он не знает слов DPI, SNI, TLS.
От сисадмина Пети, понятно что ничего не заблокируешь, он всегда найдёт лазейку.
С опозиционером Лешей будут работать по другому, будут его товарищей трафик собирать и анализировать. Потом подсунут через незащищённое HTTP соединение специальный контент, придут его из кэша достанут и подведут под статью.
Как только 99% Вась не смогут легко работать с чем-то, то популярность сервиса сдуется. Мессенджеры привлекательны когда они есть у всех, а если только пара Петь с ними работает, ну и бог с ними.santa324
12.08.2019 22:07Можно для Васи сделать платную услугу на зарубежном сайте по покупке личного замаскированного под TLS прокси на уникальном IP. И можно не только для телеги, а вообще. Достаточно ему самому или попросив Петю один раз купить себе такой прокси и единолично потом пользоваться сколько угодно, всем кроме Васи он будет просто сайтом. Товарищ майор можно покупать тоже и блокировать полученные IP — но пространство IP большое. Сам сайт по продаже можно конечно блокировать, но достаточно один раз хоть как-то получить туда доступ (например из отеля в Турции) и дальше у тебя свободный инет через прокси. Придется вводить белые списки…
SemenPV
12.08.2019 22:09Если бы Васи готовы были платить, думаю РКН сам бы ввел услугу для whitelist source IP.
А так это мечты, тем более при наличии более чем достаточного количества совершенно бесплатных, конкурентноспособных мессенджеров.santa324
12.08.2019 22:15Ну так такой прокси можно не только для месенеджеров использовать.
Продолжат такими темпами блокировать все подряд — Васи могут и платным заинтересоваться.
Но это скорее интеллектуальное упражнение продемонстрировать что без белых списков блокировки даже Васю не остановят.SemenPV
12.08.2019 22:20Вы что-то Вась переоцениваете. Основной контент для них идёт с RU сегмента. До тех пор пока кино/видюхи можно будет бесплатно смотреть на тех же ok.ru/my.mail.ru/vk.ru то можно за них не волноваться.
AlxDr
12.08.2019 17:24Да, сейчас задача — потянуть время и повысить ставку. Показать, что «контролировать Интернет» дорого, сложно и проще заработать политический капитал и попилить деньги на чём-нибудь другом.
Ну и самим себе обеспечить сносное существование на период смутного времени.
Это не значит, что нужно заниматься только этим, но и этим нужно заниматься тоже. Чем легче им даётся весь этот беспредел, тем быстрее он продвигается и растёт самоуверенность его инициаторов.
ilyapirogov
12.08.2019 18:41+1как только соединение рабочее, /16 сетку в блок
Было бы забавно, если бы при этом клиент телегама запрашивал, например, favicon.ico с сайта
https://rkn.gov.ru/SemenPV
12.08.2019 18:49+1Поэтому и написал
Оставят только whitelist сетки
Ну и с учётом наличия open source клиента, узнать правильный адрес сервера не представляет никакого труда.
Расцветёт бизнес типа открою прокси телеграмма в подсетки вашего конкурента.
Chamie
12.08.2019 19:02Ну и с учётом наличия open source клиента, узнать правильный адрес сервера не представляет никакого труда.
Он адреса в т.ч. через системные пуши получает, насколько я понимаю.SemenPV
12.08.2019 19:04Пусть получает откуда угодно, если мы смогли доставить сообщение тестовому клиенту на другой стороне, то это рабочее соединение и его можно блокировать.
shifttstas Автор
12.08.2019 19:15Вы похоже не знаете как работают пуши — их рассылается Google или Apple а не каждое приложение само. Заблокировать пуши только от одного приложения — нельзя.
RomanGL
12.08.2019 20:52Так речь не про пуши. Клиент получил новый адрес, соединение установилось — в бан всю подсеть.
shifttstas Автор
12.08.2019 21:52Так это уже проходили — банили Амазон, Гугл, других хостеров, сменить локацию сервера и отправить новый IP — дело 2 минут.
konchok
13.08.2019 10:39На API Амазона даже и двух минут не надо, всё это делается через пару https запросов из скрипта.
ilyapirogov
12.08.2019 19:17По поводу whitelist я согласен, это уже последний бастион.
А вот анализ исходников — это уже совсем не такая тривиальная задача, как поставить телеграм и блокировать все куда он ломиться.
Начнем с того, что только официальные клиенты могут быть разные для разных платформ. А по мимо этого, может быть и куча не официальных клиентов.
Тратить столько ресурсов, что бы заблокировать один единственный мессенджер? Я думаю вайтлист тут куда более вероятен.
Balling
12.08.2019 19:49Зачем это делать? Вы вообще понимаете, что такое интернет? Это сеть автономных систем. Находим АСы google и блокируем… bgp.he.net/search?search%5Bsearch%5D=Google&commit=Search
Правда там есть еще GGC… Который не всегда принадлежит google…
enzain
13.08.2019 10:52эээ… а что, виртуал хост уже отменили?…
сайт по ип и сайцт по имени на том же ип могут быть совсем разными, и сайт по ип — вполне себе может вообще не работать. (хотя обычно по ИП отдаю — форбидден)
GennPen
12.08.2019 10:19DPI же используется у оператора, к которому подключены абоненты, поэтому практически всегда используется один и тот же DNS.
jdjohndoe13
12.08.2019 13:35+1В смысле? DNS же можно прописать вручную. А еще можно использовать DNS-over-HTTPS (он недавно в Firefox появился, в Google Chrome тоже грозятся скоро реализовать). И тогда неважно, есть ли DNS-сервер у оператора — все DNS-запросы будут идти мимо него.
GennPen
12.08.2019 13:52+1DNS же можно прописать вручную.
Не спорю. Но много ли вы видели обычных пользователей, прописывающих альтернативные DNS при подключении?shifttstas Автор
12.08.2019 14:17В телеграмме уже как год используется свои DNS через DNS OVER HTTS (google/Cloudflare) он не использует провайдерский
PsyHaSTe
13.08.2019 16:44Проблема с телегой в т.ч. скачать её — ибо без VPN у меня даже в выдаче гугла
telegram.orgне появляется.
Поэтому чтобы скачать телегу УЖЕ должен быть работающий впн. Я уже замучился на каждый новый комп первым делом ставить openvpn, и ломиться генерировать очередной ключик.
friezy
13.08.2019 16:54Есть зеркало (официальное или нет не могу сказать) — telega.one
P.S. Проверил, не все поддомены видитPsyHaSTe
13.08.2019 16:58У меня всегда паранойя, что это зеркало может быть не очень честным, а может даже и злонамеренно открытым, и там может быть на скачивание не совсем правильный телеграм клиент.
ne_kotin
13.08.2019 16:59Десктопную — с гитхаба, как выше советуют.
Мобильные — с соответствующих сторов.
Balling
12.08.2019 19:54Вообще-то тут mozilla проводит Study trusted resolver-a в firefox. Так что, пользуюясь firefox, запросы сейчас у многих идут в обход провайдера.
konchok
13.08.2019 10:44DNS-over-HTTPS в Firefox включаешь и можно забыть про вайфай хотспоты в метро итд. Для рядового пользователя не очень приемлемо.
dartraiden
12.08.2019 08:43Сейчас оба прокси сервера используют домен 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, если видит проблемы).shifttstas Автор
12.08.2019 08:59И тогда это использовал именно сам телеграм, сейчас метод будет доступен обычным пользователям. Ранее правда было вот так:
- Telegram жил в облаке гугл
- Telegram запрашивал сайт А в облаке, а подключался к Б в том же облаке
Гугл был против такой схемы, сейчас же вы можете отправлять в заголовке Google а иметь сервер в Hetzner или Digital ocean, гугл может быть против, но сделать ничего не сможет. А сверка SNI:IP — очень дорогое занятие при проверки ресурса на блокировку.dartraiden
12.08.2019 09:24делать ничего не сможет
Теоретически может пригрозить удалением такого приложения из маркета.
Whuthering
12.08.2019 10:02А сверка SNI:IP — очень дорогое занятие при проверки ресурса на блокировку.
Ничто не мешает делать это отложенно, видим коннект с новой парой (искать можно быстро по хэшам) — отправляем его в очередь на проверку и ждём результат, если по результату выявлено несовпадение, добавляем в блок на будущее. Правда, следующим шагом клиенты научатся автоматически генерировать уникальные рандомные доменные имена по шаблону :)shifttstas Автор
12.08.2019 10:06Или вместо Гугл указывать свой домен i_love.cats который вполне реальный и на котором есть веб-страничка с котиками.
domix32
12.08.2019 12:54Подумалось, насколько безумна идея указывать домен какого-нибудь сбера в этом случае.
whyme
12.08.2019 16:33+1Блокировать будут не домен, а ip вашего сервера, поэтому в целом бессмыслено. Но тут есть вариант с белыми списками (вроде такой составлялся Роскомнадзором), возможно, указав домен из белого списка, дальнешийх проверок не последует.
site6893
12.08.2019 17:22блокировать только IP бессмыслено, сменить айпи на новый… делается автоматом как только старый заблочен. Каждый раз проверять автоматом и обновлять список айпишников на кторые домен резолвится добавляя их в бан черевато граблями которые уже проходили, кто-то из владельцев домена елементарно зарезолвится на айпишники правительственных сайтов и РКН с гигиканьем заблочит госуслуги на полстраны ))
whyme
12.08.2019 17:56ну я отвечал по ветке проверки SNI:IP для телеграмма, в данном случае вряд ли даже в Роскомнадзоре догадаются банить заведомо фейковые домены типа «google.com».
in_heb
12.08.2019 16:49Нет смысла. Указывать домен гугла имеет хоть какой-то смысл, т.к. google.com может резолвится во что угодно, в том числе в IP-адреса, которые гуглу не принадлежат (в случае направления на GGC)
У Сбера и подобных, IP-адреса весьма жёстко прибиты и будет довольно легко путём простейшего «детектора аномалий» и подобных методов вычислять владельцев таких прокси.
Единственный рабочий вариант это указание собственного домена, чтобы было максимально сложно находить такие прокси
То что сделали телеграмм сейчас (отправка google.com из клиента) это просто подарок для тех, кто занимается вычислением этих прокси. Без задания своего домена я бы не стал связываться.
seriyPS
12.08.2019 22:15Домен
google.comберется из секрета. Его можно на что угодно заменить.in_heb
13.08.2019 10:54Как задать другой домен в клиенте?
seriyPS
13.08.2019 11:22$ 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: разметка поехала, не знаю как поправить
shifttstas Автор
12.08.2019 10:00Вы предлагаете направить на DPI весь HTTPS трафик и во всем трафике проверять SNI, что очень дорого и медленно и есть шанс зацепить что то лишнее, если идёт общение без SNI как такового с намертво прибитым сертификатом у клиента (так делают банковские приложения и не только)
Revertis
12.08.2019 11:02Зачем направлять? Просто зеркалировать первые пакеты соединений.
shifttstas Автор
12.08.2019 11:30А смысл? Это не решит проблему нагрузки.
Revertis
12.08.2019 11:35Смысл? Для выявления новых IP поиском по хэштаблицам, а потом проверки SNI, сертов и т.п.
shifttstas Автор
12.08.2019 11:42+2Окей, у вас не сошёлся SNI, если такое заблокировать — пострадают банки и любое приложение которое использует фиксированный сертификат прибитый гвоздями. (Ну и весь Энтерпрайз).
Я все ещё не понимаю что даст анализ, особенно если мы предполагаем все же переход на eSNI.
Pas
12.08.2019 10:32Ещё есть трафик вообще без TLS SNI. У кровавого энтэрпрайза и им сочувствующих такое случается повсеместно.
kryvichh
12.08.2019 11:55Есть вообще трафик по самописным протоколам, на левые порты, по непонятным IP-адресам. Поди разберись что там стоит на сервере: самописная CRM-система, или неведомый тип Telegram-прокси для кастомного клиента.
konchok
13.08.2019 10:50Этот SNI только и нужен когда много доменов на одном IP. На корпоративном/личном прокси вообще лишняя сущность.
keydon2
12.08.2019 09:03Ожидал такой реализации с самого начала.
После пустышки Mproxy, представленный как средство улучшения безопасности, доверия к протоколам телеграма нет (да и к самому телеграмму). Поэтому только VPN.shifttstas Автор
12.08.2019 09:08MTProto решает один очень важный момент — при сценарии «гос-сертификата» соединение не установится из-за того, что MTProto не используем привычные сертификаты как следствие установка корпоративного или иного корневого сертификата не позволяет расшифровать трафик.
TimsTims
12.08.2019 09:22При этом такие «гос-сертификаты» еще нигде кроме Казахстана не внедрили (да и то безуспешно), поэтому такой сценарий почти не реалистичен. А вот DPI уже давно у всех есть и все его применяют.
Serge78rus
12.08.2019 10:22+1… такой сценарий почти не реалистичен ...
Сколько раз за последние несколько лет мы произносили подобные фразы и каждый раз ошибались в определении границ, до которых может дойти.TimsTims
12.08.2019 11:21Я имел ввиду, что можно конечно делать крутой супер-протокол, который будет работать, если упадет метеорит, и затратить на это 2 года, и ждать неизвестно сколько падения метеорита. А можно прямо сейчас внедрить fake TLS, и уже обойти все существующие блокировки, при уже осуществлённом сценарии.
Pas
12.08.2019 10:37+1В Казахстане уже развнедрили. Но никто не мешает сделать заход №2. Ну а в корпоративных сетях свой trust anchor де-факто стандарт, хотя в них, конечно, трафик к мессенжерам отдельно регулируется. Отдельно «белый» MITM любят устраивать всякие антивирусы, впихивая свой суррогатный рут в доверенные. Тоже, кто его знает, что они по факту собирают и в чьих интересах.
kryvichh
12.08.2019 11:59Во-во. Поэтому я всегда отказываюсь от настойчивых попыток бесплатных антивирусов защитить меня в Интернете.
hokum13
12.08.2019 13:13Это как всегда борьба снаряда и брони. Т.к. по сути, только телега препирается с РКН (оставим споры о том, по-настоящему или нет), то внедрение MTProto тормознуло тот маразм, который попытались внедрить в РК. Возможно теперь в РФ и не внедрят из-за безсмысленности затеи.
Главное чтобы в ответ на вот это вот обновление РКН не выступил с инициативой запретить вообще весь TLS. Для защиты детей разумеется. Впрочем не удивлюсь.khim
12.08.2019 14:15+1Главное чтобы в ответ на вот это вот обновление РКН не выступил с инициативой запретить вообще весь TLS.
А зачем ему выступать? Я думаю этот вопрос уже давно прорабатывается на предмет технической реализуемости.
Так как это совершенно логичное решение для страны, которая хочет контролировать сеть в своих границах.hokum13
12.08.2019 16:22-1А зачем ему выступать?
Ну кто-то же должен стать иницаитором процесса. Если не РКН, то придется «яжматерям» опять платить.
из-за HSTS возврат в HTTP невозможен.
Завтра на законодательном уровне запретят сертификаты от заграничных CA и станет «невозможное возможно...» Кто-нибудь еще помнит linkedin?shifttstas Автор
12.08.2019 16:52+1Хром (и другие боаузеры) не будут ничего делать, можно хоть 10 законов принять.
hokum13
12.08.2019 17:35Хром спокойно открывает сайты без шифрования. Просто обяжут эти самые сайты использовать только простой http. FB, VK, YA, G и прочие гиганты просто прогнутся (т.к. деньги не пахнут — практика уже показала), а всякие там мелкие субкультурные ресурсы можно и заблокировать безболезненно, как это было с linkedin.
Не поймите меня неправильно — я резко против, но вижу к чему идет и пока не вижу дна, от которого можно было бы оттолкнуться.shifttstas Автор
12.08.2019 18:08+1Из вашего списка прогнутся могут только: vk и ya. Остальные этого делать не будут по тем же самым коммерческим причинам, сохранение денег от «прогиба» — намного меньше чем потери от падения акций (и доверия) после такого решения.
hokum13
13.08.2019 10:20не будут по тем же самым коммерческим причинам
Ну с тайной переписки то и удалением ссылок уже прогнулись. Вопрос в размере потерь и доходов.
В конце концов все в курсе истории с гуглом в Китае.
Я не вижу снижения активности среди моих контаков в линкеде.
А я не вижу блокировок вообще (не скажу как). И ПР-ом меня и моих знакомых на выходных не дубасят. Значит ли это, что у нас соблюдается конституция?
Речь не о том, что часть целевой аудитории имеет доступ к линкедину, а о том, что он не общедоступен. И это печально.
in_heb
12.08.2019 18:41+1В линкедин сидят HR-ы почти всех IT-компаний и их активность не стала ниже после блокировок. Да и вообще, большинство ИТ-специалистов вынуждены иметь средства обхода блокировок (т.к. из гугла часто попадаешь на заблокированные страницы по технической тематике), а следовательно, ИТ-шники там продолжили сидеть.
Я не вижу снижения активности среди моих контаков в линкеде.
P.S. Работник моего круга, залогинься
ksenobayt
13.08.2019 09:11Кто-нибудь еще помнит linkedin?
Помню, пользуюсь. По ощущением, просадки среди целевой аудитории практически нет.
General_Failure
13.08.2019 09:32Пишут оттуда регулярно, и даже из Касперского (да-да, те самые которые vpn дают с фильтром от роскомпозора)
Darka
12.08.2019 09:25Когда уже можно будет использовать Telegram/MTProto в качестве транспорта, например как в tuntox.
shifttstas Автор
12.08.2019 09:34А зачем? Назначение протоколов разное.
Darka
12.08.2019 10:00Нунапример у некоторых оперторов Телега бесплатная и безлимитная
shifttstas Автор
12.08.2019 10:04У тех операторов, у кого она бесплатная идёт определение не по DPI а через белый список сетей телеграм. DPI очень не надёжен и позволяет делать Фрод, который вы собственно и описали. При белом IP списке — такого не будет.
Chupaka
12.08.2019 10:13А в TLS-ответе сертификат сервера шифруется или нет? Неужели его не видно, как SNI?..
seriyPS
12.08.2019 10:47Telegram притворяется TLSv1.3, а в нем сертификат сервера всегда зашифрован.
Chupaka
12.08.2019 10:58+1Но если мы пойдём медленным путём, повторив соединение от себя (пока eSNI ещё не в деле) — мы без проблем получим реальный сертификат сервера и увидим, что "царь-то ненастоящий"?
seriyPS
12.08.2019 11:29Ну да, в текущих реализациях прокси серверов реакция на не-телеграмный tls не такая же как у реального https. Но это поправимо.
konchok
13.08.2019 10:58Без проработки этого момента начинать продвигать fake TLS вообще смысла не имело. Китайские DPI уже много лет сами соединяются с сервером в любых непонятных ситуациях.
seriyPS
13.08.2019 11:331) https://habr.com/ru/post/461171/#comment_20497965
2) Всё-же замечу, что текущие реализации fake-TLS proxy деланы волонтёрами методом реверс-инженеринга. Возможно в официальном это будет как-то иначе решено
seriyPS
12.08.2019 10:22в будущем авторы прокси обещают сделать ввод других доменов и возможность не пускать клиентов, если они используют другой домен при согласовании подключения.
Для "ввода других доменов" от прокси ничего не требуется. Что вы положите в base64 секрет после 17го байта то и будет передано как домен.
Блокирование доступа по домену в Erlang прокси уже реализовано https://github.com/seriyps/mtproto_proxy/blob/b6565d23dc2bdafe68587c9b73dd130bb17f019e/src/mtproto_proxy.app.src#L63
Revertis
12.08.2019 11:08Я что-то не понял, а свой домен подложить, да ещё и с настоящим сертом от того же Let's Encrypt, пока нельзя?
amarao
12.08.2019 11:45+1Мне кажется, что следующим этапом будет честный SSL (в том числе с mitm), внутри которого уже будет стеганография. Веб-сокеты, вложенный коннект, обмен фотографиями, etc. Одним из интересных приёмов будет DoS атака на DPI, когда понять "телеграм или нет" можно будет только затратив ощутимые ресурсы. Например, bcrypt с большим числом раундов, внутри которого "telegram".
shifttstas Автор
12.08.2019 11:54+1Что такое: “честный SSL с MITM” ?
okeld
12.08.2019 13:54Как я понял автора комментария: Использовать HTTPS протокол, видимый для DPI, который будет инкапсулировать уже протокол MTProxy. В таком случае нужен будет свой TLS сертификат для HTTPS трафика (Например, lets encrypt), на который государство может осуществлять бессмысленную MITM атаку с подменой сертификата, как в Казахстане. Бессмысленную — потому что внутри первого слоя будет уже MTProxy.
amarao
12.08.2019 13:58TLS с настоящим (но, например, самоподписанным) сертификатом, который может перехватить mitm с предъявлением своего сертификата.
algotrader2013
12.08.2019 12:22когда понять «телеграм или нет» можно будет только затратив ощутимые ресурсы
Такая ли большая проблема в вычислительных ресурсах? Ведь DPI может проверять не все пакеты, а сначала статистически выявлять пары абонент <-> ип, или даже абонент <-> кластер ип, собранный по всей базе абонентов. А потом уже по статистически подозрительным парам семплировать, скажем, анализируя каждый сотый пакет.shifttstas Автор
12.08.2019 12:32Окей, есть облако Google или Amazon или Azure — это 80% Интернета фактически, и что и как выделять кластер?
amarao
12.08.2019 14:01Во-первых бесполезно сэмплировать пакеты, надо начало сессии. Если у нас есть криптографически тяжёлая процедура ответа на вопрос "tg это или нет", то клиент за коннект платит n ресурсов, и dpi платит за это n ресурсов.
Однако, тут есть плот твист: если dpi начинает платить n ресурсов за проверку "tg или нет", то он начинает его платить и на false positive, т.е. на сессиях, которые не являются tg. Получается существенная амплификация, и если протокол достаточно подлый (т.е. специально сделанный), то понять "что это такое" получится только завершив рассчёт, т.е. честно потратив n ресурсов на каждую сессию.
algotrader2013
13.08.2019 16:01Снова таки, если действуем следующим образом:
1. Собрали статистику сессий. Абонент <-> ip
2. Выделили кластер Группа абонентов <-> группа ip, которые по поведению могут быть телеграмом (частота обращений, одновременные рассылки с сервера на много абонентов в моменты публикаций в группах с большим охватом).
3. Каждую n-ую сессию (с элементом рандома) между абонентом из этой группы и ip из этой группы проверяем, затрачивая ресурсы.
4. Если поймали, что таки тг, то заблокировали (в зависимости от отморожености блокирующих, ip, или пару ip<->абонент, или весь кластер, или еще каую-либо комбинацию). Чем сильнее блокировка, тем больше шанс, что кого-то специально подставят, имитируя тг трафик.amarao
13.08.2019 16:20Для того, чтобы собрать эту статистику вам потребуется много сессий. А сессия у TG может устанавливаться один раз надолго (в контексте IM).
После того, как вы обнаружите, что IP такой-то кажется, TG и таки заблокируем его, мы переходим к предыдущей, успешно решённой задаче — заблокировать все IP у телеграма.
algotrader2013
13.08.2019 19:23TG и таки заблокируем его, мы переходим к предыдущей, успешно решённой задаче — заблокировать все IP у телеграма
С сильным упрощением — уже есть статистика по тем, кто на забаненный ip ходил. Теперь ищем ip, на которые абоненты из этого кластера вдруг начали ходить. Проверяем только сессии туда
PsyHaSTe
13.08.2019 17:01Ждем рейды по домам от бдительных граждан с повязками "Дружинник", которые будут смотреть, установлена ли телега на компе и телефоне.
masv
13.08.2019 17:13Нужна стеганография наличия тг на телефоне.
На рабочем ПК, который не всегда «П» некоторый персональный софт спрятан в дебрях системных файлов и запускается мной из командной строки определённой командой.
ne_kotin
13.08.2019 17:16В лучшем случае граждане дружинники дождутся вербальных инструкций о посещении известного перуанского курорта из-за закрытой двери.
Некоторые менее сознательные вполне могут и с лестницы спустить.
amarao
13.08.2019 17:28Это следующий уровень закручивания гаек. В принципе, верхняя достигнутая граница довольно высока — Красные Кхмеры убивали за очки на носу (ибо умный).
nlykl
13.08.2019 22:39А гражданам-то это зачем?
Это же не силовики с неплохой зарплатой и социальными гарантиями.PsyHaSTe
13.08.2019 23:10Ну а зачем люди в отряды путина вступают и портреты Обам\Трампов жгут?
Санкционированное насилие очень привлекательно для многих.
nlykl
13.08.2019 23:49Обама/Трамп где-то далеко за океаном, это больше мифический образ. А здесь придется вступать в открытую борьбу со своими же соседями.
General_Failure
14.08.2019 08:36+2Если у них будет поддержка от государства, займутся. Были же полицаи из местных во время второй мировой.
masv
14.08.2019 09:50Полицаи опирались на чужую армию оккупанта, которой не трудно спалить деревню бунтовщиков. Родная армия не пойдёт против своего народа. У современных полицаев опора только на режим, который стоит на плечах МВД, ФСБ, росгвардии.
General_Failure
14.08.2019 09:58Армия может и нет (есть сомнения), но МВД и ФСБ — как раз и есть армия против своего народа (пруфы — ну например недавние события в Москве). Если спустить с лестницы дружинника будет примерно равняться спуску с лестницы полицейского, то дружинники будут вести себя как полицаи во время войны.
DarkMike
12.08.2019 14:00Угу. И если использовать полный TLS с запросом пользовательского сертификата, то понять, что на домене private.supersite.com живет реальный сайт доступный только избранным с сертификатами или прокси телеграма нереально
Andrey_Rogovsky
12.08.2019 12:44Даже в Китае уже научились обходить ВКФ
А тут на подходе мешап сетиCrashLogger
12.08.2019 15:11В Китае это никогда и не было проблемой. Есть множество VPN сервисов, которые прекрасно работают. Проблема в другом — в узких каналах между Китаем и остальным миром. Из-за этого youtube нормально не посмотреть, только в 360p качестве.
DarkNews
13.08.2019 01:13Хз, в Шенчжене через впн прекрасно смотрел (2015-2017 годы) в 1080@60, через впн в ГК/Японии/Корее.
Хотя многие иностранные сайты, которые не были заблокированы, действительно плоховато грузились.
С другой стороны, с MEGA большие файлы прекрасно качались во весь канал в 300Мбит.
nlykl
12.08.2019 14:09shifttstas,
А нельзя ли сделать в опросе чек-боксы? Я бы выбрал все варианты.
Или переформулировать вопрос на «какой метод обеспечения защиты следует добавить в первую очередь?»shifttstas Автор
12.08.2019 14:22Я тоже хотел сделать чекбоксы и ранее так можно было, однако сейчас я такого функционала не нашёл :(
Boomburum
12.08.2019 15:26Это настраивается до публикации опроса — после публикации сменить тип ответов уже нельзя (
unwrecker
12.08.2019 15:49Я конечно сейчас (в рамках реалий судебной системы в РФ) наверное глупость скажу, но мне кажется телеграму стоит побороться и на правовом поле. Дело в том, что судебные решения, по которым блокируют прокси сфабрикованы: в них указано что с помощью прокси пррверяющее лицо смогло зайти в запрешённые группы, однако без пароля подключиться к прокси и проверить это невозможно. А такие решения есть даже в отношении тек прокси, пароля от которых заведомо ни у кого кроме владельца не было, и которые найдены тупо по длине пакета.
Aingis
12.08.2019 16:05+1Уже борются, Агора представляет Телеграм, но, как я понимаю, результатов пока никаких. Политическое решение.
entze
12.08.2019 20:51Борьба с телегой какая-то странная. Вроде бы как есть, но эффективность здесь относительно других стран ниже? Т.е. телега здесь и сейчас получается таргетирована на аудиторию, которой можно впаривать контролируемые каналы. А относительно тех стран, где блокировками озабочены куда серьезнее, где более массовая аудитория. Например Иран.
Расширение аудитории здесь не выгодно, но и не выгодна полная блокировка? Иначе ковровые блокировки целыми подсетями сохранялись бы.
shifttstas Автор
12.08.2019 21:53Коовровые блокировки приносят убыток бизнесу и они не выгодны %username%
unwrecker
14.08.2019 00:05Победа в борьбе с блокировками Телеграму больших ресурсов стоит. А где с Телеграмом борятся эффективней? В Китае он работает нормально без проксей (правда картинки не грузятся). В Иране куча прокси, и они наводнены рекламой, стало быть не оскудеет рука их дающая :)
Radjah
12.08.2019 18:04> Бета версии Telegram Desktop
1.8.1 про этот режим ничего не знает.
Свежее на github не вижу.ksenobayt
13.08.2019 09:13Десктоп-клиент сильно отстаёт по фичам от мобильных, как правило. Это нормальное положение дел, через несколько дней-недель приедет.
Groosha
13.08.2019 15:22Не соглашусь. Есть mobile-only фичи, типа InstantView, тогда да. В остальном TDesktop последнее время одним из первых релизит очередное обновление.
zenkov
12.08.2019 19:22> Сейчас оба прокси сервера используют домен Google.com
Интересно что Signal запретили заниматься подобным когда они собрались обойти блокировку в Эмиратах. Тут у нас опять система двойных стандартов от американских интернет-гигантов или я что-то путаю?khim
12.08.2019 20:44+1«Что-то путаете». Они хотели прокси на настоящих гугловых IP размещать.
А тут IP, которые Гуглу не принадлежат, так что Гугл ничего сделать не может. Придётся давить ISP и заставлять их подобных клиентов изгонять. Это сложнее.algotrader2013
13.08.2019 20:23Что, нету надежного способа по паре <ip, domain name> сказать valid/not valid?
khim
13.08.2019 21:19Нет. Есть способы дающие ответ «с хорошей вероятностью». Скажем известно, что Google свой контент раздаёт только из «своих» автономных систем.
Но про какой-нибудь сайт «рога и копыта» — этого узнать нельзя. Пока нельзя.in_heb
14.08.2019 10:00>Скажем известно, что Google свой контент раздаёт только из «своих» автономных систем.
Это не так. У гугла тысячи GGC-шек, которые висят на IP-адресах операторов, которые их себе ставят
YourChief
13.08.2019 05:26Пожалуй, предложу тут две своих утилиты в тему.
Первая — TLS-обёртка для соединений. По сути аналог stunnel, но только скрадывает время на установление соединений: https://github.com/Snawoot/ptw. Ей удобно обернуть коннект до того же SOCKS-прокси, а так же можно использовать как прозрачный прокси на роутере. Поддерживается использование самоподписанных сертификатов и сертификатов с subject-ом, не соответствующим адресу хоста.
Вторая — быстрая реализация SOCKS-прокси, аналогичного встроенному в ssh (какssh -ND): https://github.com/Snawoot/rsp. По сути сразу предоставляет готовый SOCKS-прокси на стороне клиента, заворачивающий соединения внутрь SSH-туннеля. На стороне сервера требуется только работающий SSH. То есть типичный виртуальный сервер сразу готов к работе в качестве прокси после развёртывания из панели хостера. Преимуществом по сравнению со стандартной реализацией SOCKS в OpenSSH является отказ от мультиплексирования соединения внутри одного тоннеля, поэтому в типичных условиях скорость существенно выше (см. сравнение скорости).
В телеграм можно задать свой SOCKS-прокси и добиться устойчивой и скрытой работы этого приложения.
rdc
14.08.2019 02:05В голосовалке очень правильная тема затронута. Давно пора закопать все эти дурацкие SMS, доступ к которым могут получить не только спецслужбы, но и любой мошенник с улицы…
kekekeks
Осталось догадаться, что надо научиться работать поверх вебсокета, тогда на хосте на все зондирующие запросы будет отвечать обычный nginx с обычным веб-сайтом. Причём для включения поддержки такой схемы на сервере достаточно обычного websockify.
Но это, видимо, слишком сложно.
shifttstas Автор
Новая веб-версия телеграмм (tdweb) которая пишется на WebAssembly работает через WebSocket напрямую с серверами TG, вполне логично, допускаю, что другие клиенты (десктоп, мобильные) получат поддержку WSS серверов и WSS прокси.
3cky
Вебсокеты — значит, (пере)подключение с использованием полноценного тяжелого TLS-протокола, что делает практически невозможным использование соединений с низкой скоростью соединения и/или высокой латентностью, то есть лишает Телеграм одного из ключевых преимуществ по сравнению с другими мессенджерами — неприхотливости к каналам связи.
wiz
На безрыбье и в вебсокеты полезешь…
domix32
Палка о двух концах — либо оно работает, но жрет чуть больше канала и дольше пингуется, либо не работает вообще из-за блокировочек. Проксирование через Tor помнится тоже было довольно небыстрым, однако доступ давало.
vak0
А почему в прошедшем времени о проксировании через Тор?
domix32
Потому, что после следующего (с начала блокировок) апдейта и чистки реестра IP все заработало без проксирования.
si001
Да, есть такое впечатление, что на вопрос «что это было?» следует отвечать — просто PR-кампания телеграма с задействованиием админ. ресурса РФ.
Конечно не я первый это придумал.
ne_kotin
С прокси он уже на EDGE ложится.
3cky
Странно, у меня через MTPROTO-прокси работает даже после исчерпания лимита мобильного трафика, когда оператор урезает до 64 кбит/с скорость соединения. А на другом операторе ТГ работает даже на неактивированной сим-карте. ) Правда, переподключается постоянно, но сообщения ходят.
ne_kotin
ну вот я когда попадаю в зону покрытия с 2G-only — ойвсё
shifttstas Автор
Вероятно в этой зоне вообще нет EDGE
ne_kotin
на палкометре телефона обычно светится E. насколько плохо на самом деле, я не заморачивался, т.к. корреляции были однозначные: E или G — и все, имеем «connecting to proxy ...», минимальная работоспособность обеспечивалась на 3G.
shifttstas Автор
Скорее всего проблема в том, что оператор вообще не даёт Интернета, т.к телеграм при хорошем EDGE вполне себе работает.
struvv
Звонил из самолёта через mtproxy через спутник(скорость что-то типа 64 кбит) — всё отлично работало, другие мессенджеры, особенно slack даже подключиться не могли
nevzorofff
Очень рекомендую вывести в строку статуса скорость передачи данных. Там, скорее всего, будут нули.
Skerrigan
А каким образом это можно сделать?
ne_kotin
А вроде как не на всех андроидах это есть
K0styan
У 2G сравнительно малая ёмкость сотовой базы, а тайм-слоты на GPRS/EDGE выдаются по остаточному принципу. Так что в городах, в зонах, где ничего кроме 2G не ловит, эта ёмкость моментально выбирается звонящими. В местах, где абонентов немного — там есть шанс получить слот-другой.
sirocco
Так EDGE и не работает. В подавляющем большинстве случаев, когда на экране сияет EDGE даже пинги не проходят. В середине нулевых, помню, на EDGE фильмы с торрентов качал, за ночь 600Мб. А с появлением 3g, EDGE стал работать только там, где он и есть, в глухих деревнях.
nlykl
Год назад я перешёл на Теле-2, а до этого был на МТС и пользовался исключительно 2G. В Москве и области EDGE работал без нареканий.
shifttstas Автор
А зачем в 2019г использовать 2G ?
nlykl
Это было в 2018 :)
Для текстового контента хватает, и бережет батарею.
ANIDEANI
А зачем они делают обязательную привязку мобильного номера? Пользователи что? Не могут сами решить проблему спама? Пусть сделаю аккаунты по электронной почте с блокированием всех сообщений вне контактов, с бесплатным местом до 1 гига. тогда спамщиков не будет а телеграмм будет по настоящему доступным. 90% жителей планеты, не имеют мобильной связи.
SemenPV
razielvamp
Я представитель 34%. Не во всех странах иметь мобильный номер — бесплатная услуга. Для редких звонков в службы 19 века, которые до сих пор не освоили электронную почту, есть скайп с балансом и без абонентки. Для личной переписки — куча мессенджеров. В итоге симкарты с интернетом хватает для 99% задач. Заключать контракт с ОПСОСом и платить постоянную абонентку за сохранение номера только ради аккаунта в телеге? Нет, как-нибудь без меня.
ne_kotin
так на нее и регайте, в чем проблема?
даже припейды живут примерно полгода без пополнения.
Irgen
У вас в телефоне симка с интернетом, но без телефонного номера? Так бывает?
khim
Бывают такие, которые не поддерживают приём SMS, вроде…
Irgen
Первый раз слышу, честно говоря. Я очень поверхностно представляю как работают телефонные сети, но мне казалось что симка это всего лишь ключ для авторизации на базовой станции, и этот ключ сопоставляется с определенным телефонным номером (конкретным абонентом), а весь прием и передача обрабатываются радиомодулем телефона, и симка не может помешать ему принимать смс, но при этом получать данные. Получается что абонент есть, а номера у него нет?
shifttstas Автор
Наличие номера — не обязательно.
khim
Так и есть, но ведь базовая станция — ещё не вся сеть. Есть роутинга SMS на данный номер и звонки не поддерживаются, то это его не нужно хранить в соответствующих таблицах и прочее. Хотя на практике это, скорее всего, всё равно всё происходит и отказ от поддержки SMS — просто способ предложить ещё один тариф.
Обычно это для IoT предлагается: теоретически IoT устройство может принять SMS… но что оно с ним будет делать?
shushu
Возможно случаи разные. Но была симка — только для интернета. СМСки приходили, даже входящие вызовы работали. Но вот позвонить нельзя — да
razielvamp
Номинально номер есть. В свойствах девайса можно найти. Смс на него не приходит, звонки, естественно тоже. В контракте он тоже нигде не указ ан, так что я даже не уверен в его неизменяемости.
Припейд симки работают даже год а не пол года без пополнения баланса, но я пользуюсь припейд именно потому, что могу в любое время ее выкинуть. И не хочу вспоминать какие же сервисы были привязаны к ней? Тем более что в отличие от почты тел. номер будет 100% переиспользван другим человеком.
Для использования не припейд карты с тел номером надо заключать контракт минимум на год со штрафом при досорчном расторжении.
Я вообще не понимаю, как можно кичиться какой-то приватностью и безопасностью с такой дырой, как авторизация по телефонному номеру.
Уже сколько новостей было про угон инфы с помощью дубликата или угона номера, и при этом я не припомню не одну статью, где для угона или прослушки воспользовались бы самыми ужасными и нашумевшими poodle ssl или meltdown уязвимостями, неговоря уже про сотни других. Все только в теории
ne_kotin
2ФА вас спасет
ShashkovS
А я у себя настроил SSLH (см. habr.com/post/412779). И в итоге у меня открыты два порта: 80 (редиректит на 443) и 443. А уже через 443 идёт и телеграм, и openvpn, и ssh. И да, на «обычные» запросы отвечает nginx, раздаёт зеркало одного из моих проектов.