В прошлом посте мы рассказали, почему при живых VPN-сервисах и AmneziaWG всё равно есть смысл строить отдельную децентрализованную сеть. Но у любого подобного инструмента - нашего или чужого - имеет смысл сразу проговаривать не только что он делает, но и чего он не гарантирует. Переоценивать инструмент обхода блокировок - плохая идея. Человек, уверенный, что инструмент решает за него все смежные проблемы, обычно перестаёт думать про эти проблемы вообще.

Шифрование канала не заменяет сквозное шифрование

Данные внутри сети передаются в зашифрованном виде, шифрование стандартное, TLS, и мы как команда не можем их расшифровать.

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

Дело не в том, доверяете вы лично нашей команде или нет. У централизованного коммерческого VPN всё держится на одном операторе: вы верите ему на слово, а юрлицо и сайт с логотипом создают ощущение, что его хотя бы можно как-то проверить и проконтролировать. На практике снаружи это почти невозможно. У децентрализованной сети всё устроено иначе: единого поставщика услуги здесь просто нет, потому что трафик идёт через множество независимых узлов.

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

Транспортное шифрование защищает содержимое от чтения на отдельном узле. Но это ещё не означает, что никто в принципе не может следить за тем, как идёт трафик в сети. Гарантировать такое мы не можем и не пытаемся.

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

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

Звоните и переписывайтесь через мессенджеры со сквозным (E2E) шифрованием. Тогда тот, кто видит ваш трафик на одном из промежуточных узлов, увидит зашифрованный поток, а не содержимое разговора.

Телеграм таким мессенджером не является, что бы по этому поводу ни говорил Павел Дуров. Сквозное шифрование там не включено по умолчанию и доступно не для всех типов чатов, а серверная часть закрыта и непроверяема. Получается ровно та же проблема с необходимостью верить на слово, о которой мы говорили выше, только без даже видимости распределённости.

Используйте Signal, а для действительно важных разговоров - Matrix. У обоих открытый исходный код клиентов и протокол шифрования, который могут независимо проверять третьи стороны, а не просто декларация в описании приложения.

Мы работаем над собственным мессенджером Рататоск поверх той же сети именно потому, что инструмент обхода блокировок и инструмент защищённого общения решают разные задачи. Их нужно разрабатывать и проверять отдельно, а не сращивать в одно приложение, где проблемы одной части прикрываются хорошей репутацией другой.

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

Эксплуатационные логи и идентификация пользователя - не одно и то же

У нас есть логи по всей системе. Не логи содержимого - сами данные мы не логируем, - а логи событий, связанных с прохождением трафика: где что заблокировано, где какой узел отказал, откуда и куда идёт соединение на уровне метаданных.

Зачем это нужно и почему это не наша прихоть.

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

Мы физически не можем контролировать, что именно пользователи делают через наши туннели: ни через какие клиентские приложения, ни через какую политику. При этом инфраструктура физически размещена в конкретных юрисдикциях, а её эксплуатанты - реальные люди с реальной ответственностью перед законом этих юрисдикций.

Отвечать перед регуляторами за оборот наркотиков, торговлю людьми или подготовку терактов, которые кто-то мог провернуть через наши туннели, мы не готовы. Телеметрия о том, где и что происходит на уровне сетевых событий, - единственный способ показать, что сами мы в такой деятельности не участвуем и ей не помогаем, если возникнут вопросы.

Есть и вторая, более приземлённая причина. Мы находимся вне России, и единственный способ понимать в реальном времени, что и как блокируется внутри страны, - получать телеметрию от самих пользователей. Какие узлы у кого не отвечают, где какой протокол режется, какой оператор связи что делает сегодня.

Без этих данных мы бы просто не знали, что чинить и в какую сторону развивать сеть. Полностью анонимная система такой обратной связи нам не даст. Поэтому мы сознательно оставляем телеметрию, без которой сеть просто невозможно нормально поддерживать, даже если из-за этого Туннельный Котик нельзя считать средством анонимизации.

Если это не устраивает - это не наш продукт для вас. Лучше сказать это прямо, чем убеждать себя в обратном постфактум.

Если нужна анонимность как таковая - используйте специализированные средства для этого, отдельно от Туннельного Котика или поверх него, но не полагайтесь на него в этой части. Это не Tor и не Bublik. У нас нет ни архитектуры луковой маршрутизации, ни цели её строить.

Мы строим инструмент обхода блокировок, а не инструмент анонимности и не мессенджер с гарантированной приватностью. Это три разные задачи. Для каждой нужны свои технические решения, нужно отдельно понимать возможные угрозы и отдельно всё это проверять. Если пытаться одним продуктом решить сразу все три задачи, обычно получается плохо по всем трём.

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