id: Гость   вход   регистрация
текущее время 10:38 20/08/2018
Владелец: unknown (создано 05/11/2012 15:52), редакция от 25/01/2013 17:56 (автор: SATtva) Печать
Категории: софт, анонимность, tor
создать
просмотр
редакции
ссылки

Часть 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)2 до M/N (где 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 для отправки команд на контрольный порт вручную.

12. Torbutton


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


Затем стало ясно, что очистка протоколов нужна и Tor стал рекомендовать Privoxy для использования в качестве прокси для приложений HTTP. Однако, недостаток такого решения ясно очевиден, в частности Privoxy не может проверять и модифицировать HTTPS трафик, так что злонамеренные веб-сайты могли посылать свой трафик черех HTTPS и избегать его очистки.


В последствии, всё больше и больше очисток было выполнено в приложении Firefox, Torbutton, которое также позволяло включать и выключать Tor, в соответствии со своим именем. Torbutton имел полный доступ к содержимому, неважно относилось ли оно к HTTP или HTTPS и отключал нежелательные для приватности опции Firefox. Прокси всё ещё был нужен, поскольку поддержка SOCKS в Firefox плохо обслуживала медленные соединения, так что вместо Privoxy было применено более легковесное Polipo.

13. Tor Browser Bundle


Теперь для использования Tor большинству пользователей стало нужно загружать и инсталлировать Tor, Firefox, Torbutton и Polipo, вероятно с одним из GUI-контроллеров, таким как Vidalia. Это стало неудобным, особенно для пользователей интернет-кафе, которые не инсталлируют программы на используемый ими компьютер. Так что TorBrowser стал включать всё необходимое ПО в связку Tor Browser Bundle, сконфигурированное с возможностью запуска с USB-носителя.


Это облегчило использование, по сравнению с предыдущим способом работы с Tor и в конечном счёте стало таковым по умолчанию. За счёт этого появилось преимущество в возможности включать патчи в TorBrowser, которые сделали использование Polipo ненужным и решили некоторые проблемы приватности, которые не могли бы иначе быть решены с помощью дополнений Firefox. Это также стало безопасным для пользователя, поскольку теперь Torbutton не может быть отключена, означая, что пользователь, имеющий различные веб-браузеры для анонимного и неанонимного просмотра с меньшей вероятностью сможет их перепутать.


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


 
Один комментарий [показать комментарии/форму]
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3