Скрытый сервис Tor: как поднять .onion-сайт, v3-адрес и типичные утечки

Что такое скрытый сервис Tor на самом деле

Скрытый сервис Tor — это сервер, который никому и никогда не сообщает о своём местонахождении. Вместо того чтобы опубликовать адрес в DNS и ждать входящих соединений, он сам строит исходящие цепочки через сеть Tor к нескольким узлам, которые выбирает в качестве точек представления, и публикует подписанный дескриптор с сообщением: «того, кто владеет этим ключом, можно найти через эти узлы». Клиент, которому известен адрес, получает этот дескриптор, выбирает третий узел в качестве точки встречи и просит точку представления передать запрос на встречу там. Обе стороны строят собственную цепочку к точке встречи, и ни одна из них никогда не узнаёт IP-адрес другой — просто потому, что его никто ей не сообщает.

Самое интересное — сам адрес. v3-адрес onion — это 56 символов в base32 плюс .onion, и это не имя, указывающее на ключ, — это и есть ключ: закодированные открытый ключ ed25519, контрольная сумма и байт версии. Здесь нечего искать и нечему доверять на веру. Когда клиент подключается, полученный им дескриптор подписан именно этим ключом, так что адрес аутентифицирует сервис по самой своей конструкции. Удостоверяющий центр не участвует, никто не может выпустить сертификат на ваш адрес, и не существует журнала прозрачности, фиксирующего сам факт существования сервиса. Если хотите разобраться в полном рукопожатии, стоит прочитать спецификацию rendezvous.

Этот список и есть вся ценность технологии, и он же объясняет, кто именно её использует. Экземпляры SecureDrop в редакциях — это скрытые сервисы именно потому, что источник не обязан доверять DNS. Debian зеркалирует свой архив через скрытый сервис, чтобы сам факт обновления пакета не выдавал адрес назначения. Несколько очень крупных потребительских платформ публикуют такой адрес, чтобы пользователи в подцензурных сетях могли достучаться до них без заблокированного IP посередине. Ничего экзотического в этом нет — это транспорт с другим набором гарантий.

Что защищает скрытый сервис Tor, а что — нет

Гарантия протокола узкая, но прочная: сетевой уровень не раскрывает, где именно работает сервис. Противник, способный наблюдать за значительной частью интернета, всё равно не может сопоставить ваш адрес с конкретной машиной, потому что здесь просто нет этапа разрешения адреса, за которым можно было бы наблюдать. Хостинг-провайдеру невозможно предъявить адрес и спросить, какому клиенту он принадлежит, потому что на стороне провайдера этого никто не знает. Сканеры не находят сервис, потому что он не отвечает ни на одном публичном порту. А атаке, которая обрушила бы обычный сайт, попросту некуда бить — поэтому эта тема всплывает в разговорах о защите от DDoS не реже, чем в разговорах о приватности.

Всё, что выше сетевого уровня, всё ещё можно испортить самостоятельно, и именно здесь разворачивается настоящая история деанонимизаций. Сервисы находили потому, что приложение печатало трассировку стека с реальным именем хоста, потому что тот же веб-сервер отвечал на публичном IP идентичной страницей, потому что на той же машине был установлен сертификат другого домена оператора, потому что изображение несло в метаданных GPS-координаты, потому что машина отправляла почту через открытый интернет, или потому что открытый всему миру статус-эндпоинт выдавал собственный адрес сервера. Tor во всех этих случаях сделал свою работу. Человек над ним — нет.

Поэтому держите в голове сразу две мысли. Транспорт надёжен и остаётся таким уже много лет; считать его слабым звеном — значит неверно читать историю реальных расследований. И этот транспорт же — лёгкая половина задачи: трудная половина — это дисциплина в отношении всего, что машина говорит и делает, чему и посвящена большая часть этого руководства. Если вы здесь из-за более широкого вопроса о том, насколько прослеживаем арендованный сервер, хорошим дополнением к этой странице будет честный ответ на него.

Как поднять скрытый сервис: две директивы и перезапуск

Конфигурация на удивление короткая, что удивляет тех, кто ждёт какого-то ритуала. Установите демон tor, затем добавьте в torrc две директивы: HiddenServiceDir — она задаёт каталог, который Tor создаст и будет им владеть, — и HiddenServicePort, которая связывает виртуальный порт, к которому будут обращаться клиенты, с локальным адресом, на котором слушает ваше приложение. Перезапустите демон — и Tor сгенерирует пару ключей ed25519 и запишет ваш адрес в файл hostname внутри этого каталога.

Самая частая ошибка описана в третьей строке. Веб-сервер по умолчанию слушает на 0.0.0.0, а это значит — публичный IPv4-адрес, а обычно и IPv6 тоже. Поставьте перед ним скрытый сервис — и вы уже отдаёте одни и те же байты в двух местах, одно из которых индексируют все сканеры интернета подряд. Тому, кто сравнит хеш страницы, favicon, ETag или характерную страницу ошибки, хватит секунд, чтобы связать их между собой. Привяжитесь к 127.0.0.1 и проверьте это командой ss -ltnp, а не просто поверьте на слово — проверка занимает пять секунд, а предположение стоило людям всего.

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

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

v3-адреса, vanity-префиксы и фишинговая проблема, которую они создают

Если в руководстве, которое вы читаете, упоминаются 16-символьные адреса, речь идёт о протоколе, которого больше не существует. Скрытые сервисы версии 2 использовали 80-битные хеши RSA-1024 — достаточно короткие, чтобы быть удобными, и достаточно слабые, чтобы быть проблемой; вдобавок их можно было перечислить, поскольку любой, кто держал директорийный узел, мог собирать проходившие через него адреса. Tor Project объявил график отказа от v2 в 2020 году, отключил v2 в ветке 0.4.6 в июле 2021 года и полностью удалил код в октябре того же года. Адреса версии 3 состоят из 56 символов, построены на ed25519 и больше не утекают через директорийные узлы.

За это приходится платить длиной, и именно поэтому существуют vanity-адреса. Такие инструменты, как mkp224o, массово генерируют пары ключей и оставляют те, чей адрес начинается с выбранного префикса. Это ничего не ослабляет: вы не ограничиваете ключ, а отбраковываете кандидатов, пока один из них случайно не закодирует нужные буквы, и уцелевший ключ ровно так же силён, как и любой другой. Платить приходится временем, и цена растёт экспоненциально — каждый дополнительный символ умножает объём работы на 32, так что четырёхсимвольный префикс подбирается мгновенно на ноутбуке, шесть-семь символов — это уже часы работы машины, а десять становятся серьёзным предприятием. Полный 56-символьный адрес методом перебора не берёт никто — в этом и весь смысл пространства поиска.

Настоящая опасность — зеркальное отражение этого удобства. Если узнаваемый префикс помогает пользователям опознать вас, он точно так же помогает кому-то другому сгенерировать похожий адрес и выставить его на фишинговой странице, ведь человек на деле проверяет лишь те восемь символов, что он читает. Защищайте адрес так же, как всегда защищали отпечатки ключей: публикуйте полный адрес в нескольких независимых местах, подписывайте его ключом, который у людей уже есть, добавьте его в заголовок Onion-Location вашего сайта в обычном интернете, если он у вас есть, и прямо заявите, что никогда не объявите новый адрес только через социальные сети. Vanity-префикс — это удобство использования, а не аутентификация.

Поверхность утечек, которая реально деанонимизирует сервисы

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

Две из этих причин стоит выделить особо — они подводят даже осторожных людей. Первая — исходящий трафик: машина, которая никогда не принимает соединения, всё равно может выдать себя, установив соединение сама. Обновления пакетов — это нормально и неизбежно; а вот агент мониторинга, отчитывающийся на панель, привязанную к вашему имени, — уже нет, как и приложение, отправляющее письма для сброса пароля через открытый интернет с машины, чей единственный смысл существования — оставаться ненайденной. Вторая причина — SSH host key. Повторное использование одного и того же ключа на разных машинах кажется аккуратной привычкой, но создаёт постоянную, легко находимую криптографическую связь между двумя серверами, которые должны были оставаться никак не связанными.

Проводите аудит как посторонний, а не как оператор сервиса. Откройте сервис в Tor Browser на машине, которая никогда не имела отношения к проекту, прочитайте все заголовки ответа, намеренно вызовите ошибку, просмотрите исходный код страницы, как будто её писали не вы, и понаблюдайте за панелью сети — не запрашивает ли страница что-то ещё извне. Затем сядьте у сервера и понаблюдайте, что уходит с него в течение целых суток. То, что вы найдёте за эти сутки, и есть вся суть этого руководства.

Авторизация клиентов: сервис, доступный только избранным

Существует режим, о котором мало кто знает, и это, пожалуй, самая изящная деталь всего протокола. При использовании авторизации клиентов дескриптор, который публикует ваш сервис, шифруется на набор открытых ключей x25519, которые вы сами назначаете. Клиент без соответствующего закрытого ключа не может даже расшифровать дескриптор, а значит, не может узнать точки представления, а значит, не может подключиться — и даже не может подтвердить, что там вообще что-то есть. Вы кладёте открытые ключи клиентов в каталог authorized_clients рядом с ключами сервиса, по одному файлу на клиента, и перезапускаете демон.

Сравните это с обычными способами ограничить доступ. Белый список IP требует заранее знать, где находятся ваши пользователи, и оставляет сервис отвечающим в интернете — его по-прежнему может просканировать и снять отпечаток кто угодно ещё. Базовая HTTP-аутентификация оставляет на виду форму входа, которая сама объявляет, что здесь что-то есть. VPN добавляет целую вторую систему, которую нужно поддерживать, да ещё и со своим адресом, который тоже можно раскрыть. Авторизация клиентов убирает сервис из поля зрения всех, кого нет в списке, — а это принципиально другое свойство: не запертая дверь, а отсутствие двери как таковой.

Естественнее всего это подходит для административных интерфейсов. Разместите публичный сайт на обычном скрытом сервисе, а панель администратора, дашборд метрик, консоль базы данных и точку входа SSH — за отдельными авторизованными сервисами, и те части вашего развёртывания, которые иначе непрерывно прощупывали бы сканеры, просто невозможно будет найти. Цена — распространение ключей: каждому клиенту нужно установить свой закрытый ключ в конфигурацию Tor, что вполне приемлемо для горстки операторов и непрактично для публичной аудитории. Используйте этот режим там, где аудиторию можно пересчитать по пальцам.

Задержки, отказоустойчивость и честные компромиссы

Onion-соединение проходит через шесть узлов: три выбирает клиент, три — сервис, и они встречаются посередине. Это и есть плата за то, что ни одна из сторон не знает другую, и проявляется она в задержке, а не в пропускной способности — первый байт идёт медленно, а дальнейшая скорость передачи обычно вполне приемлема. Проектируйте с учётом этого: меньше циклов запрос-ответ, агрессивное кеширование, никаких «болтливых» цепочек запросов, никакой страницы, которой нужно одиннадцать вложенных ресурсов, прежде чем она отрисуется. Сайт, которым приятно пользоваться через скрытый сервис, — это, как правило, сайт, который изначально хорошо спроектирован.

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

Отказоустойчивость заслуживает отдельного замечания, потому что наивный подход здесь не работает. Нельзя просто скопировать ключевой материал на вторую машину и запустить обе — два сервиса, публикующих дескрипторы для одного и того же адреса, начинают конфликтовать за директорию, и клиенты попадают то на один, то на другой непредсказуемо. Именно для этого существует OnionBalance: фронтенд-инстанс держит публичный адрес и публикует дескриптор, указывающий на точки представления нескольких бэкенд-сервисов, у каждого из которых свой ключ. Бэкенды можно пересобирать или переносить по одному, и адрес при этом никогда не меняется.

Скрытый сервис рядом с обычным сайтом

Немало скрытых сервисов — это просто второй парадный вход к тому, что и так уже существует открыто, и это совсем другая задача, чем сервис, чьё местоположение должно оставаться тайной. Решите, какую из двух задач вы решаете, прежде чем писать хоть строку конфигурации, потому что они требуют противоположных вещей. Если цель — устойчивость к цензуре для сайта, который и так все знают как ваш, связка двух адресов — это как раз и есть нужная функция: опубликуйте заголовок Onion-Location на сайте в обычном интернете, и Tor Browser сам предложит посетителям onion-адрес. Если же цель в том, чтобы никто не знал, где работает сервис, тогда любая связь между двумя адресами — это утечка, и правильное их количество равно нулю.

Именно полумера и подводит людей. Запускать оба сайта с одной машины, с одной базой данных, с одним доменом для сессионных cookie и одним набором загружаемых файлов — уговаривая себя, что аудитории всё равно разные, — значит, что одна-единственная ошибка конфигурации обрушивает всё разделение, и вы узнаете об этом не раньше, чем кто-то другой. Если оба сервиса должны существовать и при этом не должны быть связаны, это два разных развёртывания на двух машинах с двумя независимыми наборами учётных данных, и операционные издержки на это — и есть цена того свойства, которое вам было нужно.

Один практический совет, если вы всё же связываете два адреса: держите сессии и cookie привязанными к конкретному хосту. Пользователь, который вошёл на сайте в обычном интернете, а затем зашёл через onion-адрес, должен получить свежую сессию, а не общую с прежней, — иначе вы построили механизм, который сопоставляет оба визита для любого, кто видит хотя бы один из них. И отдавайте onion-адресу собственные канонические ссылки, чтобы сайт «заботливо» не перенаправлял пользователя Tor Browser обратно на тот хост в обычном интернете, которого он сознательно избегал.

Что на стороне хостинга должно быть сделано правильно

Требования здесь необычные, поэтому обычный хостинг зачастую подходит плохо. Вам нужен беспрепятственный исходящий путь в сеть Tor, потому что это единственный тип соединения, которое устанавливает ваш сервис; некоторые провайдеры попросту фильтруют трафик директорийных и ретрансляционных узлов Tor, и вы обнаружите это по тому, что сервис так и не публикует дескриптор. Вам нужен провайдер, чья политика допустимого использования упоминает Tor письменно, а не обходит его молчанием, — потому что молчание превращается в письмо о блокировке аккаунта при первой же жалобе на что-то совершенно постороннее. Вам не нужен ни стабильный IP, ни домен, ни сертификат, ни хоть один входящий порт — а значит, почти всё, чем хостинговые компании обычно кичатся, здесь просто не имеет значения.

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

На BitVPS Tor разрешён письменно — в равной мере ретрансляторы, мосты, выходные узлы и скрытые сервисы, а случай с выходными узлами отдельно задокументирован на странице о злоупотреблениях, а не оставлен на волю случая. Страница о хостинге Tor описывает подбор ресурсов для ретрансляторов; скрытым сервисам требуется меньше. На практике тариф Growth за $13.50 с 4 vCPU, 8 ГБ ОЗУ и безлимитным каналом тянет серьёзный скрытый сервис с запасом под приложение за ним, а тарифа Starter за $8.50 достаточно для небольшого. Выбирайте локацию исходя из её юридической позиции, а не задержки: шесть хопов делают разницу между близким и далёким дата-центром почти незаметной.

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

Где проходит граница

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

Чего эта технология точно не делает — не меняет сами правила. Провайдер, игнорирующий уведомления об авторских правах, — а мы именно так и поступаем, как объясняется в том руководстве, — всё равно реагирует на материалы о сексуальном насилии над детьми и на достоверные угрозы людям, причём реагирует быстро: заявленное окно реакции — четыре часа для этих случаев против сорока восьми для всего остального. Это не лазейка в остальном либеральной политике — это и есть политика, и никакой транспорт её не меняет. Политика допустимого использования короткая, и её стоит прочитать до начала работы, а не после.

Ещё одно честное замечание: анонимность — это свойство всей системы, а не товар, который можно купить. Адрес скрывает машину, но не скрывает платёжный след, повторно используемый пароль, стиль письма, домен, который вы зарегистрировали много лет назад на тот же email, или скриншот с путями вашей собственной файловой системы на нём. Если модель угроз серьёзная, транспорт — самая лёгкая её часть, и именно на неё вы потратите меньше всего времени. Более широкий разбор охватывает остальные звенья этой цепочки, а объяснение про bulletproof-хостинг — полезное противоядие от маркетинга, который окружает всю эту тему.