А еще лучше сделать такую программу в виде псевдо рутера. Повесить эту программу на псевдоинтерфейс и заворачивать туда трафик по мере надобности через iptables/ipfw :)
Меня удивило, что в новости не упомянуто почему и зачем это делается.
А делается это в ответ на акции американских провайдеров, в частности Comcast, установившего оборудование для ограничения трафика при передачи p2p данных, различаемых по сигнатурам в пакетах. Таким образом пиратбей будет время от времени менять способ или ключ шифрования, а комкасту останется выкинуть в помойку новые дорогостояшие циско-роутеры, прикупленные для этих целей.
Кстати FCC тоже зуб заимело на комкаст, и вероятнее всего их засудят за зажим трафика (хотя это дело уже тянется год) . Провайдер должен предоставлять каналы пользователю, а не заниматься полицейскими функциями.
Со стороны провайдеров уже готовятся методы противодействия шифрованию трафика. В частности недавно было опубликовано любопытное исследование, демонстрирующее программный инструмент, с помощью которого провайдеры смогут блокировать или ограничивать шифрованный трафик абонентов даже не имея возможности его посмотреть и проанализировать данные. Авторы исследования - итальянцы нашли свособ "слепой" классификации с точностью до 90% того типа трафика который сокрыт в шифрованных пакетах сеансов соединений. Такой выдающийся результат был достигнут м помощью алгоритма автоматического анализа, сопоставляющего размеры пакетов и интервалы между их доставкой. Само же содержимое пакетов программу анализа никак не интересует. Можно полагать что программа будет улучшена ещё больше, до 95-99% угадывания. Хотя провайдерам хватит и 90% вероятности, чтобы не прерывать, но заужать трафик торрентов, то есть передавать его с низшим приоритетом. Кроме того, если торренты начнёт шифровать трафик, то они займут 99% всего шифрованного трафика в сети. Бедным провайдерам можно будет просто создать правило - если трафик шифруется, то это скорее всего торрент - ставим ему низший приоритет.
В впн-пакеты будет инкапсулирован торрент-трафик, размер пакетов, интервалы между ними, возможно ещё по каким то характеристиками идущие gre-пакеты будут повторять характер торрент-трафика и это будет определено. Засудить вы никого не сможете, потому что у провайдеров в меж-операторских договорах прописаны зоны ответственности и вам всегда скажут что проблема "на той стороне, а не на нашей, до шлюза или до стыка с другими операторами у вас пинг и скорость отличная - так что к пуговицам притензии есть ?".
вот тут я с вами не согласен. Я смогу засудить своего провайдера если он мне без моего согласия будет урезать либо ставить низкоприоритетным торрент траффик. Если не он а его вышестоящий провайдер, то тут конечно я ничего не смогу сделать.
доказать можно теми же логами о том что траффик урезан в плане заблокирован. провести експертизу и тд. С низкоприоритетным траффиком - тут сложнее увидеть и доказать. Хотя в теории реально
Дело в том, что приоритет уже не помогает. Пропускная способность сети растет почти на порядок медленее чем запросы на перекачиваемый потребителямя контент. И не всегда это именно p2p пиратчина. растет доля медиаконтента - абсолютно легального, нередко оплаченного прямо там же, но от этого не менее емкого.
те провайдеры готовятся к ситуации когда потребитель хочет медиа-стрим, сервер его готов отдать, а вот провайдер передать не может, буквально "кишка тонка"
Я конечно не спец, но: SSL - Transport Layer Security, тоесть криптографический протокол, обеспечивающий защищённую передачу данных между узлами на транспортном уровне протокола
Как я понял по ссылке выше они собираются создавать защиту на сетевом уровне протокола (уровень ниже транспортного, предназначен для определения пути передачи данных)
The solution inserts a crypto layer between the IP-stack and application
Собираются заюзать дополнительный слой для шифрования. Пользователю не придется настроивать что-либо, просто установить программное обеспечение шифрования и работать.
Предлагаемые методы шифрования Salsa20 с eSTREAM для ориентированных поток сообщений и AES-CBC с неявной (статическое) IV и ciphertext stealing для датаграммы ориентированной коммуникации.
Ограничения
Не обеспечивает анонимность (но хорошо работает с IP-сетей анонимизирующую), тем самым не защищает от анализа трафика
Только защищает от пассивного eavesdropper, не защищает против активного противника или man-in-the-middle.
Причины задержки в создании, может быть проблемой для некоторых применении протоколов.
Практические испытания необходимы.
Будет досаждать приложения будут продолжать работать на машинах без поддержки протокола шифрования с ключевыми обмена запросы. (Potential log spamming?) (Потенциальные лог спам?)
"Deep пакет инспекции" межсетевые экраны и прозрачных прокси могут начать блокировать трафик, поскольку ключ-обмен запросы.
Всё равно не понимаю, в чём же преимущество для пользователя этого подхода перед предыдущими? Неужели только в том, что нужно программу поставить, а не клиент настроить?
1.Прозрачность
Цель прозрачность уровня приложений означает, что все приложения, использующие UDP / TCP транспорта смогут воспользоваться шифрования, даже не зная его. В данном случае все приложения, те же Instant Messanging и SIP на базе VoIP, могут шифровать трафик между собой.
2. Для всех приложений, которые ведут обмен данных через сеть
В данном случае они "модифицыруют" протокол данных, и все приложения, которые будут проводить обмен данными через сеть, а не только те, что поддерживают SSL, будут обмениватся шифрованым трафиком.
Неее, SSL, SSH tunnels, OpenVPN - это всё слегка не то.
Более интересен вопрос - разве opportunistic encryption (RFC 4322) делает не фактически то же самое?
Спорно....
Неведомое достаточно быстро станет известным. А поскольку оно совсем свежее, то оно может содержать баги и какие-то особые грабли, не обязательно в идее, но в какой-то конкретной реализации.
В этом плане давно известное и вылизанное может оказаться более надежным.
ну здесь же в частности даже на Хабре постили немного один из ставших известным случаем (тогда сильную огласку получил), хотя были и другие. и не сомневаюсь, что есть и неоглашенные общественности. http://pilat.habrahabr.ru/blog/30503.htm…
были еще случаи наложения арестов на серверы и все прочее.
А я советовал авторам ТОРа написать на главной странице большими буквами: «НЕТ, МЫ НЕ ШИФРУЕМ ВАШ ТРАФИК».
Ведь все думают, что он делает именно это :-)
Это вовсе не взлом. Tor не шифрует трафик. Все, что проходит через тор, может конечными серверами этой сети перехватываться в незашифрованном виде. И нужно отдавать себе в этом отчет. Все что тор делает - это скрывает местонахождение.
Арест серверов - это не взлом. Просто они оказались конечными серверами в цепочке чьего-то соединения, кто делал что-то противозаконное. Соответственно все следы ведут на последний сервак в цепочке. Потому сначала арестовывают тако сервак, а потом понимают, что не того взяли.
Единственный известный мне способ уменьшить анонимность тора - это внести в него кучу своих серваков.
Думаю, что The Pirate Bay не грозит быть пойманным правообладателями. Жаль, что на торрентс.ру стали закрывать многие раздачи. Хотя народ умудряется скачать пару десятков раз до "Закрыто по просьбе правообладателя" :)
Трекеры-то перешли. А P2P? А в Counter Strike вы тоже через HTTPS будете играть, и внутриигровой чат гонять? Или ICQ/ArtyTalk/ещё какие сервисы?
Кстати, да, вроде понятнее, чем это лучше opportunistic encryption-а. Если я правильно понимаю, такое шифрование не будет требовать собственного домена у пассивной стороны, а opportunistic encryption вроде как требует...
The Pirate Bay собирается шифровать весь трафик