Никто не мешает использовать x509 и прочие сертификаты и доверять не всем CA а только например трем:
— Telegram root CA
— Telegram root CA #2
— Telegram root CA #3
Второй на случай если сертификат первого того, ну и третий на случай полного ужаса.
Ибо вся эта инфраструктура она же не только про контейнер для ключей. Она еще про способы распространения отозванных сертификатов.
Там очень много работы, и очень многое сделано что бы было прозрачно и верефицируемо.
И вот прозрачно и верефицируемо это то чего не хватает от telegram
Но почему именно эти ключи? Почему их нет нигде на сайте telegram? И откуда они вообще берутся? Что бы их получить надо присоединиться к сети telegram и выполнить команду — сервер а дай все ключи которым верить? А почему не может быть main in the middle в этом дизайне например?
Это подтверждается, например, хорошей масштабируемостью — ни один другой 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 который создал репозиторий с этим коммитом за пару часов до этого коммита.
Почему именно эти ключи? Почему тайминг так хорошо пересекается с временем блокировок с РКН я тоже не знаю.
да, это было бы очень полезно и сняло бы вопросы подобные моим, просто сейчас создается ложное впечатление что тут большие проблемы.
Т.е. лучше просто дописать что уникальность обеспечивается не только sha1 хешем, но еще тем-то и тем-то и вероятность коллизий есть, но она теоретическая и вообще она вот-такая (и цифру какая она маленькая), а исходя из ограничение на максимальный размер письма/аттача она получается таки равна нулю :)
в сложном документе, например PDF или картинке, где лишние байты будут игнорироваться :) можно совершить атаку и подобрать мусор что бы два разных (по содержанию отображаемому пользователю) документа имели одинаковый хеш.
Мне кажется правильным как минимум держать размер (в байтах) файла, а лучше использовать две хеш функции для и размер, тем самым сводя вероятность коллизий совсем до минимума.
Спасибо за этот update.
Но это не отменяет исходный вопрос почему именно они.
Как-то это совсем не прозрачно.
В текущем дизайне меня не покидает ощущение что man-in-the-middle там есть, и он просто часть его.
— Telegram root CA
— Telegram root CA #2
— Telegram root CA #3
Второй на случай если сертификат первого того, ну и третий на случай полного ужаса.
Ибо вся эта инфраструктура она же не только про контейнер для ключей. Она еще про способы распространения отозванных сертификатов.
Там очень много работы, и очень многое сделано что бы было прозрачно и верефицируемо.
И вот прозрачно и верефицируемо это то чего не хватает от telegram
Т.е. измерить потребление виртуальной памяти да, можно. Измерить RSS сейчас этого процесса можно.
Но это все погода и вектор )
Т.е. я не нашел ссылки на сайте telegram.org что наша CDN использует вот эти вот ключи.
Кстати, внутри обычного контейнера c сертификатом кроме ключей существует еще масса мета-информации которая делает валидацию значительно проще.
Но и тут авторы решили сделать все иначе.
Собственно лимит на 1 миллион сообщений у аккаунта там например еще с тех времен ;) Хотя, возможно, они его убрали. Но не уверен.
Код сервера (то что нам показали как прокси сервер) есть развитие того что выложила эта команда в 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
В 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 который создал репозиторий с этим коммитом за пару часов до этого коммита.
Почему именно эти ключи? Почему тайминг так хорошо пересекается с временем блокировок с РКН я тоже не знаю.
Ого.
Т.е. лучше просто дописать что уникальность обеспечивается не только sha1 хешем, но еще тем-то и тем-то и вероятность коллизий есть, но она теоретическая и вообще она вот-такая (и цифру какая она маленькая), а исходя из ограничение на максимальный размер письма/аттача она получается таки равна нулю :)
:)
Но я согласен что если начать считать стоимость нахождения этой коллизии то это на amazon ec2, то это будет пара сотен тысяч долларов.
Мне кажется правильным как минимум держать размер (в байтах) файла, а лучше использовать две хеш функции для и размер, тем самым сводя вероятность коллизий совсем до минимума.
Например для md5 я с ходу нашел такую очень старую (~10 лет) работу: http://cryptography.hyperlink.cz/md5/MD5_collisions.pdf
В любом случае мой email ты знаешь ;)