Comments 70
А что мешает послать на трекер-анонсер сообщение, что являешься полным сидом раздачи с данным хешем?
Тогда трекер будет сообщать ваш IP:port всем жаждущим пирам. Они будут стучаться на этот порт. Остается только их регистрировать.
И DHT при этом не нужен.
Формально, так вы получите список скачивающих, а не список раздающих
да, но, большинство скачивающих - раздающие. Нет нет болшьой разницы раздаю я ведьмака или какой-то процент от нескольких файлов игры. хотя интересно что на этот счёт думают юристы..
В том и дело, что у пользователя может быть модифициированный клиент, в котором отдача обрезана наглухо. А если он не раздал ни байта, за что же его прессовать?
или какой-то процент от нескольких файлов игры. хотя интересно что на этот счёт думают юристы
Ваш IP-адрес может появиться в DHT-сети без вашего ведома, если один из узлов захочет нарушить протокол и просто от балды вбросить фейковые данные (все узлы максимально друг другу доверяют).
Поэтому наличие IP в DHT не может быть доказательством. Тут или обыск/обнаружение файлов на ПК, либо чистосердечное.
Так список раздающих можно получить с трекера еще проще - при помощи scrape-запроса.
Правда, насколько я помню, трекер весь список сидов сразу не выдаёт - только 50 штук за раз.
Раздача ведь и без анонсера может быть?
Как тогда пиры узнают друг о друге? аннонсер эт свезующее звено.
Через DHT, вестимо.
Ну или через "peer exchange". Но это не самостоятельный протокол, а вспомогательная функция для ускорения получения адресов:портов пиров, от пира/сида, который получил это раньше по DHT или с анонсера.
Как мне кажется, PEX предназначен для ускорения поиска новых пиров, а не сидов - сиды и так более-менее известны.
Документации и гайдов по работе с DHT мало, а готового кода я не нашел.
В качестве отправной точки,наверное, можно изучать код существующих поисковиков по DHT.
https://github.com/Olament/gDHT
https://github.com/felix/dhtsearch
Проблема конкретно IKnowWhatYouDownload в том, что он протоколирует вообще любой обмен DHT с торрент-клиентом, сидящим на каком-то адресе, и в результате включает в свою табличку торренты, которые этот клиент никогда не загружал и даже не искал по DHT. Отличить их от действительно загруженных можно по разнице между временем "Первый раз" и "Последний раз" (первая и вторая колонки таблицы). Якобы загруженные торренты, которые, на самом деле, клиентом никогда не загружались, имеют эту разницу равной нулю.
Если я правильно понимаю, такое происходит, когда кто-то с помощью DHT запрашивает торрент-клиента, висящего на определённом адресе, нет ли у него некоего торрента, а IKnowWhatYouDownload, по непонятной причине, засчитывает этот запрос в качестве попытки скачивания клиентом этого самого торрента. А потом, благодаря придуркам, организовавшим этот самый IKnowWhatYouDownload, несчастным владельцам торрент-боксов придётся долго доказывать разного рода неравнодушным социально-активным гражданам, что они, владельцы, никогда в жизни не интересовались ни CP, ни зоофилией, и никогда ничего подобного не скачивали, безуспешно пытаясь при этом собрать с пола свои выбитые зубы сломанными пальцами рук.
Временный способ обезопасить себя — перейти на IPv6. Активность торрент-клиентов с адресами IPv6 IKnowWhatYouDownload пока, к счастью, не протоколирует.
На самом деле всё происходит не так:
Торренты никто ни у кого не запрашивает. Пир каким-то образом (каким именно - мне не совсем понятно, т.к. у разных клиентов разный порт, на котором они слушают запросы DHT) спрашивает у потенциальных сидов из какого-то списка, нет ли у них раздачи с заданным хешем. Если нет, то зона опроса расширяется. Когда раздача с заданным хешем найдена, она начинает скачиваться. Но при этом возможны коллизии - разные раздачи с одинаковым хешем. На этот случай контролируются хеши всех скачанных частей. Если от кого-то приходят фейковые части, то этот сид исключается, т.к. он раздает не то, что нам нужно.
Т.е. запрашивается не собственно раздача, а раздача с определенным хешем. А задача агрегатора по этому хешу определить, какой раздаче он соответствует.
Ну и если кто-то запрашивает хеш раздачи, то не для того, чтобы на цифирки полюбоваться, а с целью эту раздачу скачать.
На самом деле всё происходит не так:
Что, прямо всё? А если заменить во втором абзаце моего сообщения слово «торрент» на «раздача с определённым инфохэшем», изложенные в нём факты станут соответствовать действительности?
Торренты никто ни у кого не запрашивает.
Признаю, был неправ. Запрашивается наличие раздачи с определённым инфохэшем.
Т.е. запрашивается не собственно раздача, а раздача с определенным хешем. А задача агрегатора по этому хешу определить, какой раздаче он соответствует.
Ну так проблема, про которую я писал, состоит в том, что IKnowWhatYouDownload, по совершенно непонятной лично мне причине, засчитывает запрос к торрент-клиенту с помощью DHT о наличии у него раздачи с определённым инфохэшем как раздачу/скачивание данным клиентом торрента с данным инфохэшем. Надеюсь, в этот раз я корректно выразил свою мысль?
Дык, "а с какой целью интересуетесь"?
В смысле, какая еще может быть цель запроса наличия раздачи с заданным хешем, кроме желания скачать эту раздачу?
Дык, "а с какой целью интересуетесь"?
С целью понять, на основании чего Вы утверждаете, что в моём исходном сообщении всё не так. Вот против «всё» у меня есть возражения.
В смысле, какая еще может быть цель запроса наличия раздачи с заданным хешем, кроме желания скачать эту раздачу?
Ну я прямо даже не знаю, каким ещё способом донести мою мысль.
Несомненно, о наличии раздачи с определённым хэшем запрашивают с целью её скачать. Но вот сам факт запроса вовсе не свидетельствует о том, что такая раздача у запрашиваемого клиента есть. Спрашивают всех, авось у кого-нибудь нужная раздача найдётся. До этого — мне всё ясно и понятно. Но вот потом, откуда ни возьмись, вылезают странные люди с IKnowWhatYouDownload, которые тщательно протоколируют все эти запросы, слушая DHT, а затем принимаются безосновательно утверждать, что если у кого-то запрашивали о наличии некоей раздачи, значит она у него точно есть. Но ведь это же не так! Как они вообще могут утверждать, что у какого-то стороннего торрент-клиента есть определённая раздача, если они не имеют технической возможности перехватить и запротоколировать ответы этого клиента на адресованные ему запросы, которые тот отправляет запросившему его юникастом? Или они сами долбятся с запросами ко всем клиентам, о которых они знают из DHT, по всем известным им инфохэшам? А если так, то зачем они врут о том, что у клиентов есть определённые раздачи, если в их же таблице львиная доля строк имеют одинаковые значения времени начала и окончания скачивания/раздачи? Как, по их мнению, клиент смог всосать/раздать несколько десятков гигабайт за ноль секунд?
С целью понять ...
Прошу прощения, но "с какой целью интересуетесь" относилось не к Вам, а к пиру, приславшего DHT-запрос. Мол, цель-то одна - скачивание.
Но вот сам факт запроса вовсе не свидетельствует о том, что такая раздача у запрашиваемого клиента есть.
Разумеется, не свидетельствует. Но DHT работает по принципу расширяющегося поиска. Не нашлась раздача среди ближайшего окружения - найдется на следующем круге поиска. Или на следующем. По "теории шести рукопожатий", если пиринговая сеть связная, то найдется всё.
засчитывает запрос к торрент-клиенту с помощью DHT о наличии у него раздачи с определённым инфохэшем
Вы какую-то фантастику выдумываете. Сервис мониторинга не может видеть трафик между двумя пирами, а запрос какого-то пира никому дальше не проксируется. Максимум, один пир может сказать другому "у меня нет, но я знаю, что IP:PORT это раздаёт или IP:PORT знает, кто раздаёт" (и вот тут можно подставить этот IP:PORT на любое CP).
Посылает запрос в DHT-сеть на поиск сидеров.
Отлично, и что он получает в ответ, и от кого именно в DHT-сети? И почему этот замечательный ответ содержит инфохэши, которые клиенты не раздавали не то, что во время на время формирования ответа, а вообще никогда?
У меня, например, статический адрес, роутер всегда включен, торрент-бокс, соответственно, тоже, в выдаче IKnowWhatYouDownload присутствует куча закачек/раздач, каждая из которых длилась ровно 0с, и их вообще нет в протоколах торрент-клиента, это вот что? Откуда они берутся? За счёт чего сеть DHT связала эти инфохэши с моим адресом? Не логично ли будет предположить, что это кто-то запрашивал либо сеть DHT, либо непосредственно моего торрент-клиента о наличии у него раздачи с этими инфохэшами, и был либо послан, либо вообще не получил ответа?
Вообще, можно ли запросить какого-либо конкретного члена сети DHT о наличии/отсутствии у него определённой раздачи по её инфохэшу так, чтобы об этом узнала все остальные члены этой сети?
Отлично, и что он получает в ответ, и от кого именно в DHT-сети?
От кого именно - кого спрашивал, от тех и получает.
Кого спрашивает - на первой итерации тех, чей ID наиболее близко к искомому инфохешу. (Публикация в DHT устроена так, что при старте раздачи клиент рассылает "у меня есть раздача" тем пирам, чей ID близок к хешу раздачи. Они это запоминают. Соответственно, другой пир, который ищет раздачу, так и находит ноды, у кого спрашивать).
в выдаче IKnowWhatYouDownload присутствует куча закачек/раздач
Баг сервиса?
Вообще, можно ли запросить какого-либо конкретного члена сети DHT о наличии/отсутствии у него определённой раздачи по её инфохэшу так, чтобы об этом узнала все остальные члены этой сети?
Нет. Зачем пересылать инфу "кто о чём спрашивал", задачи сети это никак не решает.
У меня вот какие непонятки:
Как изначально клиент получает список других участников DHT? А без него, найти их самостоятельно проблематично.
В локалке можно отправить широковещательный запрос на UDP#6881. Но не факт, что кто-то найдется.
Можно пошерстить по списку прошлых сидов/пиров. Но как быть тем, кто скачал первый и единственный торрент с RuTracker, а анонсеры заблочкны и никакого адреса он получить не может?
Говорят, что есть какие-то bootstrap-списки в открытом доступе, содержащие адреса DHT-агрегаторов. Но насколько они актуальны?
Как правило, создатели крупных клиентов держат сервер (например μTorrent - router.utorrent.com), к которому подключаются клиенты при старте, сливают туда свой IP:PORT и в обмен получают пачку актуальных DHT-пиров.
Что-то подобное я предполагал.
Но этот подход чувствителен к блокировкам. Если блочат анонсеры, то кто мешает блочить и такие DHT-агрегаторы?
Нет формальной причины, за что блочить bootstrap-сервер. Он же никак не связан с нарушением авторских прав. То есть, под блокировку должен попасть не трекер (rutracker, nnm-club), а клиент (μTorrent, bittorrent).
Формально Дуров тоже не принимал участия в распространении детского порно, сделках с запрещенными веществами и террористических атаках ...
Но сначала Дурову слали запросы: "это удоли", "на этого дай контакты (ip/телефон)". Авторам торрент-клиентов ничего такого не прилетает.
Дык, он, еще когда у нас его мессенджер блочили, заявлял, что готов предоставлять IP и другие данные по обоснованным юридическим запросам. Но ключи может предоставить только железные, т.к. при сквозном шифровании ключи хранятся только у клиентов.
Но спецслужбам (нашим ли, французским, еще чьим-то) этого мало. Они требовали отказа от сквозного шифрования, внедрения бэкдоров и возможности просматривать переписку любого клиента без ведома и согласия Телеги.
ТГ централизованная система, а DHT-сеть убить очень сложно. Авторы клиентов просто добавят опцию "ввести пира вручную". Я, и ещё 10 человек укажут свой IP:PORT например в подписи в той же телеге, или в профиле на Хабре, ну или просто будут скидывать периодически в любой форум/чат. И любой, кто запускает клиент, просто введёт этот IP вручную и через него вытащит всю сеть.
Эх, вот бы такой неубиваемый DHT-P2P мессенджер. Но я думаю, власти будут его жёстко душить в зародыше, пока он не вырос в нечно непотопляемое.
Да, мессенджеры будут прижимать жестко.
И вот тут такие агрегаторы-ловушки будут задействованы на полную. Будут фиксировать попытки использования этой сети.
И это не считая того, что полицейские будут просить "предъявить телефончик" на предмет проверки установленного приложения.
агрегаторы-ловушки будут задействованы на полную
Для мессенджера на надо делать агрегатор. Только ручной бутстрап. Адрес получаешь от товарища с активной сессией.
"предъявить телефончик" на предмет проверки установленного приложения
Приложение не нужно. Из-за развития удалёнки, браузеры могут и звонить, и камеру юзать, в-общем полноценное приложение можно сделать в web. Закрыл браузер с опцией "не сохранять сессию" - и всё стёрлось.
Чтобы не могли заблочить стартовую страницу, сделать его serverless - то есть, грузится статика, js-скрипт мегабайт на 50, и дальше сервер не нужен. А этот js легко копируется куда угодно, хостится на любой CDN, хоть на Yandex.Disk, хоть статика в github releases, запарятся вычишать.
Жаль конечно, что всё это неудобно/непонятно для простых пользователей, а значит - не взлетит.
Для мессенджера на надо делать агрегатор.
Дык, бутстрап содержит список официальных агрегаторов - резервирование на случай перебоев доступа.
А товарищимайоры делают фейковые агрегаторы (как IKnowWhatYouDownload), чтобы ловить участников поиска (иначе без поиска это уже не DHT-сеть). А при необходимости эти фейковые агрегаторы начинают выдавать пургу, затрудняя или совсем задудосивая поиск).
товарищимайоры делают фейковые агрегаторы
Всё зависит от степени закрученности резьбы. Как сейчас: YouTube заблокирован, но если пользователь пролез - к нему нет претензий. Но если юр. лицо (провайдер) помогает обходить блокировки, вот это пресекается. Если остаётся по-прежнему, схема работает. Но если за обход блокировки санкции к обычным пользователям, то они все разбегутся и тут никакие тех. средства не помогут.
Стоп! ...
А ведь раньше, до того как продаться мелкомягким, Skype использовал гибридную децентрализованную систему.
Т.е. центральных серверов не было, но некоторые мощные клиенты могли взять на себя функции супернод - координационных узлов. Они выполняли роли STUN-серверов, а при необходимости пропускали через себя трафик других клиентов (TURN).
Так что, распределенные сети мессенджеров - это уже было.
P.S. Хотя насчет STUN на супернодах я не уверен.
Т.е. центральных серверов не было,
Как минимум, логин-сервер, аутентифицирующий клиентов.
Тогда цель была не в децентрализации ради обхода блокировок, а в экономии, чтобы трафик не гонять через свою инфраструктуру.
Так что, распределенные сети мессенджеров - это уже было.
Ох, эти времена дикого непуганного интернета. Там и "поваренная книга террориста" лежала открыто на narod.ru. Сейчас вопросом, взлетит ли.
Кажется, была здесь статья, как реализовать аутентификацию в децентрализованных сетях. Но вряд ли найду ...
"Поваренную книгу" читал. Забавно. Но в научно-популярных книгах по химии, изданных в 60-х годах, еще и не такое можно было найти :D
Искать ничего не надо, всё элементарно. Юзер вводит пароль, он хешируется - получается приватный ключ. Если энтропии обычного пароля мало, можно сфоткать кошечку на улице и каждый раз при логине дополнительно к паролю указывать этот файл (конечно, надёжно его забекапив, т.к. потеря ключевого файла = потере аккаунта). Из приватного ключа получается пара приватный+публичный.
Потом в DHT вбрасывается подписанное сообщение: я (публичный-ключ) нахожусь сейчас по IP-адресу X.X.X.X, и всё можно отправлять зашифрованные сообщения.
Это не аутентификация. Это просто сеансовая регистрация.
Для аутентификации логин (номер) и хеш пароля должен где-то храниться. Но не на сервере, т.е. сеть одноранговая.
Т.е. хранение должно быть так же распределенным и с поддержанием целостности, даже если большая часть клиентов выйдет из неё.
В то же время, чем больше узлов хранит аутентификационную пару пользователя, тем выше вероятность компрометации.
Да, согласен, распределённая база нужна, с персистентностью, а не просто DHT. Но тогда ломается легковесный сценарий "всё в браузере".
вероятность компрометации
Нет такой вероятности, потому что аутентификация выполняется по публичному ключу, а приватный ключ, генерируемый из пароля, не покидает устройство владельца.
Тут больше проблема с DoS-атаками (злоумышленник может легко заспамить сеть бессмысленными данными), нужно типа PoW, чтобы доказать что твои учётные данные сгенерированы за существенные затраты мощности и потому стоят хранения.
Как это нет вероятности?
Вот попадает устройство, являющееся DHT-узлом в руки того-кого-нельзя-называть. А в этом устройстве куча логинов и парольных хешей.
Тот-кого-нельзя-называть копирует парольную пару и использует её для входа под чужим логином.
И всякие ухищрения, типа динамического соления, не помогают, потому что они затрудняют подбор пароля при перехвате хеша. А здесь ничего не перехватывается а просто задаром получается несолёный хеш.
И чем больше устройств в сети, тем больше вероятность того, что одно из них взломают.
Вы хотите восстановить приватный ключ (пароль), имея публичный (хеш).
Ну, удачи взломать 512-битный хеш. Криптографы признают, что это нереально, и строят на этом защищённые каналы. Ну или можно биткойн-кошельки опустошать, зная только лишь их адрес, и не зная приватный ключ?
Если лично ваш узел взломают, тогда да, оттуда могут вытащить ваш пароль.
А зачем узнавать пароль?
Достаточно знать сам хеш пароля. А он уже будет известен.
Обычно де при аутентификации передается пара (логин, хеш пароля). Но этот метод уязвим перед "атакой повтором". Перехватив один раз передаваемый хеш, можно затем передавать самому.
Для противодействия этому применяют динамическое соление. Каждый раз, при аутентификации клиенту передается некая случайеая "соль". Она дописывается к хешу пароля м снова хешируется. При получении такого двойного хеша сервер тоже берет хранимый хеш пароля, дописывает к нему "соль", если она еще не "протухла" и снова хеширует. Потом сравнивает с тем, что пришло.
Т.е. таким образом передается всегда разный хеш. Это помогает от перехвата.
Но не помогает, если тот-кого-нельзя-называть получит доступ к устройству с хранящимся несолёным хешем пароля.
У меня впечатление, что вы не понимаете, как работает криптография с открытым ключом. Я публикую открытый ключ, закрытый держу в тайне. И только я смогу создать сообщение, которое будет соответствовать (корректно подписано) известному открытому ключу.
Для аутентификации мне достаточно подписать сообщение "я Вася с IP-адреса x.x.x.x, а время сейчас 26.03.2025 22:11". Любой пользователь сети, знающий мой открытый ключ, будет уверен, что это я - Вася, а не какой-то самозванец.
Криптография с открытым ключом, а не хеширование?
Нет, похоже, это Вы не понимаете, что предлагаете просто вложить в эту систему готовую DDoS атаку на саму себя.
Даже DHT-запросы в торрент-клиентах вызывают кратковременные сетевые штормы. Но они затрагивают только каналы связи, а не клиентские машины, т.к. вычисление хешей даже по SHA-1 - достаточно легковесная процедура.
А вот аутентификация по открытому ключу - это уже серьезно будет нагружать компьютеры и устройства пользователей. И это будет работать примерно так:
Алиса хочет связаться с Бобом, но не знает его адреса.
Алиса посылает запрос "Где Боб" Кэрол и Тренту, удостоверив его своей цифровой подписью (эту нагрузку пока что можно игнорировать).
Но Кэрол и Трент уже забыли, кто такая Алиса (не имеют её публичного ключа).
Они начинают рассылать запросы "Кто такая Алиса?" по всем своим знакомым, подписывая своей ЭЦП (вот появилась первая нагрузка на промежуточные узлы).
Знакомые, допустим, знают Кэрол и Трента (имеют их публичные ключи). Но чтобы убедиться, что сообщение пришло от них, должны расшифровать их ЭЦП и удостовериться в их целостности и непротиворечивости.
Допустим, они знают Алису и могут сообщить Кэрол и Тренту ее публичный ключ.
Кэрол и Трент, слегка успокоившись, приступают к обработке запроса Алисы.
Но они тоже не знают, где Боб. Так что поиск с шифрованием/расшифровыванием запросов продолжается.
В конце концов TTL первоначального запроса исчерпывается или все же находится кто-то, кто знает и где Боб и запрашивающего.
Тогда он отвечает и отправляет ответ обратно, подписывая своей ЭЦП.
Ответ проходит уже без поиска пути назначения, но всё равно узлам по всей цепочке надо удостовериться, что информация пришла от того, от кого надо. Т.е. опять тягомотина с расшифровыванием и шифрованием.
Наконец, информация о Бобе приходит к Алисе.
Та, радостная, шлет ему сакраментальное "Hello Bob!"
Но Боб тоже успел забыть, кто такая Алиса.
И шлет по всем своим знакомым запрос "Who is fu***ng Alice?"
Развлекуха продолжается.
How do you like this Elon Musk?
Вы придумали плохой протокол, так делать не надо. Через DHT надо искать Алису по её открытому ключу (это мало чем отличается от поиска раздачи по инфохешу, криптография не нужна). А как только получим список Алис (если найдётся больше одной), коннектимся к каждой и уже проверяем её подлинность. Нагрузка исключительно на двух пиров, заинтересованных в диалоге.
Т.е. никакого подтверждения на право делать запросы не требуется?
Зашибись! Вот поэтому и появляются всякие фейковые DHT-агрегаторы, раз никто ничего не контролирует.
Вы какую задачу хотите решить? Скрыть от сети факт, что "X интересуется Y"? Это можно сделать, лишь размазав настоящий интерес в потоке фейка. И отфильтровывая ответы у себя локально, тогда будет невозможно понять, что есть настоящий интерес, а что фейк.
По аналогии с тем, как некоторые криптосети поддерживают постоянный трафик например 10 мегабит, забивая его мусором когда нет активности, чтобы сторонний наблюдатель не смог скоррелировать сеансы отправки и приёма между узлами.
аутентификация по открытому ключу - это уже серьезно будет нагружать компьютеры и устройства пользователей
Вы плохого мнения о современных компьютерах. Каждое TLS (https) соединение проверяет цепочку доверия по сертификатам (используя открытые ключи). Эта мизерная нагрузка, чтобы говорить "давайте откажемся от TLS"
И тем не менее, в HTTPS ассиметричное шифрование RSA применяется только во время "рукопожатия" с целью выработки сеансового ключа AES. Контент передается уже по симметричному шифрованию.
А почему? А потому что пользоваться ассиметричным шифрованием для большого объема информации (или для большого количества малых фрагментов) даже современные компьютеры позволить себе не могут.
DeepSeek мне сказал, что обработка TLS соединения выполняется за 0.5 мс. То есть, можно регистрировать в сети до 2000 новых нод в секунду. Понятно, что это поле для DoS - атаки, но при нормальном функционировании сети такой нагрузки не будет. Тем более, в DHT нода при своём появлении регистрируется не у всех, а среди своих выбранных 10-50 "соседей".
Эта обработка (выполняется даже быстрее) по большей части возлагается на кластер специально обученных серверов. Клиент только генерит сеансовый ключ и шифрует его переданным сервером открытым ключом.
В случае пиринговой сети уже каждому клиенту придется постоянно и шифровать и расшифровывать сообщения. А клиенты бывают разные!
Не нашел цифр по шифрованию AES-ключа, но проверка ЭЦП на 64-битном XEOM 3,1 GHz занимает от 100000 до 10000000 тактов процессора. Что существенно.
Думаю, слабые клиенты будут не рады.
P.S. А еще есть такая штука, как распространение новых ключей взамен протухших.
Эта обработка (выполняется даже быстрее) по большей части возлагается на кластер специально обученных серверов
Не понял, какой кластер? Когда мой браузер делает запрос на https://habr.com, какой кластер помогает проверить подлинность сайта?
10млн. тактов, это 3.33мс на частоте 3GHz. Ну, терпимо.
Можно же ещё оптимизировать. Принимать от нод подписанные заявления "я Вася (468ba46b532d1f99) с IP-адреса x.x.x.x, а время сейчас 26.03.2025 22:11" и сохранять как есть. В фоне, когда есть свободное CPU, проверять подписи у удалять невалидные. Пул непроверенных подписей ограничен, в случае DoS, непроверенные записи просто будут вытесняться новыми.
Также, можно делегировать проверку другим нодам. Вот сценарий: кто-то спрашивает Васю. Мы отправляем ему сообщение с подписью ровно в том виде, как его получили, хотя ещё не проверили его. А этот кто-то уж пусть сам проверяет подпись, это же ему нужен Вася, а не нам. Пусть не поленится потратить 5мс на проверку перед попыткой коннекта по этому адресу.
У Хабра кластера, похоже, нет - мелковат будет. Хотя, одна точка входа еще не гарантирует, что за ней нет распараллеливания потоков на несколько веб серверов (хотя, при одном входе это почти бессмысленно).
А вот Яндекс, Мэйл.ру, Амазон, Гугл и другие гиганты имеют из 2-3-4 точки входа на сайты. У Гугла их, как минимум, 6.
Это делается как для балансировки нагрузки, так и для повышения отказоустойчивости.
Ну хорошо. Объясните, какой хост кластера mail.ru помогает мне удостоверить подлинность моего подключения к сайту https://mail.ru ?
Насколько я знаю, нет таких протоколов. А если бы и были, как мне убедиться, что я подключился к подлинному серверу проверки, а не фейку? Опять на клиенте проверять подписи, но уже кластерного сервера?
А я откуда знаю? Разумеется, он находится не на кластере обработчиков запросов, а где-то глубже в сети.
Но у них централизованная сеть. Т.е. регистрацией и аутентификацией занимается некий единственный центр, а не размазано это по всей пиринговой сети.
Как это нет? Вы прошли регистрацию, зарегистрировали пользователя ВасяПупкин. Возможно, привязали почту, телефон, включили двухфакторную аутентификацию. Теперь, при вводе логина/пароля система будет знать, что в нее входит подтвержденный пользователь (не физлицо, а владелец аккаунта) ВасяПупкин.
Т.е. данные для аутентификации где-то хранятся и где-то обрабатываются и подтверждаются. Но как сделать это в открытых пиринговых сетях, где централизованной регистрации нет, а децентрализованное хранение опасно, как его не защищай?
Кстати, пришла такая идея в голову по поводу централизованного хранения хешей паролей:
Хеши хранятся на отдельном сервере, куда нет прямого доступа пользователя. Т.е. запросы принимаются только от backend-серверов и не напрямую к СУБД, а через некоторое API.
При попытке подключения пользователя на этом отдельном сервере создается идентификатор неоткрытой сессии, являющийся одновременно "солью" с ограниченным временем годности".
Пользователь хеширует пароль, приписывает соль, снова хеширует. Передает логин, соль и дважды хешированный пароль.
Всё это передается на сервер аутентификации. Если соль еще не протухла (идентификатор неоткрытой сессии не исчерпал срок действия), тот по логину находит хеш пароля, приписывает соль, хеширует и сравнивает с тем, что пришло. И выдаёт либо отлуп, либо сессионный билет.
Таким образом, несоленый хеш никогда не покидает сервер аутентификации. Исключение - запись его в ходе регистрации. Но это уже другая история, не связанная с хранением хешей паролей.
Осталось решить вопрос, как защитить сессионный билет при работе по HTTP.
А я откуда знаю? Разумеется
Ну если вам удобно, можете продолжать верить в небылицы. А можете поднять спецификации протоколов и убедиться, что клиент сам локально проверяет ЭЦП при установке SSL-соединений.
Дальше я потерял нить, при чём здесь ВасяПупкин и установление доверия сервису mail.ru, когда я открываю его в чистом браузере.
Кстати, пришла такая идея в голову по поводу централизованного хранения хешей паролей
И какие задачи решает эта схема? Чем она лучше условного телеграмма? Что так, что сяк, мы должны доверять серверу. Злоумышленник, имеющий доступ к серверу, сфабрикует вход в любой аккаунт. А не имеющий доступ к серверу, ничего не сможет сделать.
А при чем тут кластер и то, на чьей стороне проверяется сертификат?
ВасяПупкин при том, что в централизованной системе априори полагается доверие к серверу аутотентификации. Во-первых, что он ошибочно не позволит кому либо аутентифицироваться под чужим логином, Во-вторых, что БД хешей паролей достаточно защищена, а сами хеши криптостойки.
Как достичь такого же уровня доверия (и возможно ли это в принципе) в децентрализованной пиринговой сети - вот в чем вопрос.
Задача решается простая - полностью ликвидируется доступ к несоленому хешу, чтобы исключить атаку повторением.
UPD:
И, кроме того, возникает вопрос: а кто будет контролировать (удостоверять) появление новых пользователей с их ключами?
Иначе легко сказать "Я Вася Пупкин, знаю и Гоголя и Пушкина, а всю вашу шоблу на вертеле вертел". И заняться выдачей фейковых ответов, вместо адреса Боба сообщая адрес того-кого-нельзя-называть.
В криптосетях нет человекочитаемых идентификаторов, только хеши. Поэтому в контактах будет 468ba46b532d1f99, к которому вы подпишете "Вася" для удобства. Все другие Васи не будут иметь приватного ключа, из которого получен этот хеш.
И заняться выдачей фейковых ответов, вместо адреса Боба сообщая адрес того-кого-нельзя-называть
Вот это пока никак не купируется. Пиры будут доверять этим ответам, коннектиться на указанный адрес, но понимать, что там не настоящий Вася, что он себя не может аутентифицировать по ключу.
В принципе, если "зловредных" узлов мало, это никак не влияет. Если много, то увы, сеть рассыпается.
Надо освежить в памяти задачу о византийских генералах-предателях. Суть - выработка согласованного решения в условиях злонамеренного искажения информации частью узлов.
К исходной задаче это отношение имеет слабое. Но всё равно полезно.
Не понимаю, как эта задача тут применяется.
Абонент не может тебя обмануть, выдав себя за другого - подписи не сойдутся. А обман с фейковым адресом легко проверяется: сходил на этот адрес, проверил, не оно - невелика потеря, пару КБ трафика. Ещё можно фейковую ноду забанить, после N ошибочных адресов.
Вспомнил еще казус, к делу не относящийся, но показательный:
Samsung отказался от поддержки на своих устройствах кодеков DivX/XviD, т.к. по сети распространяется много пиратских фильмов в формате .avi, использующем эти кодеки.
Тем хуже для Samsung, освободил место на рынке китайским брендам, не столь щепетильным. Вообще, у меня ощущение, что Samsung умирает. Galaxy S уже не такой торт, по сравнению с тем, чем был 10 лет назад. Да и топы тоже что-то подозревают
Не китайцами одними ... Другие южнокорейцы (LG, Hyundai) не спешат перенимать столь бесценный опыт.
Любопытно, что лет 10 назад, когда для меня были актуальны пиратские фильмы с флешек, телевизор Samsung был всеядным, а LG отказывался воспроизводить звук в кодеке DTS, кушая только AC3. Нужно было в раздаче внимательно смотреть спецификации, чтобы не скачать файл, который потом не проиграется.
А теперь LG как?
А то нашему Самсунгу узе 15 лет. AVI он нормально воспроизводит, кроме "битых". А вот MKV не все. А медиацентр домосборный, слабенький - не хватает ему мощи "на лету" перекодировать форматы. Начинаются фризы на тяжелых фильмах.
Хочу всеядный, с DLNA и чтобы с веб-интерфейсом. А у LG его нет :( Или я не нашел.
Del
Сбор данных из DHT (как работают агрегаторы)