Расписанная сеть обладает списком уязвимостей, которые в новой версии были исправлены. Основных изменений было пять (относительно сети в видео): 1. Количество соединений для узла теперь ограничено определённым константным числом. Соответственно исключается возможность атаки средством большого количества подключений к узлу и последующей DDoS атаки. 2. Теперь, чтобы отправить пакет, необходимым условием является указание подтверждения работы. А те, кто принимает пакет, должен совершить проверку доказательства работы. Иными словами, применяется алгоритм PoW (Proof of work) для борьбы со спамом. 3. В обновлённой версии подпись также шифруется. Это есть важное замечание, так как в ранней версии фреймворка (которая собственно изображена на видео) данный момент позволял посредникам узнать истинного отправителя зная его публичный ключ. Иными словами, если подпись подтверждается подобранным публичным ключом из некоего множества ключей, тогда отправителем является тот пользователь, кто владеет этим проверенным публичным ключом. 4. Также добавлена фича связанная с редиректом пакета, даже если этот пакет принадлежал истинному получателю. Это позволит обезопасить получателя, при условии прослушивания траффика на его стороне. Но в данном случае, также присутствует нюанс, что получатель обязательно должен генерировать ответ, следовательно проблема отправителя остаётся (проблема: при прослушивании траффика можно узнать, что пользователь является истинным отправителем по уникальному пакету, который раннее не встречался в сети). Данную проблему можно решить только ухудшением производительности сети или иными словами спамом (и возможно, в будущем, специальным таймаутом принятого пакета), чтобы скрыть связь в потоке принимаемых-отправляемых пакетов. В таком противоречивом свойстве спам одновременно является и защитником, и губителем этой скрытой сети, и чем больше он защитник, тем больше он губитель. 5. Добавлена возможность построения маршрута пакетов методом их вложенности. Это свойство положительно скажется в те моменты, когда сеть разворачивается внутри заведомо враждебной среды, где траффик способен полностью прослушиваться от начала и до конца. В моменты высокой нагруженности сети будет сложно отделить отправителей и получателей от посредников. Также, данный аспект увеличивает свой потенциал до максимума (в плане анонимности), если сеть построена по федеративному принципу разделения пользователей.
Подскажите, пожалуйста, где для подобных вещей(разработки сетей того или иного уровня) найти базу? Откуда взять информацию по кодингу более "лёгких" в реализации сетей? Буду очень благодарен
Не совсем понятен посыл вступления, получается предыдущая реализация скрытой сети уже не актуальна на гоупир и не работает как надо? Пойду гляну в гит и перепроверю свою ветку. С ходу возник еще один вопрос - если уж вдариться в анонимность, то что на счет анонимного месенджера(на своем серваке, со своим шифрованрем с двух сторон, с контролем нод, внутри сети), блокировщиков трекинга, впн-клиента и своего шифрования, если душа лежит на админку мб даже продвинутого конроля узлов(не только через лог) итд? Если уж начали, то почему бы и да. Peace❤
Скрытая сеть (если мы говорим о HiddenLake) до сих пор базируется и работает на старой версии фреймворка, а именно на v1.1.5. Но так или иначе, её необходимо будет обновить до текущей версии фреймворка v1.2.0, чтобы улучшить моменты связанные с анонимностью и безопасностью (минимизация кода). Основной проблемой фреймворка v1.1.5, по сравнению с версией v1.2.0, является сложность проверки его безопасности. Даже если брать предыдущую версию с написанными тестами, она окажется слабее текущей версии без тестов. Всё это связано со сложностью чтения и воспроизведения, что может приводить к появлению скрытых уязвимостей. Когда же программа минимальна и легко читаема, то количество скрытых уязвимостей будет стремиться к нулю. Что же касается способов применения, то их действительно достаточно много на горизонте. В качестве последующего видео, думаю сделать самое стандартное и лёгкое приложение для такой сферы, а именно чат. Он покажет основные аспекты того, как можно применять фреймворк на практике. (Чат я сделаю в консольном виде, ибо не хочется возиться с графическим интерфейсом, не моё любимое это занятие). Также и реализацию с VPN было бы неплохо сделать, в этом фреймворке как раз присутствует F2F режим, что позволит ограничивать поступаемый трафик от других пользователей. Также вполне реально сделать электронную почту, файловое хранилище и форумы. Проблема всего этого лишь во времени, но так или иначе, примеры показать стоит.
@@CryptoFunIT Ого, как тут интересно, а можно вклиниться? 1.Если возникнут сложности\затупы с реализацией vpn или нужно предоставить мощу(сервачок) - welcome. 2. Чат по комнатам или месенджер с файлообменом? Я бы посмотрел что ваиршарк захватит при таком "общении" двух разных клиентов в варианте "месенджер". Если не сложно - сними в процессе файлообмена\общения как ведет себя пакет(ну или скринами вставь, чтоб мак-адреса\периферию не спалить в лишний раз\не монтировать сутками). 3. Почта и файлообменник - баяны, а вот боты на нейронках и форум это годнота. В любом случае полезно глянуть и на то, и на другое, и на третье. Если тяжко с форумом или с ботами - пиши, у меня где-то были исходники. ---- п.с. слушай, а ты прям молодец! Мне очень понравилось видео.
Если целью является реализация VoIP, то необходимо частично менять протокол TCP на UDP, а при таком изменении следовательно и само приложение скрытой сети будет изменено вполне глобально, в том числе симметричное шифрование нужно изменить с режима CBC на CTR, а асимметричное подписание заменить кодом аутентификации сообщений MAC. А если у нас применяется MAC, тогда необходимо первоначальное соединение (какого не имеется в данном варианте) для обмена сеансовыми ключами и на данном этапе будет корректным использовать уже TCP протокол. Это лишь поверхностные изменения, которые так или иначе нужно сделать со стороны теории, а в момент практики появятся уже другие вопросы и ответы. Что касается TTL, то здесь есть один момент, который может предполагать деанонимизацию отправителя. Счётчик TTL должен быть открытым (незашифрованным), следовательно и любой клиент/узел/посредник способен узнать максимальный размер счётчика и сопоставить его с текущим. Таким образом, атакующий может сузить диапозон пользователей и уже способен определить, что допустим пакет проходит только через один узел или вообще, что сам адресат (с реальным адресов) является настоящим отправителем (а в вариации сети, изображённой в видео, на 100% неизвестно, что даже клиент является истинным отправителем сообщения).
@@volodymyrpalamar5515 можно сказать что не усложнится, а полностью изменится. Архитектура сети с UDP протоколом будет совершенно иной, так как способ "слепой" маршрутизации хорош только при полных пакетах, иными словами при TCP соединении. Если бы мы собрались пересылать UDP пакеты ориентируясь на уже созданный фреймворк, то-есть заменив просто TCP на UDP, тогда у нас появится масса проблем, начиная с высокой нагруженности сети (за счёт уже потоковой связи и большого количества пакетов), заканчивая проблемами подтверждения работ (использованием алгоритма PoW). Если же мы решим соединить два разных механизма маршрутизации в обёртку одной сети, тогда у нас появятся противоречия, которые навредят безопасности сети в целом (допустим будут исключены плюсы, которые предполагает маршрутизация на основе TCP соединения, как высокая анонимность отправителя и получателя).
Похоже, но больше на спам, чем на ддос. DDoS атака будет эффективна против конкретного узла только в те моменты, когда он подключен одновременно к большому множеству других узлов (либо клиентов), иначе атака будет зависеть только от пропускной способности отдельно выделенных узлов (клиентов). Чтобы противодействовать атакам DDoS нужно либо обладать заранее высокими вычислительными мощностями, либо иметь ограничения, связанные с количеством возможных TCP соединений (это кстати в видео не указано, но уже сделано в моих шаблонах, скоро обновлю также и репозиторий). Клиентам такая атака особо не грозит, так как они самостоятельно выстраивают свои соединения. Что касается спама, то да, это вполне относится к такому термину. Тем не менее, спам также будет ограничен пропускной способностью уже существующих соединений. Это говорит о том, что клиент (либо узел) не возьмёт больше данных чем (N * PACK_SIZE), где N - количество выстроенных соединений. Ситуация несомненно будет ухудшаться с увеличением размера сети, так как спам сообщений будет всё больше и больше, заполняя в итоге очередь обработки пакетов, что приведёт к падению производительности. Так или иначе, это и есть цена, которую необходимо платить одновременно и за высокую анонимность, и за безопасность со стороны прозрачности кода.
![CryptoFun [ IT ]](http://yt3.ggpht.com/ytc/AIdro_k76l33NrVmap3F5zsyt2363qxptWil2scr8A2K2ksBPtg=s48-c-k-c0x00ffffff-no-rj)
чувак, ты затрагиваешь интересные темы и делаешь это очень качественно!
Чел, реально оооочент интересно и полезно. Продолжайте пожалуйста
Расписанная сеть обладает списком уязвимостей, которые в новой версии были исправлены. Основных изменений было пять (относительно сети в видео):
1. Количество соединений для узла теперь ограничено определённым константным числом. Соответственно исключается возможность атаки средством большого количества подключений к узлу и последующей DDoS атаки.
2. Теперь, чтобы отправить пакет, необходимым условием является указание подтверждения работы. А те, кто принимает пакет, должен совершить проверку доказательства работы. Иными словами, применяется алгоритм PoW (Proof of work) для борьбы со спамом.
3. В обновлённой версии подпись также шифруется. Это есть важное замечание, так как в ранней версии фреймворка (которая собственно изображена на видео) данный момент позволял посредникам узнать истинного отправителя зная его публичный ключ. Иными словами, если подпись подтверждается подобранным публичным ключом из некоего множества ключей, тогда отправителем является тот пользователь, кто владеет этим проверенным публичным ключом.
4. Также добавлена фича связанная с редиректом пакета, даже если этот пакет принадлежал истинному получателю. Это позволит обезопасить получателя, при условии прослушивания траффика на его стороне. Но в данном случае, также присутствует нюанс, что получатель обязательно должен генерировать ответ, следовательно проблема отправителя остаётся (проблема: при прослушивании траффика можно узнать, что пользователь является истинным отправителем по уникальному пакету, который раннее не встречался в сети). Данную проблему можно решить только ухудшением производительности сети или иными словами спамом (и возможно, в будущем, специальным таймаутом принятого пакета), чтобы скрыть связь в потоке принимаемых-отправляемых пакетов. В таком противоречивом свойстве спам одновременно является и защитником, и губителем этой скрытой сети, и чем больше он защитник, тем больше он губитель.
5. Добавлена возможность построения маршрута пакетов методом их вложенности. Это свойство положительно скажется в те моменты, когда сеть разворачивается внутри заведомо враждебной среды, где траффик способен полностью прослушиваться от начала и до конца. В моменты высокой нагруженности сети будет сложно отделить отправителей и получателей от посредников. Также, данный аспект увеличивает свой потенциал до максимума (в плане анонимности), если сеть построена по федеративному принципу разделения пользователей.
Подскажите, пожалуйста, где для подобных вещей(разработки сетей того или иного уровня) найти базу? Откуда взять информацию по кодингу более "лёгких" в реализации сетей? Буду очень благодарен
Очень, очень хорошо!
Здравствуйте , планируете ли вы делать видео о таких инструментах , как cryptool на ru сегменте об этом , примерно , нуль информации ???
Не совсем понятен посыл вступления, получается предыдущая реализация скрытой сети уже не актуальна на гоупир и не работает как надо? Пойду гляну в гит и перепроверю свою ветку.
С ходу возник еще один вопрос - если уж вдариться в анонимность, то что на счет анонимного месенджера(на своем серваке, со своим шифрованрем с двух сторон, с контролем нод, внутри сети), блокировщиков трекинга, впн-клиента и своего шифрования, если душа лежит на админку мб даже продвинутого конроля узлов(не только через лог) итд? Если уж начали, то почему бы и да.
Peace❤
Кст месенджер можно как с гуем(больше серверный), так и в браузере(я на спринге такое сделал, там больше клиентской части).
И да, спасибо, как перепроверю свою сеть - досмотрю видео.
Скрытая сеть (если мы говорим о HiddenLake) до сих пор базируется и работает на старой версии фреймворка, а именно на v1.1.5. Но так или иначе, её необходимо будет обновить до текущей версии фреймворка v1.2.0, чтобы улучшить моменты связанные с анонимностью и безопасностью (минимизация кода). Основной проблемой фреймворка v1.1.5, по сравнению с версией v1.2.0, является сложность проверки его безопасности. Даже если брать предыдущую версию с написанными тестами, она окажется слабее текущей версии без тестов. Всё это связано со сложностью чтения и воспроизведения, что может приводить к появлению скрытых уязвимостей. Когда же программа минимальна и легко читаема, то количество скрытых уязвимостей будет стремиться к нулю.
Что же касается способов применения, то их действительно достаточно много на горизонте. В качестве последующего видео, думаю сделать самое стандартное и лёгкое приложение для такой сферы, а именно чат. Он покажет основные аспекты того, как можно применять фреймворк на практике. (Чат я сделаю в консольном виде, ибо не хочется возиться с графическим интерфейсом, не моё любимое это занятие). Также и реализацию с VPN было бы неплохо сделать, в этом фреймворке как раз присутствует F2F режим, что позволит ограничивать поступаемый трафик от других пользователей. Также вполне реально сделать электронную почту, файловое хранилище и форумы. Проблема всего этого лишь во времени, но так или иначе, примеры показать стоит.
@@CryptoFunIT Ого, как тут интересно, а можно вклиниться?
1.Если возникнут сложности\затупы с реализацией vpn или нужно предоставить мощу(сервачок) - welcome.
2. Чат по комнатам или месенджер с файлообменом? Я бы посмотрел что ваиршарк захватит при таком "общении" двух разных клиентов в варианте "месенджер". Если не сложно - сними в процессе файлообмена\общения как ведет себя пакет(ну или скринами вставь, чтоб мак-адреса\периферию не спалить в лишний раз\не монтировать сутками).
3. Почта и файлообменник - баяны, а вот боты на нейронках и форум это годнота. В любом случае полезно глянуть и на то, и на другое, и на третье. Если тяжко с форумом или с ботами - пиши, у меня где-то были исходники.
----
п.с. слушай, а ты прям молодец! Мне очень понравилось видео.
Можете подготовить контент по реализацию приложений шифр-систем который шифрует и расшифрует файлов?
Спасибо
подскажите а вот вы програмируете чтото а что в итоге будет ?
Здравствуй, а как реализовать передачу VoIP?
И ещё вопрос а если клиентов много и они одновременно посылают данные не лучше ли сделать TTL?
Спасибо
Если целью является реализация VoIP, то необходимо частично менять протокол TCP на UDP, а при таком изменении следовательно и само приложение скрытой сети будет изменено вполне глобально, в том числе симметричное шифрование нужно изменить с режима CBC на CTR, а асимметричное подписание заменить кодом аутентификации сообщений MAC. А если у нас применяется MAC, тогда необходимо первоначальное соединение (какого не имеется в данном варианте) для обмена сеансовыми ключами и на данном этапе будет корректным использовать уже TCP протокол. Это лишь поверхностные изменения, которые так или иначе нужно сделать со стороны теории, а в момент практики появятся уже другие вопросы и ответы.
Что касается TTL, то здесь есть один момент, который может предполагать деанонимизацию отправителя. Счётчик TTL должен быть открытым (незашифрованным), следовательно и любой клиент/узел/посредник способен узнать максимальный размер счётчика и сопоставить его с текущим. Таким образом, атакующий может сузить диапозон пользователей и уже способен определить, что допустим пакет проходит только через один узел или вообще, что сам адресат (с реальным адресов) является настоящим отправителем (а в вариации сети, изображённой в видео, на 100% неизвестно, что даже клиент является истинным отправителем сообщения).
@@CryptoFunIT Спасибо, а сильно усложниться сеть если её делать одновременно с TCP и UDP
@@volodymyrpalamar5515 можно сказать что не усложнится, а полностью изменится. Архитектура сети с UDP протоколом будет совершенно иной, так как способ "слепой" маршрутизации хорош только при полных пакетах, иными словами при TCP соединении. Если бы мы собрались пересылать UDP пакеты ориентируясь на уже созданный фреймворк, то-есть заменив просто TCP на UDP, тогда у нас появится масса проблем, начиная с высокой нагруженности сети (за счёт уже потоковой связи и большого количества пакетов), заканчивая проблемами подтверждения работ (использованием алгоритма PoW). Если же мы решим соединить два разных механизма маршрутизации в обёртку одной сети, тогда у нас появятся противоречия, которые навредят безопасности сети в целом (допустим будут исключены плюсы, которые предполагает маршрутизация на основе TCP соединения, как высокая анонимность отправителя и получателя).
@@CryptoFunIT Спасибо
thanks
gogo!
Tnx bro
слушай, такой наверника глупый вопрос, а разве это не похоже на спам или ддос?
Похоже, но больше на спам, чем на ддос. DDoS атака будет эффективна против конкретного узла только в те моменты, когда он подключен одновременно к большому множеству других узлов (либо клиентов), иначе атака будет зависеть только от пропускной способности отдельно выделенных узлов (клиентов). Чтобы противодействовать атакам DDoS нужно либо обладать заранее высокими вычислительными мощностями, либо иметь ограничения, связанные с количеством возможных TCP соединений (это кстати в видео не указано, но уже сделано в моих шаблонах, скоро обновлю также и репозиторий). Клиентам такая атака особо не грозит, так как они самостоятельно выстраивают свои соединения. Что касается спама, то да, это вполне относится к такому термину. Тем не менее, спам также будет ограничен пропускной способностью уже существующих соединений. Это говорит о том, что клиент (либо узел) не возьмёт больше данных чем (N * PACK_SIZE), где N - количество выстроенных соединений. Ситуация несомненно будет ухудшаться с увеличением размера сети, так как спам сообщений будет всё больше и больше, заполняя в итоге очередь обработки пакетов, что приведёт к падению производительности. Так или иначе, это и есть цена, которую необходимо платить одновременно и за высокую анонимность, и за безопасность со стороны прозрачности кода.
Нихера себе вы тут чем занимаетесь?
Кампутер саенс
6l9tь, кто ты что ты, чел???