К ближайшим аналогам, организованным выпускниками техкомпаний, можно отнести сообщества Xooglers и YNDXFamily
YNDXFamily это не ближайший аналог, это то же самое -- это UnionVK на самом деле от тех же людей, что и YNDXFamily, а не от "Бывших сотрудников VK".
В "политиках в отношении обработки персональных данных" фигурирует некая "Alumni Hub LTD". В реестре юрлиц Великобритании основателем и "person with significant control" указан ABDUKHAMIDOV Anton.
Если открыть Notion, на который ссылка на unionvk.com (Вся информация о прошедших и ближайших мероприятиях — ЗДЕСЬ), и перейти на уровень выше в том же Спейсе Notion -- попадаем на страницу "МЕДИАСТРАНИЦА — частично для внешних, ч-но для внутренних" Там на страничке можно найти имена нескольких человек, которые на самом деле занимаются этим проектом:
Stepan Svistunov, Alexandra Sasha Pryakhina, Anton Abdukhamidov
Их несложно найти в LinkedIn и других соцсетях -- и заметить, что ни один из них никогда работал в VK. Ну и для страницы на Notion в превью Телеграм тоже закешировано имя "YNDX Family".
Anton Abdukhamidov и некоторые другие сотрудники YNDXFamily/UnionVK работают в GuruDev Capital.
GuruDev Capital занимается инвестированием в стартапы, основатели которых -- выходцы из "бигтеха", включая российский БигТех.
Не вижу ничего плохого в том, что создатели YNDXFamily создали UnionVK, но не очень понимаю, зачем говорить "Бывшие сотрудники VK сформировали сообщество UnionVK" -- если это сотрудники конкретного инвестиционного фонда, который специализируется на бывших сотрудниках бигтеха (включая VK и Yandex).
Уверены, потому что в процессе "обмена сессионными ключами" присутствует следующие шаги:
Клиент генерирует временный рандомный ключ
Клиент шифрует этот ключ и еще кое-какие данные публичным ключом, который "вшит" в приложение
Он отправляет результат шифрования на сервер, и тот расшифровывает временный ключ, и используя его и еще одно случайное значение (server_nonce), которое известно клиенту, серверу (и тем, кто занимался MITM атакой) получает ключ и вектор инициализации для AES, и шифрует этим сообщение, в котором содержатся параметры сервера для диффи-хэллмана (dh_prime aka p, g и g_a=g^a mod p)
Клиент расшифровывает ответ сервера, проверяет надежность параметров для диффи-хэллмана, и отправляет серверу g_b=g^b mod p
g^{ab} mod p используется как auth_key
То есть, для проведения MITM атаки нужно либо получить их приватный RSA ключ за время с момента создания Telegram, либо сломать RSA/AES256-IGE за краткий промежуток времени, пока клиент раскладывает число на множители и сервер/клиент ждут ответа друг от друга.
Прокси ничем не отличается от того же провайдера — если может взломать автор прокси, то может и провайдер, и "хакер" за соседним столиком в кафе, и много еще кто. Или они не входят в вашу модель угроз?
upd:
Ну и немного ссылок, так как это скорее TL;DR:
Это вы про t.me/tgiostests/34850, а разработчик — это sadal?
Если да, то вынужден вас расстроить — sadal не является разработчиком Telegram, и имеет к Telegram в целом не большее отношение, чем Я — занимается модерацией и ещё парой волонтерских проектов у Telegram.
фишку со sponsored channel никто из них не поддерживает, разумеется
Sponsored channel идет через сервера Telegram: Клиент подключается к серверам Telegram и в initConnection передает IP и порт используемого прокси-сервера — а тот (сервер Telegram) уже находит по ним соответствующий Sponsored channel и передает его клиенту.
Начну с довольно резкого вопроса: Что это делает на хабре?
Ни слова про техническую реализацию.
Точнее, пару раз упоминается, что это "почти TLS". Это не соответствует правде.
Недавно подобная статья была на TJournal, где Даша aka koteeq из VeeSecurity дала неплохое описание протокола "obfuscated2", который используется в том числе для "mtproto proxy". Процитирую:
На днях по приколу писала DPI, определяющий пакеты Telegram по содержимому:) Обфускация "anti-DPI" там простая. Генерят на клиенте случайный 32-байтовый ключ и 16-байтовый IV, ими шифруют пакет с AES CTR и отправляют. При этом сами ключ и IV отправляются перед зашифрованной нагрузкой.
В итоге, если вы провайдер, вам нужно ВСЕГО ЛИШЬ брать от каждого исходящего пакета 8-40 байты (ключ) и 40-56 байты (IV), расшифровывать содержимое (64-… байты). В расшифрованном содержимом уже вполне стандартный mtproto-формат, где первые 8 байт — сигнатура авторизационного ключа. Поймали несколько пакетов, где первые 8 байт после расшифровки совпадают — смело вносим конечный адрес в реестр запрещённых ресурсов. насчёт ВСЕГО ЛИШЬ и почему я вообще об этом открыто говорю, не боясь дать подсказку РКН: сама идея слишком простая, глупая, а защиты-то по сути никакой, но вот только ни у одного провайдера не хватит мощностей каждый пакет расшифровывать с AES-256 и какие-то проверки проводить на предмет наличия там Telegram.
Идем дальше:
Внутри тоннеля — «каша» из шифрованного трафика, трафик зашифрован, как можно догадатся, тем самым паролем/секретной фразой которую вы вводите при подключении. Но не только ей, конечно же, тут используются все возможности SSL/TLS.
"Секретная фраза" не принимает участия в шифровании, и нужна только для авторизации — можете сами в этом убедиться, просто открыв и бегло просмотрев код любой (неофициальной) реализации. Про "все возможности SSL/TLS" я уже сказал выше.
На просторах чатов в телеграмм был найден полу-официальный прокси который прекрасно работает с новым протоколом и (похоже) запущен одним из разработчиков, собственно вот он
Абсолютно никаких пруфов, конечно же. Просто ссылка со словами "запущен одним из разработчиков". Может расскажете, почему "похоже"?
PS А еще в самой свежей версии библиотеки для VOIP звонков которая используется в telegram найдена поддержка режима конференций, похоже скоро будет сразу два больших анонса.
А это вообще какое отношение к теме статьи имеет? И снова без каких-либо ссылок или пруфов...
RSA хоть и тормозной, но есть гипотеза что он более стойкий чем ECDSA и 25519 за счёт того что у него разрядность сильно выше, как минимум квантовые компы под него обойдутся сильно дороже.
Кривые на квантовых компьютерах ещё быстро ломать не умеют, в отличие от того же RSA.
Согласен насчёт паранойи насчёт Signal — уж слишком его пиарят, аж подозрительно. Даже если там нет никаких закладок, и вообще он великолепен, слишком привязываться к одному транспорту нельзя.
Не совсем. Есть 2 лимита: на общее количество контактов, и ограничение для предотвращения брутфорса.
Первый лимит — 10 000, если мне не изменяет память.
Второй лимит — что-то около 5000.
API возвращает список успешно добавленных контактов, список незарегистрированных номеров, и список номеров, которые не были проверены — их добавление клиент должен запросить позже.
Как-то ради эксперимента я попробовал добавить 10000 номеров. Сервер прислал около 200 новых контактов, 4800 номеров, которые не зарегистрированы в TG, и ещё 5000 номеров для повторного запроса.
Вот только повторный запрос естественно ничего не дал — ни один контакт не был обработан.
Я попробовал удалить часть контактов и отправить новый запрос — безрезультатно. Причем те контакты, которые сервер уже обработал до этого, продолжали обрабатываться. А любые другие, включая 5000 изначально необработанных просто игнорировались — сервер их не добавлял.
На следующий день я всё ещё не мог добавлять контакты. Больше не проверял, надоело.
1) Обычные аккаунты не имеют «bot info». Они не могут прислать текст с разметкой и уж тем более работать в inline режиме
2) @ya. Минимальная длинна юзернейма то от 4, то ли 5 символов. Не 2 уж точно.
Из википедии (Сила Архимеда):
В отсутствие гравитационного поля, то есть в состоянии невесомости, закон Архимеда не работает. Космонавты с этим явлением знакомы достаточно хорошо. В частности, в невесомости отсутствует явление (естественной) конвекции, поэтому, например, воздушное охлаждение и вентиляция жилых отсеков космических аппаратов производятся принудительно, вентиляторами.
YNDXFamily это не ближайший аналог, это то же самое -- это UnionVK на самом деле от тех же людей, что и YNDXFamily, а не от "Бывших сотрудников VK".
В "политиках в отношении обработки персональных данных" фигурирует некая "Alumni Hub LTD".
В реестре юрлиц Великобритании основателем и "person with significant control" указан ABDUKHAMIDOV Anton.
Если открыть Notion, на который ссылка на unionvk.com (Вся информация о прошедших и ближайших мероприятиях — ЗДЕСЬ), и перейти на уровень выше в том же Спейсе Notion -- попадаем на страницу "МЕДИАСТРАНИЦА — частично для внешних, ч-но для внутренних"
Там на страничке можно найти имена нескольких человек, которые на самом деле занимаются этим проектом:
Их несложно найти в LinkedIn и других соцсетях -- и заметить, что ни один из них никогда работал в VK.
Ну и для страницы на Notion в превью Телеграм тоже закешировано имя "YNDX Family".
Anton Abdukhamidov и некоторые другие сотрудники YNDXFamily/UnionVK работают в GuruDev Capital.
GuruDev Capital занимается инвестированием в стартапы, основатели которых -- выходцы из "бигтеха", включая российский БигТех.
Не вижу ничего плохого в том, что создатели YNDXFamily создали UnionVK, но не очень понимаю, зачем говорить "Бывшие сотрудники VK сформировали сообщество UnionVK" -- если это сотрудники конкретного инвестиционного фонда, который специализируется на бывших сотрудниках бигтеха (включая VK и Yandex).
Про десктопный клиент — он все ещё открытый, вот гитхаб
Уверены, потому что в процессе "обмена сессионными ключами" присутствует следующие шаги:
То есть, для проведения MITM атаки нужно либо получить их приватный RSA ключ за время с момента создания Telegram, либо сломать RSA/AES256-IGE за краткий промежуток времени, пока клиент раскладывает число на множители и сервер/клиент ждут ответа друг от друга.
Прокси ничем не отличается от того же провайдера — если может взломать автор прокси, то может и провайдер, и "хакер" за соседним столиком в кафе, и много еще кто. Или они не входят в вашу модель угроз?
upd:
Ну и немного ссылок, так как это скорее TL;DR:
https://core.telegram.org/mtproto
https://core.telegram.org/mtproto/auth_key (немного устарело)
https://github.com/telegramdesktop/tdesktop/blob/dev/Telegram/SourceFiles/mtproto/connection.cpp#L2538
Это вы про t.me/tgiostests/34850, а разработчик — это sadal?
Если да, то вынужден вас расстроить — sadal не является разработчиком Telegram, и имеет к Telegram в целом не большее отношение, чем Я — занимается модерацией и ещё парой волонтерских проектов у Telegram.
АПД: Был неправ насчет Secret'а, он действительно используется в шифровании пакета.
А вообще Анна aka koteeq написала целую обширную статью про mtproto proxy и все все все: https://t.me/theyforcedme/48.
Sponsored channel идет через сервера Telegram: Клиент подключается к серверам Telegram и в initConnection передает IP и порт используемого прокси-сервера — а тот (сервер Telegram) уже находит по ним соответствующий Sponsored channel и передает его клиенту.
Да, у меня постоянно проблемы с запоминанием имен...
Насчет пруфов и ссылок — да, можно поискать и найти. А можно сразу оставить их в статье.
Можно чуть конкретнее? Где выложил?
Начну с довольно резкого вопроса: Что это делает на хабре?
Ни слова про техническую реализацию.
Точнее, пару раз упоминается, что это "почти TLS". Это не соответствует правде.
Недавно подобная статья была на TJournal, где Даша aka koteeq из VeeSecurity дала неплохое описание протокола "obfuscated2", который используется в том числе для "mtproto proxy". Процитирую:
Идем дальше:
"Секретная фраза" не принимает участия в шифровании, и нужна только для авторизации — можете сами в этом убедиться, просто открыв и бегло просмотрев код любой (неофициальной) реализации. Про "все возможности SSL/TLS" я уже сказал выше.
Абсолютно никаких пруфов, конечно же. Просто ссылка со словами "запущен одним из разработчиков". Может расскажете, почему "похоже"?
А это вообще какое отношение к теме статьи имеет? И снова без каких-либо ссылок или пруфов...
del
Кривые на квантовых компьютерах ещё быстро ломать не умеют, в отличие от того же RSA.
Согласен насчёт паранойи насчёт Signal — уж слишком его пиарят, аж подозрительно. Даже если там нет никаких закладок, и вообще он великолепен, слишком привязываться к одному транспорту нельзя.
Не совсем. Есть 2 лимита: на общее количество контактов, и ограничение для предотвращения брутфорса.
Первый лимит — 10 000, если мне не изменяет память.
Второй лимит — что-то около 5000.
API возвращает список успешно добавленных контактов, список незарегистрированных номеров, и список номеров, которые не были проверены — их добавление клиент должен запросить позже.
Как-то ради эксперимента я попробовал добавить 10000 номеров. Сервер прислал около 200 новых контактов, 4800 номеров, которые не зарегистрированы в TG, и ещё 5000 номеров для повторного запроса.
Вот только повторный запрос естественно ничего не дал — ни один контакт не был обработан.
Я попробовал удалить часть контактов и отправить новый запрос — безрезультатно. Причем те контакты, которые сервер уже обработал до этого, продолжали обрабатываться. А любые другие, включая 5000 изначально необработанных просто игнорировались — сервер их не добавлял.
На следующий день я всё ещё не мог добавлять контакты. Больше не проверял, надоело.
2) @ya. Минимальная длинна юзернейма то от 4, то ли 5 символов. Не 2 уж точно.
В отсутствие гравитационного поля, то есть в состоянии невесомости, закон Архимеда не работает. Космонавты с этим явлением знакомы достаточно хорошо. В частности, в невесомости отсутствует явление (естественной) конвекции, поэтому, например, воздушное охлаждение и вентиляция жилых отсеков космических аппаратов производятся принудительно, вентиляторами.