Вот попадает устройство, являющееся DHT-узлом в руки того-кого-нельзя-называть. А в этом устройстве куча логинов и парольных хешей.
Тот-кого-нельзя-называть копирует парольную пару и использует её для входа под чужим логином.
И всякие ухищрения, типа динамического соления, не помогают, потому что они затрудняют подбор пароля при перехвате хеша. А здесь ничего не перехватывается а просто задаром получается несолёный хеш.
И чем больше устройств в сети, тем больше вероятность того, что одно из них взломают.
А то нашему Самсунгу узе 15 лет. AVI он нормально воспроизводит, кроме "битых". А вот MKV не все. А медиацентр домосборный, слабенький - не хватает ему мощи "на лету" перекодировать форматы. Начинаются фризы на тяжелых фильмах.
Хочу всеядный, с DLNA и чтобы с веб-интерфейсом. А у LG его нет :( Или я не нашел.
А ведь раньше, до того как продаться мелкомягким, Skype использовал гибридную децентрализованную систему.
Т.е. центральных серверов не было, но некоторые мощные клиенты могли взять на себя функции супернод - координационных узлов. Они выполняли роли STUN-серверов, а при необходимости пропускали через себя трафик других клиентов (TURN).
Так что, распределенные сети мессенджеров - это уже было.
Дык, бутстрап содержит список официальных агрегаторов - резервирование на случай перебоев доступа.
А товарищимайоры делают фейковые агрегаторы (как IKnowWhatYouDownload), чтобы ловить участников поиска (иначе без поиска это уже не DHT-сеть). А при необходимости эти фейковые агрегаторы начинают выдавать пургу, затрудняя или совсем задудосивая поиск).
Вспомнил еще казус, к делу не относящийся, но показательный:
Samsung отказался от поддержки на своих устройствах кодеков DivX/XviD, т.к. по сети распространяется много пиратских фильмов в формате .avi, использующем эти кодеки.
Дык, он, еще когда у нас его мессенджер блочили, заявлял, что готов предоставлять IP и другие данные по обоснованным юридическим запросам. Но ключи может предоставить только железные, т.к. при сквозном шифровании ключи хранятся только у клиентов.
Но спецслужбам (нашим ли, французским, еще чьим-то) этого мало. Они требовали отказа от сквозного шифрования, внедрения бэкдоров и возможности просматривать переписку любого клиента без ведома и согласия Телеги.
Как изначально клиент получает список других участников DHT? А без него, найти их самостоятельно проблематично.
В локалке можно отправить широковещательный запрос на UDP#6881. Но не факт, что кто-то найдется.
Можно пошерстить по списку прошлых сидов/пиров. Но как быть тем, кто скачал первый и единственный торрент с RuTracker, а анонсеры заблочкны и никакого адреса он получить не может?
Говорят, что есть какие-то bootstrap-списки в открытом доступе, содержащие адреса DHT-агрегаторов. Но насколько они актуальны?
Прошу прощения, но "с какой целью интересуетесь" относилось не к Вам, а к пиру, приславшего DHT-запрос. Мол, цель-то одна - скачивание.
Но вот сам факт запроса вовсе не свидетельствует о том, что такая раздача у запрашиваемого клиента есть.
Разумеется, не свидетельствует. Но DHT работает по принципу расширяющегося поиска. Не нашлась раздача среди ближайшего окружения - найдется на следующем круге поиска. Или на следующем. По "теории шести рукопожатий", если пиринговая сеть связная, то найдется всё.
Торренты никто ни у кого не запрашивает. Пир каким-то образом (каким именно - мне не совсем понятно, т.к. у разных клиентов разный порт, на котором они слушают запросы DHT) спрашивает у потенциальных сидов из какого-то списка, нет ли у них раздачи с заданным хешем. Если нет, то зона опроса расширяется. Когда раздача с заданным хешем найдена, она начинает скачиваться. Но при этом возможны коллизии - разные раздачи с одинаковым хешем. На этот случай контролируются хеши всех скачанных частей. Если от кого-то приходят фейковые части, то этот сид исключается, т.к. он раздает не то, что нам нужно.
Т.е. запрашивается не собственно раздача, а раздача с определенным хешем. А задача агрегатора по этому хешу определить, какой раздаче он соответствует.
Ну и если кто-то запрашивает хеш раздачи, то не для того, чтобы на цифирки полюбоваться, а с целью эту раздачу скачать.
Ну или через "peer exchange". Но это не самостоятельный протокол, а вспомогательная функция для ускорения получения адресов:портов пиров, от пира/сида, который получил это раньше по DHT или с анонсера.
Как мне кажется, PEX предназначен для ускорения поиска новых пиров, а не сидов - сиды и так более-менее известны.
Как это нет вероятности?
Вот попадает устройство, являющееся DHT-узлом в руки того-кого-нельзя-называть. А в этом устройстве куча логинов и парольных хешей.
Тот-кого-нельзя-называть копирует парольную пару и использует её для входа под чужим логином.
И всякие ухищрения, типа динамического соления, не помогают, потому что они затрудняют подбор пароля при перехвате хеша. А здесь ничего не перехватывается а просто задаром получается несолёный хеш.
И чем больше устройств в сети, тем больше вероятность того, что одно из них взломают.
Читаю заголовок ...
Так обнаружение было с использованием ML тли атака?
А теперь LG как?
А то нашему Самсунгу узе 15 лет. AVI он нормально воспроизводит, кроме "битых". А вот MKV не все. А медиацентр домосборный, слабенький - не хватает ему мощи "на лету" перекодировать форматы. Начинаются фризы на тяжелых фильмах.
Хочу всеядный, с DLNA и чтобы с веб-интерфейсом. А у LG его нет :( Или я не нашел.
Это не аутентификация. Это просто сеансовая регистрация.
Для аутентификации логин (номер) и хеш пароля должен где-то храниться. Но не на сервере, т.е. сеть одноранговая.
Т.е. хранение должно быть так же распределенным и с поддержанием целостности, даже если большая часть клиентов выйдет из неё.
В то же время, чем больше узлов хранит аутентификационную пару пользователя, тем выше вероятность компрометации.
Кажется, была здесь статья, как реализовать аутентификацию в децентрализованных сетях. Но вряд ли найду ...
"Поваренную книгу" читал. Забавно. Но в научно-популярных книгах по химии, изданных в 60-х годах, еще и не такое можно было найти :D
Стоп! ...
А ведь раньше, до того как продаться мелкомягким, Skype использовал гибридную децентрализованную систему.
Т.е. центральных серверов не было, но некоторые мощные клиенты могли взять на себя функции супернод - координационных узлов. Они выполняли роли STUN-серверов, а при необходимости пропускали через себя трафик других клиентов (TURN).
Так что, распределенные сети мессенджеров - это уже было.
P.S. Хотя насчет STUN на супернодах я не уверен.
Дык, бутстрап содержит список официальных агрегаторов - резервирование на случай перебоев доступа.
А товарищимайоры делают фейковые агрегаторы (как IKnowWhatYouDownload), чтобы ловить участников поиска (иначе без поиска это уже не DHT-сеть). А при необходимости эти фейковые агрегаторы начинают выдавать пургу, затрудняя или совсем задудосивая поиск).
Не китайцами одними ... Другие южнокорейцы (LG, Hyundai) не спешат перенимать столь бесценный опыт.
Да, мессенджеры будут прижимать жестко.
И вот тут такие агрегаторы-ловушки будут задействованы на полную. Будут фиксировать попытки использования этой сети.
И это не считая того, что полицейские будут просить "предъявить телефончик" на предмет проверки установленного приложения.
Вспомнил еще казус, к делу не относящийся, но показательный:
Samsung отказался от поддержки на своих устройствах кодеков DivX/XviD, т.к. по сети распространяется много пиратских фильмов в формате .avi, использующем эти кодеки.
Дык, он, еще когда у нас его мессенджер блочили, заявлял, что готов предоставлять IP и другие данные по обоснованным юридическим запросам. Но ключи может предоставить только железные, т.к. при сквозном шифровании ключи хранятся только у клиентов.
Но спецслужбам (нашим ли, французским, еще чьим-то) этого мало. Они требовали отказа от сквозного шифрования, внедрения бэкдоров и возможности просматривать переписку любого клиента без ведома и согласия Телеги.
Формально Дуров тоже не принимал участия в распространении детского порно, сделках с запрещенными веществами и террористических атаках ...
Del
Что-то подобное я предполагал.
Но этот подход чувствителен к блокировкам. Если блочат анонсеры, то кто мешает блочить и такие DHT-агрегаторы?
У меня вот какие непонятки:
Как изначально клиент получает список других участников DHT? А без него, найти их самостоятельно проблематично.
В локалке можно отправить широковещательный запрос на UDP#6881. Но не факт, что кто-то найдется.
Можно пошерстить по списку прошлых сидов/пиров. Но как быть тем, кто скачал первый и единственный торрент с RuTracker, а анонсеры заблочкны и никакого адреса он получить не может?
Говорят, что есть какие-то bootstrap-списки в открытом доступе, содержащие адреса DHT-агрегаторов. Но насколько они актуальны?
Прошу прощения, но "с какой целью интересуетесь" относилось не к Вам, а к пиру, приславшего DHT-запрос. Мол, цель-то одна - скачивание.
Разумеется, не свидетельствует. Но DHT работает по принципу расширяющегося поиска. Не нашлась раздача среди ближайшего окружения - найдется на следующем круге поиска. Или на следующем. По "теории шести рукопожатий", если пиринговая сеть связная, то найдется всё.
Что-то это какой-то бешеный заяц - меняет направление на противоположное.
Но если заяц еще способен резко затормозить или сменить направление движения, то ЛА так не может:
Даже если бы у ЛА был реверсивный двигатель - резко затормозить, развернуться и опять врубить тягу ему не дано.
Поэтому, скорость может изменяться очень незначительно. И то за счет повышенного сопротивления воздуха на маневре.
А вот направление может изменяться. Но не сильно и не мгновенно, а по дуге с ограничением по минимальному радиусу.
Дык, "а с какой целью интересуетесь"?
В смысле, какая еще может быть цель запроса наличия раздачи с заданным хешем, кроме желания скачать эту раздачу?
На самом деле всё происходит не так:
Торренты никто ни у кого не запрашивает. Пир каким-то образом (каким именно - мне не совсем понятно, т.к. у разных клиентов разный порт, на котором они слушают запросы DHT) спрашивает у потенциальных сидов из какого-то списка, нет ли у них раздачи с заданным хешем. Если нет, то зона опроса расширяется. Когда раздача с заданным хешем найдена, она начинает скачиваться. Но при этом возможны коллизии - разные раздачи с одинаковым хешем. На этот случай контролируются хеши всех скачанных частей. Если от кого-то приходят фейковые части, то этот сид исключается, т.к. он раздает не то, что нам нужно.
Т.е. запрашивается не собственно раздача, а раздача с определенным хешем. А задача агрегатора по этому хешу определить, какой раздаче он соответствует.
Ну и если кто-то запрашивает хеш раздачи, то не для того, чтобы на цифирки полюбоваться, а с целью эту раздачу скачать.
Через DHT, вестимо.
Ну или через "peer exchange". Но это не самостоятельный протокол, а вспомогательная функция для ускорения получения адресов:портов пиров, от пира/сида, который получил это раньше по DHT или с анонсера.
Как мне кажется, PEX предназначен для ускорения поиска новых пиров, а не сидов - сиды и так более-менее известны.