Tor часто описывают слишком просто: «браузер для анонимности», «вход в даркнет», «инструмент обхода блокировок». Формально всё верно, но такие описания почти ничего не объясняют.
Мне интереснее другое: что происходит между нажатием Enter в адресной строке и загрузкой страницы. Почему сайт не видит мой реальный IP. Почему провайдер видит факт подключения к Tor, но не видит сайт. Почему выходной узел опасен для HTTP. Почему Tor Browser не стоит превращать в обычный Firefox с двадцатью расширениями.
Разбираю именно механику.
Tor Browser и Tor — это разные слои одной системы
Tor Browser — это браузер на базе Firefox ESR, который настроен так, чтобы весь веб-трафик шёл через сеть Tor. Внутри там не только «прокси», а связка из браузера, Tor-клиента, настроек приватности, NoScript и набора патчей против отслеживания. Tor Project прямо описывает Tor Browser как Firefox ESR с изменениями для приватности и безопасности.
Сеть Tor — отдельная вещь. Это оверлейная сеть из ретрансляторов. Одни узлы принимают соединение от пользователя, другие гонят трафик внутри сети, третьи выпускают его в обычный интернет. В старых материалах это обычно рисуют как цепочку: клиент → охранный узел → промежуточный узел → выходной узел → сайт.
Суть Tor в том, что ни один узел цепочки не должен знать всю картину.
Охранный узел видит IP пользователя, но не знает, на какой сайт он идёт. Выходной узел видит сайт, но не знает IP пользователя. Промежуточный узел нужен как прослойка, чтобы вход и выход не оказались соседями в маршруте.
И вот тут начинается самый смак — лучок.
Почему маршрутизация «луковая»
Когда Tor-клиент строит цепочку, он не берёт три случайных сервера и не кидает через них обычный запрос к сайту. Сначала он договаривается о ключах с каждым узлом маршрута. Отдельно с guard-узлом, отдельно с промежуточным узлом, отдельно с выходным.
После этого запрос упаковывается в несколько слоёв шифрования. Отсюда и «луковая» маршрутизация.
Снаружи лежит слой для guard-узла. Он снимает только его и видит, куда передать данные дальше. Следующий слой может снять только промежуточный узел. Последний слой снимает выходной узел, после чего запрос уходит к сайту.
Это упрощённая схема. В реальности Tor работает не с «большими пакетами», а с ячейками фиксированного размера. Между узлами есть TLS-соединения, для цепочки согласуются ключи, а поток приложения режется на части. Но для понимания базовой идеи модель лука подходит: каждый узел снимает только свой слой и знает только соседей.
Отсюда важная мысль. Tor не делает каждый узел доверенным. Он делает так, чтобы один узел не видел всю картину.
Плохой guard-узел может узнать, что пользователь подключился к Tor. Неприятно. Но он не знает, какой сайт открыт в конце цепочки.
Плохой выходной узел может увидеть, куда уходит трафик после Tor. Если там HTTP, он может читать содержимое. Если HTTPS, содержимое защищает уже TLS. Но реальный IP пользователя выходной узел сам по себе не видит.
Проблема начинается, когда противник смотрит на оба края: соединение пользователя с guard-узлом и соединение exit-узла с сайтом. Тут речь уже не про взлом шифрования, а про корреляцию. Время, объём трафика, задержки, похожие всплески активности.
Tor снижает такие риски, но не отменяет физику сети. Если кто-то видит достаточно много точек наблюдения, у него появляется материал для анализа. Это неприятная часть модели угроз, о которой часто забывают в популярных объяснениях.
Как Tor выбирает узлы
После запуска Tor-клиенту нужна свежая карта сети. Он не берёт адреса узлов из случайного списка в интернете.
В Tor есть набор авторитетных директорий — directory authorities. Они голосуют за текущее состояние сети и публикуют общий consensus. Это документ со списком ретрансляторов: какие узлы доступны, какие давно работают, какие подходят для входа, какие могут быть выходными, каким узлам можно давать больше нагрузки.
Без такого каталога клиенту пришлось бы верить случайным IP-адресам. Плохая идея. Узел может притвориться нормальным, быть перегруженным, пропасть через минуту или вообще не подходить для нужной роли.
С guard-узлом отдельная история. Это первый узел в цепочке, и Tor выбирает его осторожно.
На первый взгляд кажется, что безопаснее постоянно менять вход в сеть. Сегодня один guard, завтра другой, потом третий. Больше перемешивания, больше анонимности. Логика понятная, но для Tor она опасная.
Если каждый раз брать новый первый узел, растёт шанс однажды попасть на узел наблюдателя. Поэтому Tor держится за ограниченный набор guard-узлов. Меньше разных входов — меньше попыток поймать пользователя на плохом входе.
Выходной узел подбирается по другой логике. Он должен подходить под нужное соединение и свою exit policy. Оператор exit-узла сам задаёт, куда он готов выпускать трафик. Один разрешает 80 и 443 порты, другой закрывает SMTP, третий вообще не работает как exit.
Выходные узлы получают больше жалоб, потому что для внешнего сайта именно они выглядят источником соединения. Пользователь сидит за цепочкой Tor, а сайт видит IP exit-узла. Вот почему не каждый оператор хочет брать на себя эту роль.
Что видят провайдер, сайт и узлы Tor
Самая частая ошибка — думать, что Tor делает пользователя невидимым для всех.
Нет. Он просто делит информацию между разными участниками цепочки.
Если пользователь подключается к Tor обычным способом, провайдер часто видит сам факт подключения. Он может видеть IP guard-узла, время соединения, объём трафика и сетевые признаки. С мостами и obfs4 всё менее прямолинейно, но магии всё равно нет: провайдер видит соединение, просто ему сложнее понять, что именно происходит.
Конкретный сайт внутри цепочки провайдер видеть не должен.
Обычный сайт в интернете видит IP exit-узла. Не реальный IP пользователя. Для сайта запрос как будто пришёл от Tor-выхода, и именно поэтому некоторые сайты режут Tor, кидают капчи или относятся к такому трафику подозрительно.
Guard-узел видит пользователя. Он знает, кто вошёл в Tor. Но он не знает конечный сайт.
Промежуточный узел видит только соседей по цепочке. Для него это просто передача дальше.
Exit-узел видит, куда уходит трафик из Tor. Если это HTTP, всё плохо: exit может читать и менять содержимое. Логины, формы, страницы, ответы сервера — всё проходит без защиты TLS.
Если это HTTPS, ситуация другая. Exit всё ещё видит, что соединение куда-то идёт. В зависимости от DNS, SNI, ECH и конкретной схемы он может видеть часть метаданных. Но содержимое HTTP-запросов и ответов он читать не должен. Его закрывает TLS.
Отсюда простой вывод: Tor Browser не заменяет HTTPS.
Tor скрывает маршрут. HTTPS защищает содержимое. Это разные задачи.
И есть ещё уровень выше — сам браузер и поведение пользователя. Реальный IP может утечь не потому, что «сломался Tor», а из-за внешнего приложения, документа, расширения, странной настройки или авторизации в личный аккаунт. Сетевой маршрут может быть скрыт идеально, но если пользователь сам вошёл в свой основной профиль, анонимность закончилась на уровне приложения.
Как строится цепочка
Tor-клиент открывает соединение с первым узлом и постепенно расширяет цепочку. Он не отдаёт охранному узлу готовый список всего маршрута в открытом виде. Клиент говорит входу: «соедини меня со следующим узлом», потом через уже созданный участок договаривается со вторым узлом, потом через два участка договаривается с третьим.
Это похоже на сборку тоннеля изнутри. Каждый новый участок добавляется так, чтобы предыдущие узлы не получили лишней информации.
Дальше браузер отдаёт запрос Tor-клиенту через локальный SOCKS-прокси. Tor-клиент режет поток на ячейки, шифрует их под цепочку и гонит по маршруту. На выходе ячейки снова собираются в TCP-поток к нужному сайту.
Тут есть неприятный компромисс: Tor — сеть низкой задержки. Он нужен для интерактивного веба, где страница должна открываться сейчас, а не через полчаса. Поэтому Tor не может просто перемешивать пакеты часами, как теоретическая mix-сеть. Скорость лучше, а защита от корреляции по времени хуже.
Tor не магическая «анонимная труба». Он постоянно торгуется с реальностью: задержка, пропускная способность, число пользователей, число узлов, устойчивость к блокировкам, удобство браузера.
Почему Tor Browser борется с отпечатком браузера
Допустим, сетевой уровень сработал. Сайт видит IP выходного узла. Хорошо.
Но сайт может попытаться узнать пользователя по браузеру. Размер окна, список шрифтов, язык, часовой пояс, canvas, WebGL, доступные API, поведение JavaScript, особенности рендера. Это называется browser fingerprinting. Цель защиты Tor Browser — сделать пользователей похожими друг на друга, а не дать каждому идеально «замаскированный» уникальный профиль.
Поэтому Tor Browser стандартизирует и ограничивает часть параметров. Например, он использует letterboxing: добавляет поля вокруг страницы, чтобы размеры окна попадали в более грубые корзины. Это снижает ценность отпечатка по разрешению экрана. Tor Project отдельно описывает такие меры: ограничение перечисления шрифтов, стандартизацию размеров окна, уменьшение разнообразия языковых настроек.
Отсюда практический вывод: когда пользователь начинает «улучшать» Tor Browser расширениями, темами, нестандартными настройками и полноэкранным режимом, он часто делает себя заметнее. Не потому что расширение обязательно вредное. Просто оно добавляет отличия.
В обычном браузере приватность часто строится вокруг блокировки трекеров. В Tor Browser идея грубее и строже: быть похожим на других пользователей Tor Browser.
Почему JavaScript в Tor — больная тема
JavaScript нужен современному вебу. Без него половина сайтов либо ломается, либо превращается в музей.
Но JavaScript расширяет поверхность атаки. Через него можно собирать отпечаток браузера, проверять особенности среды, пытаться эксплуатировать уязвимости движка, связывать действия между вкладками. Поэтому в Tor Browser есть уровни безопасности. Чем выше уровень, тем больше режется активный контент.
Это не делает браузер «абсолютно безопасным». История браузеров вообще показывает, что сложный JS-движок — жирная цель. Tor Browser снижает риск, но остаётся браузером. Он парсит HTML, CSS, JS, изображения, шрифты, видео. Каждый парсер — код. Код иногда ломается.
Мосты: когда Tor блокируют на входе
Публичные узлы Tor можно скачать списком. Это нужно для работы сети, но цензор может взять тот же список и заблокировать подключение к guard-узлам. Старые статьи про Tor часто объясняют это через две стратегии блокировки: блокировать выходы Tor на стороне сайтов или блокировать вход пользователей в сеть Tor. В приложенном PDF эта проблема описана через публичность списка узлов и переход к мостам как решению для доступа из-за цензуры.
Мосты — это непубличные входы в сеть Tor. Они не публикуются в обычном consensus-документе как стандартные ретрансляторы. Пользователь получает несколько мостов и подключается через них.
Но просто «секретный IP» уже слабая защита. Цензор может искать характерный Tor-трафик через DPI. Поэтому появились pluggable transports — сменные транспортные обёртки, которые меняют внешний вид соединения. Tor Browser сейчас использует Lyrebird для таких транспортов, включая obfs4, meek, Snowflake и WebTunnel.
Смысл у них разный.
obfs4 пытается сделать трафик менее похожим на Tor и усложнить активное сканирование мостов.
Snowflake использует временных прокси-добровольцев и WebRTC. Это постоянно меняющаяся поверхность, цензору сложнее просто составить список IP и закрыть тему.
meek исторически использовал идею domain fronting, когда трафик выглядел как обращение к крупной платформе. Сейчас с этим сложнее, потому что крупные провайдеры меняли правила.
WebTunnel маскирует соединение под обычный HTTPS-трафик к веб-серверу. Это уже игра в похожесть на нормальный веб, но цензоры тоже не стоят на месте.
Onion services: когда сайт тоже прячется
Обычный сценарий Tor такой: пользователь скрывает свой IP от сайта, но сайт находится в обычном интернете. У него есть IP, хостинг, дата-центр, DNS.
Onion service работает иначе. Сайт живёт внутри Tor, его адрес заканчивается на .onion, а реальный IP сервера не раскрывается клиенту. В v3 onion services используется схема с introduction points, onion service descriptors, HSDir и rendezvous point. Официальная спецификация Tor описывает роли hidden service directory, introduction point и rendezvous point именно для этой схемы.
Грубо говоря, процесс выглядит так:
Сервис заранее выбирает несколько introduction points и публикует подписанный descriptor в распределённой директории. Клиент, зная .onion-адрес, находит descriptor, выбирает rendezvous point и через introduction point передаёт сервису приглашение встретиться. Сервис строит свою цепочку к rendezvous point. Клиент уже имеет свою цепочку к тому же rendezvous point.
В итоге клиент и сервис общаются через точку встречи. Rendezvous point не знает, где физически находится сервис, и не знает реальный IP клиента. Он просто пересылает зашифрованные данные между двумя Tor-цепочками. Официальное объяснение Tor Community описывает похожую последовательность: introduction point передаёт сервису данные клиента и адрес rendezvous point, после чего сервис решает, подключаться ли к этой встрече.
Тут появляется цена. Onion service обычно медленнее обычного сайта через Tor, потому что маршрут длиннее: цепочка клиента плюс цепочка сервиса. Зато сервер не светит IP.
Где Tor реально силён
Tor хорошо решает несколько задач.
-
Скрывает реальный IP пользователя от сайта.
-
Мешает провайдеру видеть конкретные сайты, которые открывает пользователь.
-
Помогает обходить сетевую цензуру, особенно с мостами и транспортами.
-
Даёт инфраструктуру для onion services, где скрывается не только клиент, но и сервер.
-
Снижает связность между сессиями за счёт настроек Tor Browser, изоляции и борьбы с fingerprinting.
Для журналистов, исследователей, активистов, обычных пользователей в жёстких сетях это серьёзная вещь. Не потому что нужен «даркнет», а потому что доступ к информации иногда сам по себе становится технической задачей. DW в материале 2024 года как раз пишет о продолжающихся спорах вокруг безопасности Tor и давления на инфраструктуру даркнета, хотя сам Tor остаётся одним из главных инструментов анонимного доступа.
Где Tor слаб
Tor не спасает от добровольной деанонимизации. Если зайти в личный аккаунт, написать свой номер телефона, загрузить документ с метаданными или открыть ссылку из личной почты, сеть уже мало поможет.
Tor не гарантирует защиту от глобального наблюдателя. Если противник видит входящий трафик пользователя и исходящий трафик с выходного узла, он может пытаться коррелировать события. Исследования по website fingerprinting показывали, что даже зашифрованный Tor-трафик можно классифицировать по времени и объёму пакетов, хотя практическая применимость зависит от модели атакующего и условий эксперимента.
Tor не защищает содержимое HTTP от выходного узла. Тут нужен HTTPS.
Tor не любит BitTorrent. Торренты шумные, создают нагрузку, часто палят IP через DHT, UDP, трекеры и клиентские особенности. В старых популярных материалах можно встретить фразу, что P2P-приложения можно настроить на Tor, но для реальной приватности это плохая идея: слишком много путей для утечки, слишком много трафика, слишком мало пользы для сети.
Tor Browser не стоит превращать в персональный комбайн. Расширения, нестандартные настройки, логины в личные аккаунты, скачанные документы, открытые вне изолированной среды — всё это ломает модель «быть похожим на остальных».
Что происходит при смене личности
В Tor Browser есть New Identity. Пользователь нажимает кнопку, браузер закрывает вкладки, очищает состояние, сбрасывает цепочки. Идея простая: новая активность не должна связываться со старой.
Но тут есть тонкость. Сетевая цепочка это только часть состояния. Есть куки, кэш, localStorage, IndexedDB, HSTS, состояние расширений, процессы браузера, отпечаток среды. Tor Browser годами режет такие связи, но браузер — огромная программа. Уязвимости в механизмах изоляции иногда появляются даже в проектах, которые строятся вокруг приватности. Поэтому дисциплина пользователя остаётся частью модели безопасности.
Я бы формулировал так: Tor Browser делает безопасное поведение проще, но не делает опасное поведение безопасным.
Почему Tor медленнее обычного браузера
Потому что запрос идёт не напрямую.
Обычный браузер строит соединение с сайтом или CDN рядом с пользователем. Tor гонит трафик через несколько добровольных узлов, часто в разных странах. Каждый участок добавляет задержку. Пропускная способность ограничена самым слабым местом цепочки. Выходные узлы перегружены сильнее, потому что их меньше и на них больше юридического давления.
Есть криптография, но она не главный тормоз. Основная цена — маршрут, задержки, очереди, добровольная инфраструктура.
Поэтому Tor плохо подходит для тяжёлого медиапотребления, больших загрузок и постоянного фонового трафика. Он рассчитан на приватный веб-доступ, а не на замену домашнего гигабитного канала.
Итог
Tor Browser — это не «браузер с другим IP». Это аккуратно собранная система из сетевой анонимизации, настроек браузера, защиты от отпечатков, изоляции состояния, мостов и транспортов для обхода цензуры.
Луковая маршрутизация решает главную задачу: разделяет знание между узлами. Вход знает пользователя, выход знает сайт, середина разрывает прямую связь. Tor Browser добавляет к этому прикладной слой: делает пользователей похожими друг на друга и режет механизмы веб-трекинга.
Слабые места никуда не исчезают. Выходные узлы опасны для HTTP. Fingerprinting остаётся гонкой. Корреляция трафика возможна для сильного наблюдателя. Поведение пользователя иногда деанонимизирует быстрее любой атаки.
Но сама архитектура Tor всё равно красивая. Она честная: не даёт гарантий, а раскладывает доверие по кускам. И именно поэтому работает уже много лет.
Спасибо всем большое, что дочитали статью до конца! Буду рад видеть вас в своём Telegram-канале, там я продолжаю разбирать темы, связанные с кибербезопасностью: цифровая гигиена, приватность, деанон, антифрод, OSINT, реальные схемы атак и всё, что помогает лучше понимать угрозы вокруг себя.
ссылка на оригинал статьи https://habr.com/ru/articles/1034854/