Pull to refresh

TOX: Что произошло в проекте за полгода

Reading time 4 min
Views 62K


Многие наверно уже слышали о Tox — это мессенджер, который должен заменить Skype, предоставив такой же функционал, как и его проприетарный аналог, подарив такие полезные вещи, как: Шифрования всего и вся, отсутствие слежки, отсутствие рекламы, децентрализация.

Может показаться, что проект умер развивается слишком медленно, но на самом деле, у него под капотом (в ядре) произошли огромные изменения которые стоит осветить.

Tox, как большинство ПО, сейчас делится на ядро и оболочку и обычно, ядро разрабатывают одни люди, а оболочку совершенно другие, скорость разработки и внедрение новых функций не всегда одинаковы быстро происходят в обоих частях (Ядро/Оболочка)

В прошлом посте мы тестировали Tox аудиторией хабры (и отправили мой тестовый ID в spam листы).
Но с этого момента произошли изменения, некоторые из которых уже можно «потрогать» а о некоторых только почитать и помочь реализовать в оболочке.

Анонимность


Защита от идентификации способом добавления в друзья

Tox — мессенджер, построенный на основе DHT сети, что означает видимость вас и вашего IP адреса всему миру.
В мире Tox клиенты идентифицируют друг друга на основе ключей генерируемых при первом запуске, очевидно, что была проблема прямой связи ID = IP адрес = физический человек = репрессии.

Для решения этой проблемы применяется луковичная маршрутизация, о которой я упоминал в прошлом посте.
Принцип её работы следующий:
Алиса хочет добавить Боба в друзья для последующего общения.
1) Она выбирает случайных трёх пиров в сети Tox и анонсирует себя по правилам луковичной маршрутизации (Первая нода знает адрес Алисы и ID, вторая нода знает только адрес первой ноды и ID Алисы, третья нода, соответственно знает только ID и IP адрес второй ноды) (Боб при запуске клиента делает так же, выбирая последовательность из трех узлов)

2) Она ищет по DHT ноды которые знают о существовании Боба и передает им сообщение о добавлении в друзья

3) После получения запроса авторизации происходит его передача группе пиров которые знают о бобе, и запрос о авторизации проходит через следующие случайные три ноды выбранные Бобом.

4) После получения авторизации процесс повторяется с использованием новых случайных узлов для передачи подтверждения о добавлении в друзья

5) Устанавливается прямое соединение в котором уже видны IP адреса Боба Алисе и наоборот.

Защита от идентификации за пользователем на основе накопления данных

В сети DHT, обычно (Bittorrent/Kademlia) при первом соединении с сетью, генерируются случайные идентификаторы, которые не меняются при смене IP адреса.
Очевидно, что в рамках безопасного мессенджера — это проблема.

Она решена следующим путём:
1) При первом запуске генерируются ID/Key длительного действия

2) На основе первичных ключей при каждой смене IP адреса генерируются новые ID/Key (так же они меняются через случайные период времени)

Но как Алиса найдет Боба если по старому ключу в DHT она его найти уже не может?

Алиса и Боб друзья, они сгенерировали временные ключи и подсоединились к DHT сети.
Боб находит случайные три узла (A, B, C)
Боб находит ближайший узел который находится ближе всего к нему (D)

Боб создает луковичную маршрутизацию (пакет будет следовать через узлы A, B, C и выходной точкой пакета будет служить нода D)
В место его ключа и ping_id адреса, он анонсирует все нули.
Боб будет продолжать строить цепочку до тех пор, пока он не найдет узел который ближе всего к нему на основе его реального публичного ключа.

Как только такой узел найден, ему будет отправлен запрос с корректными данными ping_id (не своими а любого из узлов A, B, C) — данный узел и будет финальным узлом который будет в дальнейшем анонсировать Боба и отвечать за него в сети выполняя роль ноды D

Боб попросит данный узел держать в памяти информацию о нем для взаимодействия с сетью.

Тем временем Алиса ищет ближайший узел к Бобу, она использует временные ключи и ID, как только она получает ответ в виде ping_id = 0 она отправляет данные данному узлу и просит передать его Бобу, передавая свой временный ID в DHT сети.

Боб находит её в сети, на основе её временного ID, устанавливается прямое соединение.

Таким образом, невозможно узнать IP адрес боба и Алисы пока они не добавлены в друзья друг к другу, так невозможно связать TOX ID и DHT ID (без добавления в друзья) c реальным IP адресом.

PS Естественно на каждом этапе пакеты шифруются и защищены от подделки.

Борьба с админами NAT и фаерволами


Если вы помните, Skype обходит файерволы при помощи супер-нод и использования стандартных портов, TOX тоже будет уметь так делать.
— Работать через 80/443 порт
— Находить супер-ноды или быть ими
— Использовать UDP/TCP в зависимости от окружающей среды

Tox в основном использует UDP (для пробивки NAT), но если настройками безопасности трафик UDP блокируется, то TOX будет делать следующее:

1) Алиса пользуется Tox на соединении которое допускает только TCP подключения, она генерирует временные публичные ключи и подключается к узлам для инициализации.

2) После получения данных о сети с узлов инициализации, она выбирает некоторые количество случайных узлов которые являются супер-нодами

3) Она, используя луковичный роутинг через TCP супер-ноду может отправлять запросы на авторизацию или сообщить своему контакт-списку о своём он-лайн статусе, используя временный публичный ключ.

4) Боб получает пакет через луковичный роутинг от Алисы, которая сообщает ему, к каким узлам она подключена по DHT с использованием временного публичного ключа.

5) Боб подключается к тем же узлам что и Алиса.

6) Данное соединение используется для передачи как сообщений так и A/V трафика

7) Если какой-либо узел отключается, Боб и Алиса переходят на любой другой узел, к которому они оба подключены.

Супер нода — это такой узел, у которого имеется внешний IP адрес и проброшены порты Tox.

Чему еще научился Tox?


— Ускорена работы DHT сети
— Массовые чаты (Начальная реализация, без шифрования, без синхронизации мета-информации)
— Передача аудио/видео (Полностью реализовано, на стадии аудита)
— Передача файлов
— Поддержка IPV6 (всё протестировано, кроме групповых чатов)

О главном

Всё, что описано выше — реализовано в ядре, а не в оболочке, другими словами — конечные клиенты, пока, не могут пользоваться многими полезными функциями (например передача аудио/видео или файлов) (не все клиенты еще умеют)

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

Кроме того, проект Tox участвует в Google Summer of Code, а это означает, что скоро в проект придут новые разработчики.

О хорошем


— Для Android активно разрабатывается клиент github.com/Astonex/Antox
— Теперь для Windows существует целых 3 клиента
— Теперь для всех (включая Linux) платформ существуют готовые сборки в пакетах wiki.tox.im/binaries
Only registered users can participate in poll. Log in, please.
Сможет ли Tox победить Skype?
62.47% Да 1052
37.53% Нет 632
1684 users voted. 396 users abstained.
Tags:
Hubs:
+52
Comments 72
Comments Comments 72

Articles