Многие наверно уже слышали о 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
Автор: shifttstas
