C-toxcore: Задокументируйте вопросы и ответы, связанные с криптографией и сетями p2p.

Вы ошибаетесь. Узлы начальной загрузки DHT существуют для облегчения присоединения к DHT. Если вам нужны дополнительные пояснения, вы можете просмотреть эту статью: https://en.wikipedia.org/wiki/Distributed_hash_table. Кроме того, вы можете присоединиться к нам в IRC, на канале #tox на Freenode, и мы постараемся объяснить все как можно лучше.

Ваш трафик может проходить через загрузочные узлы, действующие как ретрансляторы TCP, в то время как tox использует TCP для дружеского соединения. Это похоже на TURN . Ваш трафик по-прежнему зашифрован от начала до конца, поэтому конфиденциальность и подлинность ваших сообщений никогда не будут скомпрометированы. Вероятно, эта ретрансляция TCP — это то, что вы видели при анализе трафика. Он подробно описан в спецификации протокола tox .

Это голосовой трафик. Он зашифрован, и теперь третьи лица не могут его расшифровать, но это не значит, что это невозможно в будущем.

У меня есть прямой адрес IPv4/IPv6. Почему я должен отправлять свои данные на узлы?
Вы говорите: «Узлы начальной загрузки DHT существуют для облегчения присоединения к DHT», но это неправда. На прикрепленном снимке экрана трафик проходит через узлы, а не напрямую ко мне.

«Tox — это простое в использовании программное обеспечение, которое связывает вас с друзьями и семьей так , чтобы никто другой вас не подслушивал». — Это ложь? Трафик зашифрован, хорошо. Но он использует узлы для доставки? Я не знаю, кто обслуживал эти узлы. Что делать, если один или несколько узлов являются ложными?

Я понимаю, что этот момент может показаться неверным, поэтому я зарегистрировал проблему с документацией, чтобы улучшить наше представление об этом. Спасибо за объяснение ваших мыслей.

Чтобы быстро объяснить вашу конкретную проблему, я перефразирую ее. Пожалуйста, дайте мне знать, если я неправильно понял:

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

A: Во-первых, рассмотрим пакет, идущий напрямую с вашего компьютера на компьютер вашего друга, при условии, что вы подключены к локальному Wi-Fi:

• Ваш компьютер создает зашифрованный пакет Tox (см. сведения о шифровании ), который он упаковывает в пакет UDP, содержащий порты источника/назначения (random/33445), а затем в пакет IP, содержащий IP-адреса источника/назначения (вы и ваш друг) , затем кадр Wireless, содержащий MAC-адреса источника/получателя (вы и точки доступа).
• Этот кадр беспроводной сети отправляется по зашифрованному каналу AES (при условии WPA2).
• Беспроводная точка доступа, как и любой другой пользователь сети, получает его. Другие пользователи обычно игнорируют пакет, но это не обязательно. Чтение пакетов, которые не предназначены для вас, называется сниффингом. Это первая точка, в которой другие могут прочитать пакет.
• Беспроводная точка доступа подключена к WAN-маршрутизатору (интернету), который устанавливает соединение с маршрутизаторами вашего интернет-провайдера с помощью некоторых средств (акустическая связь, ISDN, ADSL, кабель, спутник, оптоволокно, ...). Это соединение может быть зашифровано (некоторые спутники), но обычно это не так. На этом этапе маршрутизатор WAN, на который вы отправили свой пакет, создаст кадр Ethernet, содержащий его собственный MAC-адрес и MAC-адрес следующего маршрутизатора, к которому он подключается, который является маршрутизатором вашего интернет-провайдера. При передаче IP- и MAC-адреса, скорее всего, не зашифрованы и могут быть прочитаны любым, кто прослушивает оптоволокно между вами и провайдером. Это вторая точка, в которой другие могут прочитать пакет.
• После того, как пакет прибыл к интернет-провайдеру, он будет проходить через различные внутренние системы в их центрах обработки данных, возможно, в зашифрованном или незашифрованном виде в различные моменты времени. Маршрутизатор ISP затем определит следующий маршрутизатор, на который он должен отправить пакет, определяемый IP-адресом. Для этого он развернет полученный кадр Ethernet, завернет его в новый и отправит следующему маршрутизатору. В любой момент во время обработки у интернет-провайдера сотрудники центра обработки данных или системного администратора этого интернет-провайдера могут получить доступ к вашему пакету. Третья точка доступа.
• Теперь ваш пакет будет прыгать от маршрутизатора к маршрутизатору (попробуйте traceroute $your_friend_ip , чтобы увидеть, куда он идет), каждый из которых имеет свободный доступ к кадру Ethernet, пакету IP и пакету UDP, а также к его содержимому. Много точек доступа, назовем ее 4-й.
• Тогда ваш друг может оказаться в похожей ситуации, в локальном вайфае в другом месте. Опять же, их маршрутизатор и члены беспроводной сети могут прочитать пакет. Пятая точка доступа.
• Только вот, наконец, ваш пакет приходит на компьютер вашего друга. Он получает кадр беспроводной сети, разворачивает его, чтобы найти пакет IP, разворачивает его, чтобы найти пакет UDP, разворачивает его, чтобы найти пакет Tox, который затем обрабатывается реализацией протокола Tox. Эта обработка включает в себя расшифровку и декодирование пакета и действия над ним, что обычно приводит к тому, что клиент вашего друга отображает сообщение, воспроизводит аудио или видео или выполняет некоторые другие действия на уровне приложения.

Как видите, при «прямой» передаче от вас к вашему другу есть много моментов, где пакет может быть просмотрен произвольными людьми. Сквозное шифрование означает, что между вами и вашим другом никто не сможет прочитать фактическое содержимое, которое вы намеревались передать. Они всегда могут видеть только зашифрованные данные.

Теперь добавление ретранслятора TCP в середине просто удлинит маршрут (теоретически он может его сократить, но это маловероятно). Любой, кто запускает ретранслятор, может прочитать пакет, как и любой другой между вами и вашим другом. Криптопротокол Tox гарантирует безопасность вашего общения.

Теперь я также вижу вторую проблему:

В : _Что произойдет, если один из узлов, передающих мои данные, будет вредоносным?_
A: Tox выбирает количество ретрансляторов TCP, которые он может использовать для связи в случае, если прямые соединения UDP невозможны (например, из-за NAT или брандмауэра). Злые ретрансляторы могут сделать очень немного зла:

• Они могут решить не отправлять пакет. В этом случае Tox повторит попытку через другое реле. Только если все загрузочные узлы являются злыми, передача не удастся.
• Они могут отправить измененный пакет. Благодаря кодам аутентификации сообщений любая фальсификация данных может быть обнаружена. Если отправителю удастся подделать его таким образом, что программное обеспечение не обнаружит его, расшифрованный пакет будет считаться мусором, и прикладной уровень (декодер протокола Tox) отбросит его. Следовательно, это имеет тот же эффект, что и полное отсутствие ретрансляции пакета.

Это в основном все. Ни в коем случае злой ретранслятор не сможет прочитать ваши данные. Он может только не ретранслировать, и только если каждый узел начальной загрузки является злом, вы не можете общаться. Это было бы довольно неприятно, и мы были бы недовольны этим, но ничья информация никогда не скомпрометирована.

Я надеюсь, что это проясняет некоторые вещи. Я не проверял этот ответ, но я позабочусь о том, чтобы он был правильно представлен на веб-сайте для дальнейшего использования. Дайте мне знать, если у вас есть какие-либо другие проблемы. Еще раз спасибо, что подняли этот вопрос.

Я только что снова прочитал ваше сообщение и обнаружил, что пропустил еще одну проблему:

В: Хотя сейчас данные зашифрованы, что гарантирует, что они не будут расшифрованы в будущем?
A: Протокол Tox обеспечивает совершенную прямую секретность за счет использования эфемерных ключей. Это означает, что если один из этих ключей будет скомпрометирован, можно будет расшифровать несколько сообщений, но не всю вашу историю общения. Часть «несколько сообщений» в этом предложении в будущем будет сокращена до «одного сообщения». Если ваш долгосрочный секретный ключ скомпрометирован, никакие прошлые сообщения не могут быть расшифрованы.

Если используемые нами криптографические примитивы сломаны, мы проигрываем. Это зависит от того, каким образом они сломаны, это возможные наихудшие сценарии:

• Шифр ( salsa20 ) можно легко отменить без ключа. В этом случае все прошлые коммуникации скомпрометированы.
• Примитив обмена ключами ( curve25519 ) взломан таким образом, что секретный ключ можно легко восстановить с помощью открытого ключа. В этом случае также скомпрометированы все прошлые коммуникации.

Эти сценарии вряд ли станут реальностью в ближайшем будущем или, возможно, навсегда. Согласно нынешнему пониманию криптографического сообщества, только квантовые вычисления могут реализовать второй сценарий. Первый сценарий считается невозможным.

Все это сказано, я также заметил, что вы сказали, что у вас есть прямой адрес IPv4. Что это значит? Если вашему компьютеру назначен общедоступный IPv4-адрес, а порт 33445 открыт, Tox должен установить прямое соединение очень быстро. Если это не так, это ошибка, и мы должны работать вместе, чтобы выяснить, почему вместо этого используется протокол TCP.

Большое спасибо за это объяснение. Теперь я понимаю немного больше.
Я не уверен насчет прямого IPv4-адреса... Я использую WireGuard VPN. WireGuard устанавливается на виртуальный сервер с прямым адресом IPv4 и IPv6. Весь трафик обернут в namespace.
Информация о сети ноутбука: https://gist.github.com/DebugReport/1268e15c3bd1c99b56929d645d99392b
Если я ошибся, извините.
Возможно, IPv4 не является прямым, но как насчет IPv6? Я могу использовать прямые подключения, если у другого клиента тоже есть IPv6?

Да, если у обеих сторон есть IPv6, и конфигурация брандмауэра не блокирует порт 33445 (или какой-то другой порт рядом с ним, что-то между 33445 и 33545), это должно работать. Ваш друг находится в той же VPN?

Нет.
Хм... Вопрос. Нам всегда нужно использовать узлы? Или только если у одного из нас нет прямого IP (только IPv4?)?
Нужны ли узлы для IPv6 (я) <-> IPv6 (друг)? Если да - почему?

(Оставлять этот вопрос открытым до тех пор, пока на все эти вопросы не будут даны ответы в документации)

Если у одного из вас есть общедоступный IP-адрес, то другой может загрузиться, используя IP-адрес и порт другого. Для этого требуется поддержка клиентов. Я не думаю, что в настоящее время у любого клиента есть:

• Получите открытый ключ DHT от клиента с общедоступным IP-адресом и открытым портом ( tox_self_get_dht_id ) и его портом ( tox_self_get_udp_port ).
• Отправьте этот ключ другому как-нибудь (продиктуйте по телефону или сообщением в скайпе или еще как-то).
• Другой теперь нужно загрузить с помощью кортежа (key, ip, port) .

После этого у вас есть личная сеть Tox из 2 человек. Итак, теоретически вам не нужны никакие другие узлы. Однако они облегчают задачу.

Если у одного из вас есть общедоступный IP-адрес и открытый порт, то подключение к узлам начальной загрузки также должно позволить вам установить прямое соединение. Узлы начальной загрузки DHT не имеют ничего общего с тем, можете ли вы подключиться или нет. Прямое подключение должно быть возможно, даже если только у одного из вас есть общедоступный IP-адрес и открытый порт. Другой подключится к нему, что создаст маршрут в локальном маршрутизаторе и предоставит клиенту временный случайный публичный порт.

Просто примечание: я заметил такое же поведение с C-Toxcore. Одна из сторон находится на VPS с общедоступным IP-адресом и без брандмауэра, другая находится за NAT, но имеет перенаправленный порт Tox, поэтому они должны быть взаимно доступны. Трафик по-прежнему направлялся через TCP.

Я не считаю это проблемой безопасности, но это, безусловно, проблема масштабируемости, если сеть P2P передает весь свой трафик через ретрансляторы.