Комментарий от Shir0

Комментарий #2129446

в топике «10 лет за распространение имитации и хентая» единогласно принято во втором чтении30 мая 2016

Алсо, рассуждая на правах лирического отступления, даже если предположить, что торренты серьезно порежут, в итоге все равно найдутся люди, которые будут доставать контент, выкладывать его в локалках, записывать с винта на винт и так далее. Как в начале 2000-х и раньше.

Я с этим не спорю и более того полностью согласен. Вообще вся фабула того, что я написал, про другое, речь о том, что если государство захочет сделать поводок покороче, оно это сделает. Мы сейчас вообще слишком привыкли к доступности различного защищенного авторским правом контента и забыли, что это не "право", а особая "привилегия", которую в силу определенных обстоятельств мы получили и которую нужно ценить. И мы можем, к сожалению, ее лишиться. Вот взять, TPP, о котором тут напомнил Джон, за что ему спасибо. Если оно будет принято, то мы много чего потеряем. Например мы привыкли к тому, что можно спокойно пойти и почитать практически любую мангу, за которую, кстати в Японии хотят неприличных денег, или посмотреть свеженький блюр аниме, за который, кстати, тоже хотят неприличных денег в Японии. Так вот этого может легко не стать благодаря TPP.
Хотя учитывая невысокое качество современных тайтлов, я от такого события на стенку лезть не буду.

whois

Шейпить != блокировать, и active probe китайцы не от скуки придумывали.

Возможность шейпить/детектировать конкретный тип трафика - это тоже самое, что и возможность блокировать его.
Китайцы active probe придумали потому что сложность и ширина задачи у них сильно другая. В их случае нужно контролировать все, включая до сели невиданные протоколы и их реализации. В нашем же случае нужно контролировать ВСЕГДА МАССОВЫЙ протокол и его реализации. Говоря более понятным языком, китайцам нужно, чтобы даже блоха не проскочила, а нам и ружья на слона хватит. Но это все лирика, давай возьмем немно конкретики.
goo.gl/l10a8x (www.openu.ac.il/home/mikel/papers/60490373 [ 1 ].pdf) - вот хорошая статья на тему практической реализации алгоритмов распознавания шифрованного трафика на основе статистической классификации. И там как раз уделено немалое внимание распознаванию шифрованного bittorrent трафика. Пара ключевых тезисов оттуда:

The current paper introduces a hybrid statistical algorithm that integrates two basic and well known machine learning algorithms, known as k-nearest neighbors and k-means. The algorithm is fast, accurate and most important it is insensitive to encrypted traffic.

The strength of our algorithm is demonstrated on Encrypted BitTorrent, one of the hardest applications to identify. The BitTorrent development community puts a lot of effort into detection avoidance and uses port alternation, packet padding (on initial flow packets) and encryption as part of this effort. Actually, as to encryption, it turns out that it identifies encrypted and non-encrypted BitTorrent flows with the exact same accuracy.

One of the main purposes of this study was dealing with encrypted flows in realtime. Indeed, encrypted BitTorrent exhibited results similar to non-encrypted BitTorrent. Also note that Skype (which is encrypted) exhibits an accuracy similar to BitTorrent. These results look very promising and indicate that our algorithm is insensitive to encryption and can classify encrypted traffic as easily as non-encrypted one.

Realtime evaluation. We tested the feasibility of our algorithm in a realtime embedded environment, by implementing the k-nearest neighbors and hybrid algorithms on the SCE2020 platform, one of Cisco’s network traffic controllers. More specifically, the algorithms were developed and implemented as a standalone component (in C++, on a PPC dual core) on SCE 2020.

Technical Limitations. The algorithm employs basic mathematical calculations, mostly simple additions and multiplications. Implementing such an algorithm may be more challenging on a platform that does not support floating point primitives, although this difficulty is of course solvable in software.
Memory. The algorithm used 76 bytes per flow on the statistics collection phase and one Megabyte for the training set. Taking into account a concurrency level of a few thousand flows (in the classification phase) and the use of an LRU table, the classifier uses only 4-5Mb. This is a very low figure (for core classifiers) and fits our realtime low memory usage requirement.
Performance. Running the algorithm did not appear to exert any stress on the CPU.

Для тех, кто не знает английский, кратко изложу смысл, ученые в этой статье тестировали в реальных условиях алгоритм распознавания различных типов зашифрованного трафика. Делали они это на обычной платформе Cisco SCE 2020, без каких либо масштабных и сложных датацетров, вычислительных кластеров и тому подобного. В процессе тестирования алгоритм показал крайне выскую эффективность распознавания bittorrent траффика не зависимо от шифрования оного. Ниже табличка оттуда.

Дело было в 2010м году.
Все еще будешь спорить?

whois

а чей счет оборудование устанавливается? ФСБ?)

Ты хоть знаешь, что такое СОРМ? Или ты хочешь сказать, что внедрить новую сложную систему аналитики информационных потоков и обеспечить доступ к уже существующей системе аналитики информационных потоков - это одно и тоже с точки зрения финансовых затрат!? 0_o Конечно интернет провайдеров обязали расширить логирование и хранить логи дольше, но это, извини, совсем из другой оперы и затраты там минимальные.
Хотя я не удивлен, что ты в очередной раз пытаешься съехать на экономику... ¬ ͜ ¬

whois

Где доказательства, что системы представленных провайдеров реагируют именно на шифрованный p2p-трафик, а не в том числе?

Во-первых, если бы даже провайдеры реагировали на что-то другое, это бы не означало, что они не определяют p2p траффик, просто в силу того, что пров может захотеть заблокировать еще что-то, во-вторых если бы что-то подобное имело место быть оно бы было описано в таблице. Напротив же четко написано:

J:COM (Zaq) Ultra 160M, Osaka area. Throttling speeds on all P2P connections only on their 160M plan. 60Kbyte/s - 70Kbyte/s down speed. HTTP / FTP downloads 8 - 12 Mbyte/s.

J:COM (zaq) start speed throttling from August2011.160M connection only shows 15 to 20K speed. They admit that P2P is blocked from now.

whois

К слову, у меня знакомый ей тоже пользовался, и резались там не только торренты, но и игровой трафик, и FTP (sic!).

Если хочется поговорить именно о FTP, у нашей организации в одной из лабораторий в Питере интернет для сотрудников предоставляется через Yota, обмениваться данными через FTP приходится часто, проблем пока не было. То, что ты описал, больше смахивает на ситуацию когда базовая станция просто перегружена. )

whois

Паттерн, во-первых, должен быть составлен таким образом, чтобы не порезать "честный" трафик.

И это не проблема.

whois

Учитывая, кстати, мое достаточно продолжительное знакомство с программным кодом в телекоммуникационном оборудовании (китайским в т.ч.), там ни о каких паттернах, как правило, речи вообще не идет.

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

@whowas

Ответы

whowas30 мая 2016#

Shir0

Возможность шейпить/детектировать конкретный тип трафика - это тоже самое, что и возможность блокировать его.

Критичность ложных срабатываний другая.

Shir0

В их случае нужно контролировать все, включая до сели невиданные протоколы и их реализации.

NO WAY. Не зная протокол, не сформируешь адекватный probe request.

"Твоё же."

We were also able to resist active probes by modifying a bridge of ours to ignore old VERSIONS Tor cells.

"Еще."

The phenomenon of active probing arose presumably in response to enhanced circumvention systems that better resist traditional forms of blocking. For example, instead of employing a protocol recognizable by deep packet inspection (DPI), some of these systems embed their traffic inside TLS streams. Barring any subtle “tells” in the circumvention system’s communication, the censor cannot distinguish circumventing TLS from any other TLS, and thus cannot readily block the circumvention without incurring significant collateral damage. Active probing enables the censor to disambiguate the otherwise opaque

Слишком увлекся, что ли?

Shir0

вот хорошая статья на тему практической реализации алгоритмов распознавания шифрованного трафика на основе статистической классификации

Эм, a что мешало еще в начале ее приложить, поставив тем самым точку в вопросе? Надо было свое ЧСВ потешить?)
Методология, кстати, достаточно в общих чертах написана. А вот что будет, например, если я начну банально трафик фрагментировать?

Shir0

Ты хоть знаешь, что такое СОРМ?

Знаю. Еще я знаю, что установка оборудования идет из своего кармана, и провайдеры помельче договариваются с фсбшниками о сливе данных по запросу. Никто никого не дотирует, хотя, казалось бы, целиком и полностью государственная инициатива.

Shir0

Значит сам не можешь, так бы и сказал. У меня уже складывается такое впечатление, что ты решил поднять своей профессиональный уровень за мой счет, сам не знаешь, искать информацию не можешь, зато все время просишь, чтобы я тебе что-то нашел... ¬ ͜ ¬

Ты говоришь - ты ищешь, a ad hominem припаси для кого-нибудь другого.

Shir0

Но твое недоверие ни капли не мешает мне писать код в продакшн и смотреть на всю эту

кухню

if (guts == OSPFC_dbguts_null_CNS ||
guts->where == OSPFC_on_free_list_E ||
(metric = RSG_swap32_MAC (db->adv.ase->tos0.tos_metric)) == OSPFC_ls_infinity_CNS ||
db->adv.sum->ls_hdr.ls_age >= OSPFC_MaxAge_CNS ||
db->key[OSPFC_ls_id_E] == OSPFC_ospf.my_rtr_id ||
db->key[OSPFC_adv_rtr_E] == OSPFC_ospf.my_rtr_id ||
((route = OSPFP_rtr_findroute (OSPFC_area_null_CNS,
db->key[OSPFC_ls_id_E],
OSPFC_dtype_asbr_CNS,
OSPFC_ptype_intra_CNS)) != OSPFC_route_null_CNS &&
(area->trans_capable == FALSE ||
(route_info = &route->ospf_rt_info,
route_info->area->area_id != OSPFC_backbone_id_CNS))))

изнутри. Всякое, дружелюбное для пользователя, API на системном уровне грозит превратиться в фарш и содомию, хотя там тоже пытаются следить за качеством кода.
Заметь, мы еще опускаем QA или саму целесообразность каких бы то ни было доработок, например.

@Shir0

Твой комментарий

Комментарий #2129446 Shir0

Комментарий #2129446
Shir0