Не совсем, атакующий должен иметь возможность изменять форму нешифрованного трафика между точкой назначения и exit node и читать трафик между entry node и пользователем.
Ваш вариант атаки тоже возможен, но менее интересен практически.
Не может быть полной случайности и непредсказуемости данных на неслучайном потоке данных. Если сервер передает большой кусок данных — принимающая сторона должна получить большой кусок данных ровно в то же самое время. Если вы хотите этот кусок сокрыть — придется постоянно передавать большие куски данных.
Поддержка «онлайнового» просмотра загруженного видео пока только в разработке, но могу сказать что потребление процессора на нужды SSL не превышает 2%, на мобильных клиентах процент может быть немного выше, но все равно не критический.
Накладные расходы есть, но при правильной организации их можно минимизировать. Мы тоже боялись что не справимся по нагрузкам, но на практике потребление ресурсов оказалось не таким страшным. Вот здесь статья, как почта переводилась на SSL.
SSL используется и в Облаке, где трафик передается десятками гигабайт, в том числе в мобильных клиентах, к явным проблемам с быстродействием это не приводит.
Не любая, для этого надо получить соответствующий consensus flag «Guard». Т.е. при желании сделать это возможно (поэтому и «относительно»), но просто так поднять у себя на домашнем компе tor и объявить себя entry node не получится.
VPN точно так же передает «форму» трафика и тайминги, это особенность большинства сетей low latency. Если я отправляю маленький пакетик раз в секунду — будет приходить минимальный возможный пакет раз в секунду. Если я отправляю большой бёрст трафика — будет приходить большой бёрст трафика.
Никто и не даст поднять на вашем компе entry node, т.к. entry node в tor — ограниченный список (относительно) доверенных узлов.
Вы поднимаете у себя клиента tor и идете на entry node, который, как правило, находится в другой стране. Трафик можно слушать везде, по пути от вас (клиента) до entry node и пассивный доступ к этому трафику имеет и оборудование СОРМ у вашего провайдера и соответствующее оборудование в той стране, где располагается entry node. Т.е. возможность слушать этот трафик имеет даже и не одна спецслужба, а несколько.
Смотря что для вас актуально — сама возможность атаки или практическая реализация на конкретном оборудовании. На внутренних ресурсах и корпоративных сетях построенных на арендуемых каналах нет оборудования СОРМ.
В принципе проблема актуальна везде, где трафик проходит через две точки, в одной из которых возможна его маркировка а в другой прослушивание и где такая возможность что-то дает атакующему. Про i2p и практичность атак чуть выше говорили — пока есть хоть какая-то возможность менять форму выходного сигнала — есть и возможность его маркировать, но на практике реализовать гораздо сложнее.
На уровне протокола не очень эффективное сокрытие, т.к. «подозреваемые» все равно есть и выбрать из них того, кто реально запрашивал трафик относительно просто. А в случае именно с tor получатель обнаруживается и без этого условия, т.к. получает трафик от известного списка entry node.
А если делать такой финт «по собственной инициативе» и подставлять кого-то другого — так проще воспользоваться соседским WiFi.
Вариант с сохранением фиксированной полосы канала работает, он как раз был в конце статьи описан. Но надо понимать, что любое затухание/набор скорости — это уже бит информации.
А вот со стороны сайта делать какие-то действия бесполезно — атакующий все равно может эти данные перешейпировать по-своему.
В I2P я не смотрел, т.е. атака частично компенсирована, но опять же — если у нас есть, например, 4 различимые скорости и мы можем, скажем, раз в минуту между ними переключаться — значит можно передавать 2 бита в минуту, надо только найти способ скрытно сохранять канал достаточно долго и пихать туда трафик так, чтобы со стороны клиентского приложения это не вызывало подозрений. Это возможно в большинстве прикладных протоколов.
Конечно, при таких условиях атака гораздо менее практична, т.к. такие темплейты гораздо сложней распознать в массовом трафике, чем последовательность пакетов определенного размера от известных entry node, чтобы «взвести» оборудование и начать анализировать трафик именно этой сессии.
Атака в целом работает с прокси, не работает только передача маркировки через полузакрытое соединение, когда маркировку можно передать скрытно от клиентского приложения, не затрагивая передачу реальных данных. Именно потому, что прикладной шлюз одновременно является и клиентом и сервером. Клиент не считает«скрытых» данных — соответственно и не передаст их в сервеную часть и дальше следующему клиенту.
С UDP все даже легче, т.к. в нем Нагла нет. Т.е. потеря возможности управлять размером пакетов с лихвой компенсируется очень прогнозируемыми таймингами.
В действительности скорость передачи данных очень сильно скачет. Например, в HTTP через одно соединение проходит несколько запросов, между которыми могут быть паузы порядка десятков секунд. А в мессенджерах, терминальных сессиях и т.п. трафик вообще рандомно ходит в любом направлении.
Да-да. Много вариантов, можно и свой баннер на конкретный сайт за деньги повесить, и шейпить отдачу баннера. От рекламных денег никто ж не отказывается.
А еще год назад на одной из выставок (не помню — или Zero Nights или PHD) показывали активное оборудование СОРМ, которое встает в разрыв между абонентской сетью и интернетом и умеет шейпить трафик. Exit node под контролем такого оборудования — это готовое условие для атаки. И не факт что в других странах уже не так.
Нет, к сожалению не поможет, это то же самое что datacompboy предлагает выше. К тому же, с точки зрения реализации, это классическая атака slow read, она приведет к увеличению потребления ресурсов на entry node.
В случае двуглавого орла получатель ID это оборудование СОРМ, в случае других орлов — его аналоги. Т.е. если спецслужбы захотят знать, кто посещает, например, сайты определенной тематики, им достаточно промаркировать часть трафика от этих сайтов вблизи этих сайтов (если они на подконтрольной территории) или на exit node'ах и на оборудовании отслеживать получателей маркировки. Там где маркировка вошла и не вышла — там и конечный получатель.
Ваш вариант атаки тоже возможен, но менее интересен практически.
SSL используется и в Облаке, где трафик передается десятками гигабайт, в том числе в мобильных клиентах, к явным проблемам с быстродействием это не приводит.
Вы поднимаете у себя клиента tor и идете на entry node, который, как правило, находится в другой стране. Трафик можно слушать везде, по пути от вас (клиента) до entry node и пассивный доступ к этому трафику имеет и оборудование СОРМ у вашего провайдера и соответствующее оборудование в той стране, где располагается entry node. Т.е. возможность слушать этот трафик имеет даже и не одна спецслужба, а несколько.
В принципе проблема актуальна везде, где трафик проходит через две точки, в одной из которых возможна его маркировка а в другой прослушивание и где такая возможность что-то дает атакующему. Про i2p и практичность атак чуть выше говорили — пока есть хоть какая-то возможность менять форму выходного сигнала — есть и возможность его маркировать, но на практике реализовать гораздо сложнее.
А если делать такой финт «по собственной инициативе» и подставлять кого-то другого — так проще воспользоваться соседским WiFi.
А вот со стороны сайта делать какие-то действия бесполезно — атакующий все равно может эти данные перешейпировать по-своему.
В I2P я не смотрел, т.е. атака частично компенсирована, но опять же — если у нас есть, например, 4 различимые скорости и мы можем, скажем, раз в минуту между ними переключаться — значит можно передавать 2 бита в минуту, надо только найти способ скрытно сохранять канал достаточно долго и пихать туда трафик так, чтобы со стороны клиентского приложения это не вызывало подозрений. Это возможно в большинстве прикладных протоколов.
Конечно, при таких условиях атака гораздо менее практична, т.к. такие темплейты гораздо сложней распознать в массовом трафике, чем последовательность пакетов определенного размера от известных entry node, чтобы «взвести» оборудование и начать анализировать трафик именно этой сессии.
С UDP все даже легче, т.к. в нем Нагла нет. Т.е. потеря возможности управлять размером пакетов с лихвой компенсируется очень прогнозируемыми таймингами.
А еще год назад на одной из выставок (не помню — или Zero Nights или PHD) показывали активное оборудование СОРМ, которое встает в разрыв между абонентской сетью и интернетом и умеет шейпить трафик. Exit node под контролем такого оборудования — это готовое условие для атаки. И не факт что в других странах уже не так.