Вот ощущение что они встроили MitM в дизайн протокола меня активно не покидало и не покидает.

Спасибо за этот update.

Спасибо, возможно когда я искал я не нашел этих ключей через поиск github.

Но это не отменяет исходный вопрос почему именно они.

О, т.е. для каждого приложения ключи могут быть вообще свои?

Как-то это совсем не прозрачно.

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

В текущем дизайне меня не покидает ощущение что man-in-the-middle там есть, и он просто часть его.

Никто не мешает использовать x509 и прочие сертификаты и доверять не всем CA а только например трем:
— Telegram root CA
— Telegram root CA #2
— Telegram root CA #3

Второй на случай если сертификат первого того, ну и третий на случай полного ужаса.

Ибо вся эта инфраструктура она же не только про контейнер для ключей. Она еще про способы распространения отозванных сертификатов.

Там очень много работы, и очень многое сделано что бы было прозрачно и верефицируемо.

И вот прозрачно и верефицируемо это то чего не хватает от telegram

В Linux измерить потребление памяти очень не просто. Я бы сказал не возможно.

Т.е. измерить потребление виртуальной памяти да, можно. Измерить RSS сейчас этого процесса можно.

Но это все погода и вектор )

Но почему именно они?

Т.е. я не нашел ссылки на сайте telegram.org что наша CDN использует вот эти вот ключи.

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

Но и тут авторы решили сделать все иначе.

его придумали в vk еще, как и сервер telegram был «форком» сервера сообщений в vk вроде никто особо не отрицает, хотя и не акцентирует внимание.

Собственно лимит на 1 миллион сообщений у аккаунта там например еще с тех времен ;) Хотя, возможно, они его убрали. Но не уверен.

Но почему именно эти ключи? Почему их нет нигде на сайте telegram? И откуда они вообще берутся? Что бы их получить надо присоединиться к сети telegram и выполнить команду — сервер а дай все ключи которым верить? А почему не может быть main in the middle в этом дизайне например?

Кстати про 2 года вы оптимисты.

Код сервера (то что нам показали как прокси сервер) есть развитие того что выложила эта команда в open source когда была еще в vk.

Сравните например две функции:

github.com/vk-com/kphp-kdb/blob/master/common/crc32.c#L576
github.com/TelegramMessenger/MTProxy/blob/master/common/crc32.c#L945

Это подтверждается, например, хорошей масштабируемостью — ни один другой IM не поддерживает групповые чаты на 200 000 пользователей. И даже на порядок меньшая планка в 20к участников чата является практически недостижимой.

В 2011 году я для tigase (XMPP/Jabber на Java кстати) с commet (HTTP, тогда не было еще web socket) делал proof of concept на больше миллиона активных соединений, с пиковой нагрузкой до 10 миллионов на ноду: catap.ru/blog/2011/12/19/over-1m-open-sockets-linux-node

Latency на нескольких миллионах (простите, не помню сколько, 4-5 или что-то такое) было в районе 200-300 ms.

Сейчас железо стало куда более масштабным, и такое уже не удивляет как бы.

В общем я не вижу какой-то rocket science в том что они делают ;)

Спасибо за интересную статью.

Я хочу ее добавить одним очень интересный вопрос который мне не дает покоя.

В любой из клиентов что я видел имеет вшитый в него набор ключей которым надо верить что они-то надежные. Это несколько ключей. Откуда они взялись это вопрос ибо из документации это не следует никак, и если поискать эти ключи как константу то можно найти что самое первое упоминание их тут: github.com/d0ctrey/telegram-client/commit/b1297677df381e90c1e54515b648b15cf250d0cc

Это Dec 19, 2017 и коммит сделал некий d0ctrey который создал репозиторий с этим коммитом за пару часов до этого коммита.

Почему именно эти ключи? Почему тайминг так хорошо пересекается с временем блокировок с РКН я тоже не знаю.

Вы пропускаете важный момент — когда OOM Killer приходит кого-то убить он считает что root-процессы важнее и стремиться их не трогать!

Т.е. файл мы отдадим, только если он был залит с этим письмом, или не отдадим ничего.

Ого.

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

Т.е. лучше просто дописать что уникальность обеспечивается не только sha1 хешем, но еще тем-то и тем-то и вероятность коллизий есть, но она теоретическая и вообще она вот-такая (и цифру какая она маленькая), а исходя из ограничение на максимальный размер письма/аттача она получается таки равна нулю :)

Спасибо за корректный ответ, просто из статьи сложилось впечатление что вы проверяете только хеш.

в сложном документе, например PDF или картинке, где лишние байты будут игнорироваться :) можно совершить атаку и подобрать мусор что бы два разных (по содержанию отображаемому пользователю) документа имели одинаковый хеш.

Мне кажется правильным как минимум держать размер (в байтах) файла, а лучше использовать две хеш функции для и размер, тем самым сводя вероятность коллизий совсем до минимума.

Например для md5 я с ходу нашел такую очень старую (~10 лет) работу: http://cryptography.hyperlink.cz/md5/MD5_collisions.pdf

Макс, зачем для этого возвращаться? :)

В любом случае мой email ты знаешь ;)

Может люди такие там и есть, не знаю. Но я не там уже более 5 лет :)