Во-первых, не говорил. Во-вторых, только в пределах мкада миллионов 15 людей. Вы реально хотите их сжечь? И реально уверены, что потеря этих людей, находящихся там научных и производственных центров, центра управления нашей страной — пойдёт ей на пользу? Если считать пользой развал страны, разделение её на отдельные, подконтрольные иностранным государствам зоны оккупации — то да.
Почти все интранет-чаты (без сервера или клиент-серверные, не суть важно) работают на протоколе UDP. В госорганах в том числе. Запрещайте, пОцОны, чО, юзайте Ватсапп и Вайбер :)))
Нахрен тогда интернет вообще нужен? 500р чтобы в одноклассниках котов лайкать? Так можно запретить и рекламу по телеку переключать.. А то рекламодатели убытки терпят от непросмотренной
Запретить udp, ну-ну. А чего сразу не фазовую модуляцию? Закон Ома тоже можно. Уравнения Максвелла приравнять к ЦП. Вот чего только люди не придумают, чтобы скрыть неспособность впарить свои поделия хоть кому-нибудь!
Где таких дебилов берут? Не, ну правда, где этот элитный питомник? Сжечь бы его к бениной маме, что бы не плодились.
Хрен с ним с покотовым видео и торрентами... Но мля, UDP использует DNS! Даже число корневых серверов ограничено для того, что бы ответ влезал в один пакет. DNS тоже запретить?
Уж не говоря о том, что на торрентах раздается огромные объемы информации как в приницпе некоммерческой, например дистрибутивы того же Linux'а, так и информация которую иначе хрен найдешь, причем правообладателям, вообщем-то, и насрать на нее.
Работает. Если данные больше 512 байт.
Так что придется для начала переписать клиентов в используемом оборудовании, что бы они сразу открывали tcp, а не слали udp. Да и сервер тоже не должен использовать udp для ответов, иначе не дойдет.
А причем здесь количество корневых серверов и один пакет?
Список корневых серверов никогда не запрашивается — просто не у кого. Он сохраняется в файловой системе при инсталляции сервера DNS.
Ослик с торрент-клиентами отлично и по ТСР работает. А вот перекрытие UDP = смерть куче игрулин и, например, IP телефонии. Особенно — международной. Потому что за пределами России, скорее всего, чихать будут на то, что внутри нее творится. Да и с остальными стандартными сервисами, типа того же DNS, проблемы возникнут.
Два года назад кто-то из МТС накатал жалобу в роскомнадзор что скайп являтся конкурентом, но лицензии на услуги связи не имеет.
Роскомнадзор, правда, тогда лицензировать отказался. С нынешней борьбой против огентов госдепа и переносом персональных данных в российские ДЦ, могут еще раз попробовать прижать.
Какая-то ерунда. Ну запретят UDP вернемся к торрентам через TCP (пусть медленнее, но будут же). Потом шифрование никто не отменял. Если крупнейшие поисковики не будут искать — будут искать специализированные поисковики или сами торрент-клиенты. VPN-ы накройняк....
Так что это новость из разряда "напугать"...
На фрэштеле резалка торентов по скорости стояла. Так вот ни шифрование ни смена tcp/udp на скорость не влияли. Подозреваю при желании и совсем отключить могли..
Хз как, но они это сделали. При том у них безлимит до 10 мегабит 900р стоил.. "...с помощью которого можно выяснить, не ограничивает ли провайдер интернет-трафик по таким протоколам, как BitTorrent..." это не оно? p2p-news.ru
Как раз первоначальное скачивание тут сильно сбоку.
Клиент с клиентом только через https заворачиваешь. Так и связан. Если по другому то конечно это никакой не торент через https.
https это http over ssl/tls, и используется afaik максимум для связи серверами.
В приниципе, ни что не мешает известные протоколы пропускать без ограничения, а неизвестные — резать. В том числе и https по нестандартному порту. Во всяком случае у меня ktorrent на 443 порту ничего не открывает.
Я знаю что такое https :)
Использовать его можно практически где угодно в качестве канала связи.
Номер тут в том, что снаружи виден только https, содержимое снаружи не видно. Поэтому проблема неизвестных протоколов отсутствует как класс.
Остается вопрос блокировки собственно https соединений. А это больно для всех — банки, платежные системы, госуслуги и тд, а в ближайшей перспективе практически все ресурсы будут через https, все к этому идет.
Ну а порт. Какой скажу такой и будет.
Если что угодно, то это не http :)
А именно что угодно в обертке ssl/tls. Так же как в нее можно запихуть smtp, pop3, imap, но https они от этого не станут. :)
У обычных нормальных людей.
Если я начну объяснять человеку про модели оси, протоколы и шифрование он пошлет меня лесом и будет прав.
Потому для нормальных людей простыми сущностями.
Ок. У обычных нормальных ламеров.
Если не вдаваться в уровни OSI (а зачем, кстати?) то трафик просто шифрованный.
https, кстати, в первом приближении защищен от monkey in the middle, чего не скажешь о произвольном зашифрованном трафике с несимметричными ключами.
Разница в том, что в случае http-сервера его ключ можно проверить в CA, а ключ CA уже прописан в систему, так что подменить не получится. Если, конечно, сервер не используется самоподписанный ключ.
Гмейл, кстати, отказывается забирать почту по протоколу pop3s, если на сервере самоподписанный ключ. Я давеча на эти грабли уже наступил.
А в случае двух клиентов с большой вероятностью у них будут самоподписанные ключи, которые проверить банально негде.
В случае двух клиентов будут просто ключи :) Вообще никак и никем не подписанные а просто сгенерированные.
Если меняться по DH то перехватившему ничего не светит.
Негодяй конечно может выдать себя за другого, но в процесс общения вмешаться не сможет никак.
Если кто-то перехватывает трафик, то он перехватит обмен ключами, подменит ключи и будет шейпить только в путь, пользуясь DPI.
А проверить подмену ключей в этом случае невозможно.
а это, простите, как? Голубиной почтой, что-ли?
без подколок, я действительно не знаю, что это за технология. :)
зы. В банк ключ отношу натурально на бумаге распечатанный. :)
А. Это я знаю. Я думал может какая-то новая битторентовская технология. :)
Имхо, уязвим любой обмен ключами, при котором первоначальные данные передаются в открытом виде и могут быть подменены. Например — чей-то публичный ключ, которым потом будет зашифрован сеансовый ключ.
Комментарии
если сесть в бомбардировщик"
Тоже ведь про Москву сказано
ну почему же только котов?
Там много рекламы Путина ))))
Хрен с ним с покотовым видео и торрентами... Но мля, UDP использует DNS! Даже число корневых серверов ограничено для того, что бы ответ влезал в один пакет. DNS тоже запретить?
Уж не говоря о том, что на торрентах раздается огромные объемы информации как в приницпе некоммерческой, например дистрибутивы того же Linux'а, так и информация которую иначе хрен найдешь, причем правообладателям, вообщем-то, и насрать на нее.
Но в целом да, дебилы без понимания того о чем говорят.
Так что придется для начала переписать клиентов в используемом оборудовании, что бы они сразу открывали tcp, а не слали udp. Да и сервер тоже не должен использовать udp для ответов, иначе не дойдет.
И клиенты переписывать не надо, они легко конфигурятся.
Список корневых серверов никогда не запрашивается — просто не у кого. Он сохраняется в файловой системе при инсталляции сервера DNS.
Дык операторы традиционной телефонии давно уже на разные там скайпы и SIPы косо смотрят и все думают как бы это запретить.
Роскомнадзор, правда, тогда лицензировать отказался. С нынешней борьбой против огентов госдепа и переносом персональных данных в российские ДЦ, могут еще раз попробовать прижать.
Так что это новость из разряда "напугать"...
Если честно нереально звучит. Там же никакое глубокое сканирование не поможет.
Клиент с клиентом только через https заворачиваешь. Так и связан. Если по другому то конечно это никакой не торент через https.
В приниципе, ни что не мешает известные протоколы пропускать без ограничения, а неизвестные — резать. В том числе и https по нестандартному порту. Во всяком случае у меня ktorrent на 443 порту ничего не открывает.
Использовать его можно практически где угодно в качестве канала связи.
Номер тут в том, что снаружи виден только https, содержимое снаружи не видно. Поэтому проблема неизвестных протоколов отсутствует как класс.
Остается вопрос блокировки собственно https соединений. А это больно для всех — банки, платежные системы, госуслуги и тд, а в ближайшей перспективе практически все ресурсы будут через https, все к этому идет.
Ну а порт. Какой скажу такой и будет.
Вы немножко не разбираетесь.
А именно что угодно в обертке ssl/tls. Так же как в нее можно запихуть smtp, pop3, imap, но https они от этого не станут. :)
Примерно как копир ксероксом.
Если я начну объяснять человеку про модели оси, протоколы и шифрование он пошлет меня лесом и будет прав.
Потому для нормальных людей простыми сущностями.
Если не вдаваться в уровни OSI (а зачем, кстати?) то трафик просто шифрованный.
https, кстати, в первом приближении защищен от monkey in the middle, чего не скажешь о произвольном зашифрованном трафике с несимметричными ключами.
Ключи отдельно, обмен ключами отдельно.
Гмейл, кстати, отказывается забирать почту по протоколу pop3s, если на сервере самоподписанный ключ. Я давеча на эти грабли уже наступил.
А в случае двух клиентов с большой вероятностью у них будут самоподписанные ключи, которые проверить банально негде.
Если меняться по DH то перехватившему ничего не светит.
Негодяй конечно может выдать себя за другого, но в процесс общения вмешаться не сможет никак.
А проверить подмену ключей в этом случае невозможно.
без подколок, я действительно не знаю, что это за технология. :)
зы. В банк ключ отношу натурально на бумаге распечатанный. :)
ru.wikipedia.org
Действительно уязвимо для MITM.
Посыпаю голову пеплом.
Имхо, уязвим любой обмен ключами, при котором первоначальные данные передаются в открытом виде и могут быть подменены. Например — чей-то публичный ключ, которым потом будет зашифрован сеансовый ключ.