Часть 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, перенесли вторую стадию согласования в записи с данными, встроив внутреннее согласование во внешнее через совместное использование некоторого ключевого материала.

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