[Dan]

https://coub.com/view/16ufsk

Кто умеет кубы выкладывать - поправьте плиз )))

[Пэтро]

Дед Мороз, Погуглите Китайская печатная машинка

[_sv_]

Advoc@te (26 апреля 2018 - 15:20) писал:

ФАПСИ ликвидирован в 2003 году.

Надо же. Я где-то в нулевых сертифцитировал оборудование, реализущие ГОСТ шифрование. Надо будет посмотреть кто теперь этим занимается...

Сообщение отредактировал _sv_: 27 апреля 2018 - 08:44

[_sv_]

Инквизитор (26 апреля 2018 - 15:38) писал:

значит, либо провайдер/владелец хранит вместе с перепиской и ключи, либо ключ один на всех, либо есть способ обойтись вообще без ключа.

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

В таком случае вы правы. Только два уточнения:

Если все реализовать честно, то выполнить требования российского законодательства не получится теоретически. Ни провайдеры, ни серверы не имеют затребованных данных. Не "не сохраняют", а вообще не имеют их. Ключи для расшифровки есть только у тех, кто участвует в сессии. А трафик не обязан идти через сервер.

Не знаю деталей реализации Телеграм, но Дуров может быть не в состоянии выполнить требования в принципе.

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

А так да - в целом вы правы.

[GerinG]

В можно вопрос от криптодилетанта? А на чем основана информация о том, что Паша не имеет доступа к ключам и остальному? Он сам сказал?

[_sv_]

GerinG (27 апреля 2018 - 07:23) писал:

А на чем основана информация о том, что Паша не имеет доступа к ключам и остальному?

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

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

Дело в том, что надежных криптографических решений раз, два и обчелся. Получается, что достаточно заметить в коде специфичную последовательность команд и можно сразу сказать "похоже дело труба". Остается лишь выяснить тонкие детали реализации. Тут правда целый вагон вариантов - генерируются ли слабые ключи, есть ли шансы переупорядочить поток данных, и т.д. Но в целом предварительный анализ происходит программным анализатором, а не руками. Ну и ответ на вопрос "что там у Дурова" получают в течении 15 минут после выхода новой версии программы.

[Пэтро]

Исходники клиента вроде открыты.

[MedicusAmicus]

А вот исходники сервера - нет.
И, будь они опубликованы - не факт, что именно они крутятся на боевых серверах.

[Инквизитор]

_sv_ сказал:

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

Ну, собственно, предложение шифровать самим клиентам и было в контексте противодействия передаче личных данных пользователей представителями провайдера/владельца третьей стороне.
И, понятно, речь не о самопальных "пляшущих человечках", а о современных годных алгоритмах, таких, как задействованные в троянах-шифровальщиках.

_sv_ сказал:

Если все реализовать честно, то выполнить требования российского законодательства не получится теоретически. Ни провайдеры, ни серверы не имеют затребованных данных. Не "не сохраняют", а вообще не имеют их. Ключи для расшифровки есть только у тех, кто участвует в сессии. А трафик не обязан идти через сервер.

Вот тут-то и собака порылась.
С одной стороны - вполне возможно, что имеют - где-то же хранится переписка, через что-то же она синхронизируется с разными гаджетами. Другой вопрос, что она может быть зашифрована персональными ключами конкретных пользователей, которые на серверах не хранятся. Кстати, как при таком раскладе шифруются многопользовательские конференции, ума не приложу, разве что имеются уникально зашифрованные копии у каждого участника =)

[KillerSerg]

MedicusAmicus сказал:

А вот исходники сервера - нет.
И, будь они опубликованы - не факт, что именно они крутятся на боевых серверах.

В данном случае неважно что на сервере. Есть есть открытый код клиента, есть протокол, то аудит кода покажет что в случае e2e уходит зашифрованый контент, расшифровать который может только получатель

https://core.telegra...c10049a7190694f

Инквизитор сказал:

Кстати, как при таком раскладе шифруются многопользовательские конференции, ума не приложу

Многопользовательские не шифруются

[Пакость]

А точнее - по соединению (которое может быть как открытым, так и TLS) идет шифрованный поток данных E2E.
Как вы представляете себе man-in-the-middle в таком ключе?
Если понимать буквально по максимуму - у нас SSL (и т. п.) туннель по которому мы гоним (допустим таки ведомый) E2E трафик, причём отдельно обмен открытыми ключами установки E2E сессии может происходить как-то там и не обязательно через этот туннель - тогда лично я - вообще никак - возникает сильно большой объём однородного случайного характера данных, которые надо перелопатить чтоб хоть концы отыскать.
А с другой стороны, вполне возможно гоню. Я таки этой самой "Телегой" ни разу не пользовался и подробностей её работы на личном опыте не знаю, только из того что по интернетам писано. Так что в спор не лезу.

https://core.telegra...c10049a7190694f
Картинка хороша, но таки вот мне до конца оставляет открытым вопрос: "Secret Chat key" в конце концов каким образом доставляется собеседникам, открытым или закрытым?

Сообщение отредактировал Пакость: 27 апреля 2018 - 13:40

[KillerSerg]

Пакость сказал:

Картинка хороша, но таки вот мне до конца оставляет открытым вопрос

Изучайте
https://core.telegra.../api/end-to-end


Хотя и по одной картинке ясно, что "Secret Chat key" не передается.



Зы - желающим доказать уязвимость протокола MTProto гарантировались премии в 200к$ и 300к$. Достаточно серьезные призы для bug bounty программы.
https://telegram.org/crypto_contest
https://telegram.org...g/cryptocontest

[KillerSerg]

Очередной обосрамс от РКН. Пусть и на пару часов по продолжительности, но факт

Цитата

В числе заблокированных:

IP Домены на IP
31.13.92.14, 157.240.20.15, 157.240.20.19... facebook.com, m.facebook.com, messenger.com
13.107.21.200 bing.com, m.bing.com, ...
104.244.42.131 twitter.com
104.244.42.5 t.co
2.17.140.47 addthis.com
104.16.18.96 whatismyipaddress.com
37.79.247.8 rnis66.ru *
151.101.84.84 pinterest.com
194.190.168.1 ntp.ix.ru (сервер времени на MSK-IX)
217.20.155.10 odnoklassniki.ru, ok.ru, tamtam.chat
195.128.157.74 mail.dom.gosuslugi.ru, mir24.tv
95.213.222.13, 95.213.222.9 smi2.ru
87.240.129.133 vk.com
213.180.204.90, 77.88.21.90 mc.yandex.ru

Цитата

Сегодня ночью в реестре Роскомнадзора внезапно появилось пять IP-адресов «Яндекса». Наши адреса пробыли в реестре около двух часов, на текущий момент IP-адреса из этого списка пропали. Дежурная смена наших технических специалистов всю ночь оперативно мониторила ситуацию и поддерживала полную доступность наших сервисов. Мы ждём разъяснений Роскомнадзора.

Попытка заблокировать Telegram в России неожиданно стала ударом по всему рунету. Блокировка коснулась не только мессенджера — пострадали многие ресурсы и их пользователи. Мы не считаем эту ситуацию нормальной.

Российский рынок может развиваться только в условиях открытой конкуренции. Ограничение доступа к глобальным и российским интернет-сервисам навредит прежде всего рунету. Именно несвободу и отсутствие выбора для пользователей мы считаем самым опасным последствием блокировок.

Отсутствие открытости и конкуренции на внутреннем рынке не только приводит к падению качества продуктов, от чего страдают пользователи, но и лишает страну возможности технологической конкуренции на мировых рынках в будущем.
Очир Манджиков
директор по связям с общественностью «Яндекса»

Обсуждение на хабре https://habr.com/post/354484/
там предполагают причину

Цитата

Как такое могло произойти?

Во всей этой ситуации примечателен не сам факт блокировки — тут ничего нового, а возможные причины появления именно такого списка заблокированных IP.

Давайте представим что вы — РКН, и вам поручили заблокировать Телеграм. Откуда вы, РКН, может взять IP для блокировки Телеграма? Само очевидное решение было бы где-то перехватывать трафик Телеграма, брать оттуда IP, к которым он пытается подсоедениться, и отправлять в блокировку. Для этого достаточно простейшего правила вида iptables -j LOG и скрипта из tail -f, grep и xargs для вызова программы добавления в блок-лист.

Перехватывать трафик РКН было бы оптимально с мобильного приложения, так что самым очевидным решением было бы настроить Wi-Fi точку доступа, подключенную через подконтрольный роутер, а к ней подключить телефон, на котором будет открыт Телеграм. Так любые попытки подсоединения к серверам телеграма будут отслеживаться, адреса — блокироваться.

Если посмотреть на список заблокированных, то бросается в глаза счётчики и рекламные сети. Такое чувство что кто-то с устройства, предназначенного для блокировки Телеграма, зашел в обычный интернет и пошел по разным сайтам. Скорее всего это было какое-то другое устройство, которое по случаю подключилось к той же Wi-Fi сети. Судя по присутствию сайта whatismyipaddress.com в списке заблокированных, это мог быть даже не сотрудник РКН, а какой-то посторонний человек, по случаю нашедший открытую Wi-Fi сеть или подобравший пароль. Впрочем, бритва Хэнлона подсказывает что от сотрудников РКН можно ожидать и не такого.

О чём это говорит?

Если раньше владелец заблокированного домена мог добавить в блок-лист произвольные IP адреса заменой A записи, то сейчас ситуация выходит на совершенно новый уровень. Просто представьте себе: что если Телеграм будет пытаться открыть не свои сервера, а просто обратится к IP топовых сайтов? IP объектов инфраструктуры?.. Эти все IP по логике Роскомнадзора быстренько попадут в список под блокировку, а затем также быстро в выгрузку провайдерам.

Это означает что владелец заблокированного приложения, вроде того же Телеграма или Zello, может не просто заблокировать какие-то отдельные IP подобно владельцам сайтов, а потенциально получает возможность заблокировать вообще всё что ему захочется.

Из этой возможности естественно следует появление белого списка адресов, которые никогда нельзя заблокировать. Можно предположить такой список уже есть, ведь IP сервера, откуда провайдеры берут новые данные, уже попадал в выгрузку с понятными последствиями, но этому списку явно есть куда расти (сообщают что там было порядка 500 IP). Само наличие такого полного белого списка влечет за собой возможность в какой-то момент отключить всё, кроме белого списка. Это не может радовать.

[Пэтро]

А могли со серьезной миной и оставить эти адреса в списке блокированных, а чо?

[_sv_]

Инквизитор (27 апреля 2018 - 12:53) писал:

она может быть зашифрована ...

Конечно - ключи не хранятся. Они вообще нигде не хранятся кроме конечных "потребителей".

Инквизитор (27 апреля 2018 - 12:53) писал:

как при таком раскладе шифруются многопользовательские конференции.

В Телеграм? Или принципиально?
Ответа на первый вопрос - не знаю. А в принципе ничего сложного в этом нет. Просто один из участников конференции становится ведущим и перешифровывает остальным весь поток...

[_sv_]

Пакость (27 апреля 2018 - 13:25) писал:

мне до конца оставляет открытым вопрос: "Secret Chat key" каким образом доставляется собеседникам, открытым или закрытым?

Он вообще не доставляется. Обе стороны генерируют его синхронно на этапе установления соединения. Каждая из сторон вычисляет полу-результат и передает его по открытым каналам. Обратная сторона принимает чужой полу-результат и производит с ним завершающие вычисления. В конце обе стороны получат одинаковое число. Его и будут использовать как сессионный ключ.

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

[_sv_]

KillerSerg (27 апреля 2018 - 13:18) писал:

Многопользовательские не шифруются

Почему? Решили, что не надо?

[Rumlin]

_sv_ сказал:

Почему? Решили, что не надо?

а может следующий шаг после раскрутки популярности, но уже платно.

[KillerSerg]

_sv_ сказал:

Почему? Решили, что не надо?

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

Но скорей всего посчитали не нужным концептуально, смысла к секретных чатах на троих нет. По принципу "то что знают трое - знают все"
Одно дело тет-а-тет, с уверенностью что сообщение не перехватили и содержимое знает только два собеседника.
И совсем другое когда чат на троих. Скажем содержимое этого чата утекло. В себе самом есть уверенность. Но кто из двух оставшихся собеседников слил беседу?

[_sv_]

KillerSerg (27 апреля 2018 - 18:52) писал:

много архитектурных сложностей...
посчитали не нужным концептуально...

Понятно. С фразой "сложности" не соглашусь, но это и не важно.
То, что такое посчитали не нужным - мне понятно. Спасибо.