Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Информационная безопасность доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 16
Хорош! Продолжай в том же духе. Ждём мобильное приложение.
Плюсую любые статьи про анонимность и децентрализованные сети. Но скажите - вот есть такая модель OSI. Какие уровни покрывает ваша сеть?
Дело в том, что децентрализованных сетей (разной степени анонимности) много. Разных. Но на мой взгляд, ни одна из них полноценно не достигла самого верхнего уровня - назовем его условно "пользовательским", т.к. в OSI его нет. Т.е. все реализуют некие протоколы, но нет пользовательских приложений, где можно работать не менее удобно, чем с обычным интернетом. Поиск - и чтобы он нашел информацию, пусть и не сразу. Функции социальной сети - поиск единомышленников, группы по интересам. Все это в удобном графическом интерфейсе.
Но скажите - вот есть такая модель OSI. Какие уровни покрывает ваша сеть?
Если натянуть сову на глобус, то думаю можно покрыть все уровни. Вопрос только зачем и для чего. OSI - это всё же модель, более подробная, чем TCP/IP, GP/12, но если последних хватает для описания задачи, то OSI становится просто-навсего оверинжинирингом.
Дело в том, что децентрализованных сетей (разной степени анонимности) много. Разных. Но на мой взгляд, ни одна из них полноценно не достигла самого верхнего уровня - назовем его условно "пользовательским"
Так проблема и не только в децентрализованных сетях. Нет такового приложения и в централизованных аналогах, которое покрывает весь пользовательский опыт. Мы пользуемся браузером, как хорошей абстракцией связывания множества услуг в одну. Проблема существования большого количества протоколов нацеленных на децентрализацию и плохая их применимость в реальной жизни связана в большей мере из-за того, что сама сеть Интернет поощрает централизацию в степени большей, чем децентрализацию. Из-за этого вытекает и куда бОльшая стандартизация централизованных решений.
Вопрос только зачем и для чего.
Децентрализованных сетей много. И все они... несколько недоделанные. И в том числе поэтому p2p сети не такие популярные (исключение пожалуй одно - торренты, но там поисковых и социальных функций нет вообще). Потому что в одиночку или небольшим коллективом пилить по сути новый стек протоколов и софт для него - очень сложная задача. А вот если бы грамотно разбить задачу на модули, то можно было бы к примеру сделать так: кто-то пилит чисто сеть с конкретными фишками (шифрование, безопасность, анонимность...), без UI. А кто-то пилит универсальный UI для нескольких сетей сразу. И это простейший пример разбивки. А ведь можно провести и более глубокую и умную декомпозицию.
/умный режим откл
а по простому. вот я условная домохозяйка как могу приобщиться к вашей сети? мне не надо "весь пользовательский опыт", мне надо установить приложение и отправить сообщение. ну и принять тоже. но тут какой-то исходный код, куда его в ворд вставить чтоб заработало?
/умный режим вкл
у меня довольно много опыта в айти, в сетях и программировании. не очень глубокого, но мне к вам ближе, чем домохозяйке ко мне. а я не понимаю как этим пользоваться. т.е. в общих чертах я вижу, что мне надо изучить, чтоб понять, но голубиная почта кажется более простым решением, чем установка этого добра мне и условному васе, с которым я хочу както общаться после блокировки тг.
По простому - скачать бинарники из релизных версий (тут - hlc и тут - hl-client) и просто их запустить. Этого будет достаточно, HLC запустит ноду, HL-Client подключится к ней. Чтобы HLC подключился к какому-либо внешнему ретранслятору / глобальной сети - нужно запустить узел с опцией `--network oi4r9NW9Le7fKF9d`. Через графический интерфейс HL-Client'а уже можно работать со всем добром - добавлять друзей, редактировать соединения и просто общаться.
В результате, действий получается не сильно много. Безусловно больше на один-два шага, чем в любой централизованной связи, но на деле не критично. Возможно подробности работы самой сети и её изменений, описанные в статье, придали вид сложности. На деле же, на более прикладном уровне, это работает плюс-минус просто.
то думаю можно покрыть все уровни.
то OSI становится просто-навсего оверинжинирингом.
Как много умных слов и красивых картинок в вашем посте, но теперь возникает впечатление, что вы не понимаете, что делаете.
1й уровень модели - физический, кабели. Разве вы затрагиваете этот уровень? Очевидно, что нет. Как и уровень 2.
Почему об этом вас спрашивают? Ну вот вы утверждаете, что ваша сеть полностью нерушима под натиском РКН и им подобных. Ну это же не так! ФСБ даёт требование отключить интернет (проект прошёл второе чтение и нет сомнений что закон будет принят), и провайдер отключает вас от интернета как раз на уровне 1,2 ну или 3. Спасёт ли ваша сеть человека от такого ограничения? Конечно нет. Как спасёт ваша сеть, если у нас на магистральном кабеле (ну предположим что он один, как в Белоруссии, например) связи с глобальным интернетом поставят фильтр по белым спискам? Поэтому, почему вы лучше Tor?
Слабое место децентрализации - сама децентрализация. Как набрать достаточное количество ячеек, чтобы есть оставалась живой и наполненной, но не привлекала внимание санитаров майоров? Кто будет осуществлять стыковку с другими типами сетей (как выходная нода в Tor для связи с глобальной частью интернета. Я вот никогда у себя не запущу такой, мне проблемы не нужны)?
Хотя соглашусь, что в общем то, постановка вопроса была неправильной. Пользовательский опыт - это как раз набор программ, которые используют сеть, как инструмент связи, как транспорт. Как раз интернет и развивался именно так, как пишет NeoCode. Кто-то делал сеть, а кто-то набор программ для пользователей. Но только это вещи не связанные друг с другом. Программа может поддерживать разные протоколы и сети. Ну грубо говоря, производители оптоволокна не должны делать почтовых клиентов.
Если не смущает интерфейс все в одном - то есть Retroshare. Правда оно desktop-only(мобильного интерфейса нет) и когда я еще им пользовался - вменяемого режима для запуска без GUI(на сервере) у него не было.
А каким образом "белые" социалки могут помочь трафик между нодами передавать?
Технически это можно осуществить при помощи групповых чатов или комментариев под постами. Суть такая, что адаптерам HL необходимо реализовать две интерфейсные функции: Produce и Consume на группу пользователей. Если предположить, что это комментарии под постом, то Produce - это создание нового комментария, а Consume - это чтение недавно созданных комментариев.
Конечно будет опрометчиво говорить, что такая реализация адаптера будет простой. Баны и каптчи - никто не отменял. Из-за этого адаптер должен уметь не только продьюсить/консьюмить сообщения, но и должен уметь делать трафик более невидимым и по возможности решать проблемы с банами / каптчами.
Понятно. Более реалистично тогда это через личные сообщения провернуть, группы будут отлетать по бану очень быстро такие.
Энивэй, скорость такого взаимодействия, получается смехотворна...
Да и клиента, реализующего эту возможность, как я понимаю, пока не предвидится, хоть для того же ВК?
Понятно. Более реалистично тогда это через личные сообщения провернуть, группы будут отлетать по бану очень быстро такие.
Недостаток в том, что будет существовать точно известная связь 1к1. Конечно можно объединить множество личных чатов в одну общую сеть, тем самым сделав 1кN сеть, но это будет отправление одинаковых сообщений по множеству чатов, что будет детектироваться как спам куда быстрее, чем писать по одному сообщению в групповой чат.
Энивэй, скорость такого взаимодействия, получается смехотворна...
Да, это факт, адаптация будет съедать и без того не быструю передачу данных.
Да и клиента, реализующего эту возможность, как я понимаю, пока не предвидится, хоть для того же ВК?
Пока есть возможность использовать другие виды связи, то не предвидится. На поддержку таких адаптеров будет уходить много времени, т.к. подобные централизованные сервисы достаточно часто могут менять алгоритмы вставки палок в колёса.
окей, что то похожее на битмесседж... но добавлена отправка раз в N секунд, что еще сильнее создает флуд в сети
не совсем понятно, как устроена доставка если пользователь которому адресовано сообщение был оффлайн, есть какое то подтверждение доставки или иной механизм?
не понятно что делать если ключ скомпроментирован, обычно делается основной ключ и ключ представляющий тебя в сети, и смена ключа происходит безболезненно, а в этом проекте как?
понятно что есть бутстрап сети, но дальше как это работает? таблица узлов с постоянным обновлением?
Сори, не туда ответил: https://habr.com/ru/articles/996434/comments/#comment_29548278
окей, что то похожее на битмесседж... но добавлена отправка раз в N секунд, что еще сильнее создает флуд в сети
Факт, из-за этого существуют хаки в виде подсетей, которые разграничивают разные сети между собой не позволяя им сливаться в одну. Технически можно построить соединения в HL и без проблемы масштабируемости, сведя саму генерацию лишь и только между непосредственными сетевыми узлами, но в таком случае становится необходимым не только логическое доверие (на уровне друзей), но и сетевое - к кому подключаешься.
не совсем понятно, как устроена доставка если пользователь которому адресовано сообщение был оффлайн ...
Раньше эту роль выполнял HLT, который сохранял N-ое количество сгенерированных сообщений, а узлы их подгружали в момент подключения к сети. В текущей реализации этот механизм был убран - возврат этой логики под вопросом. Легче создать логику на уровне прикладных сервисов, когда обмен сообщениями происходит при помощи "запрос-ответ", а процедура отправления сообщений - это их локальное сохранение в хранилище + отправка по сети.
... есть какое то подтверждение доставки или иной механизм?
Есть, существует два типа запросов - Send и Fetch. Первый отправляет сообщение без подтверждения, второй - с подтверждение (получением ответа). Если ответ при Fetch не был получен - выполняются ретраи. Логика при которой запрос был получен (обработан), а ответ - нет (из-за чего возникает ретрай), должна регулироваться уже прикладными сервисами.
не понятно что делать если ключ скомпроментирован, обычно делается основной ключ и ключ представляющий тебя в сети, <...>, а в этом проекте как?
В этом проекте существует долговременный ключ, который идентифицирует пользователя. Им шифруют сообщения, им подписываются сообщения (фактически это два ключа - ML-KEM + ML-DSA, интерпретируемые как один). Каждое сообщение шифруется одноразовым симметричным ключом, который инкапсулируется при помощи ML-KEM.
Если ключ скомпрометирован, то остаётся лишь менять старый ключ на новый и далее оповещать всех друзей о смене ключа (также по сторонним каналам связи). Сам факт компрометации - это, в массе своей, есть ошибка пользователя.
и смена ключа происходит безболезненно
Смена ключа при компрометации безболезненно нигде не проходит, особенно если это долговременные ключи.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Анонимная сеть «Hidden Lake»: текущее состояние, развитие и перспективы