Часть 3

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

9. Протокол связей TLS, пересогласование

Оригинальная версия Tor (первая) содержала непосредственную процедуру согласования TLS. Клиент говорил, что он поддерживает значительный набор криптографических алгоритмов и параметров (наборы шифров в терминологии TLS), а сервер выбирал один из них. Если одна сторона хотела доказать другой, что она являлась Tor узлом, ей нужно было посылать цепочку двухэлементого сертификата, подписанного ключом, опубликованным в директории Tor.

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

Стало очевидно, что изначальный дизайн Tor выглядел сильно отличающимся от HTTPS. Во-первых, веб-браузеры позволяют широкий спектр наборов шифров, такие как с использованием RC4 (из-за ограниченных требований к безопасности) и обмен ключами посредством RSA (за счёт отсутствия наперёд заданной секретности ). Во-вторых в HTTPS веб-трафике клиент редко владеет сертификатом и сервер обычно представляется цепочкой из одноэлементного сертификата, в то время как в Tor-коммуникациях "узел-узел" обе стороны представляются двухэлементой цепочкой сертификата.

Поэтому в предложении 124, впоследствии заменённом предложением 130, попытались решить ситуацию, что привело к реализации второй версии протокола соединений в Tor 0.2.0.20-rc. Теперь клиент предоставлял большой выбор наборов шифров (включая некоторые, которые он в действительности не поддерживает), выбираемых для того, чтобы выглядеть схожим с веб-браузером. Затем сервер выбирал один из наборов, адекватных для применения с Tor, но если сервер выбирал не адектватно безопасный, то клиент прекращал соединение.
Для того, чтобы сделать часть согласования более близкой к HTTPS, клиент не посылает никакого сертификата, а сервер посылает пустой сертификат с одноэлементой цепочкой. Сертификат, выданный серверу, создан так, чтобы не содержать никаких отличительных строк, которые могли бы быть использованы для блокирования (первая версия сертификатов использовала "Tor"или "TOR" в качестве имени организации). Как только согласование завершено, Tor начинает согласование заново (сквозь TLS-соединение), но уже зашифрованное ключами, установленными в ходе первого соединения и посылает двухсертификатную цепочку как и раньще.

Это значительно улучшило ситуацию в вопросе борьбы с блокированием, однако многое ещё оставалось недоделанным. В частности, факт пересогласования не скрывается от наблюдателя, поскольку часть TLS-сообщений (известных как записи), незашифрованы TLS и записи пересогласования отличаются по типу от записей данных. По этому, в последующей третьей версии протокола соединений, описанной в предложении 176 и выполненной в Tor 0.2.3.6-alpha, перенесли вторую стадию согласования в записи с данными, встроив внутреннее согласование во внешнее через совместное использование некоторого ключевого материала.

10. Взлёт и падение псевдодомена .exit

В Tor 0.0.9rc5 была добавлена опция использования .exit. За счёт этого, если пользователь запрашивал domain.nickname.exit, то Tor делал соединение с domain через использование Tor узла nickname в качестве последнего узла (если есть такая возможность). Это удобная возможность для изучения того, как в разных местах выглядит интернет, но это также вызвало некоторые опасения в безопасности.

В частности, злонамеренный вебсайт мог встроить картинку с именем .exit-хоста, принуждая клиента к выбору исходящего узла. контролируемого атакующим. Затем, если пользователь также выбирает контролируемый атакующим входящий узел, то его цепочка могла быть деанонимизирована. Такая стратегия повышала вероятность успешной атаки с примерно (M/N)² до M (где M — количество контролируемых атакующим сетевых ресурсов, а N — полные ресурсы сети).

Поэтому в Tor 0.2.2.1-alpha нотация .exit исключена по умолчанию. В Tor 0.2.3.17-beta сделано исключение, позволяющее нотацию .exit, если она определена в конфигурационном файле или посредством контроллера. Эти источники подразумеваются безопасными и при комбинировании .exit-нотации с опцией MapAddress для клиента возможно всегда осуществлять конакт с определёнными доменными именами через определённый исходящий узел. Это полезно, когда сервис запущен на той же самой машине, что и Tor-узел, так что клиент может выбрать цепочки, никогда не покидающие сеть Tor.

11. Протокол контроллера

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

Контролирующий протокол также оказался удачным для исследователей, экспериментирующих с Tor. Изначально функциональность, предоставляемая контролирующим протоколом была в соответствии с предоставляемой конфигурационным файлом и лог-файлами. Предоставление информации статуса в специфично-машинном формате сделало легче задачу мониторинга и контроля Tor. Затем в контрольный протокол была добавлена функциональность, которая не должна показываться рядовым Tor-пользователям, но пригодная для исследователей, такая как возможность посредством контроллера управлять процессом выбора пути (внедрено с 0.1.0.1-rc).

В 0.1.1.1-alpha протокол изменён до первой версии, которая использовала ASCII вместо двоичных команд, для того, чтобы сделать более лёгким написание и отладку контроллера, также как и позволить продвинутым пользователям использовать telnet для отправки комманд на контрольный порт вручную.

Назад | Оглавление