Перейти к содержимому
Калькуляторы

Рыба с какого места гниёт?

Она так быстро загнивает, что место первоначального гниения не важно. Тем более она и без него тоже сгнивает так же быстро. :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Особенно понравилось "...номинальная пропускная способность узла...".

Я уже где-то рядом мрачно шутил/ехидничал. Поставил подъездный узел на десять абонентов, каждый воткнут в 100Мбит порт - готовь для этих абонентов хранилище на 1Пбайт.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я уже где-то рядом мрачно шутил/ехидничал. Поставил подъездный узел на десять абонентов, каждый воткнут в 100Мбит порт - готовь для этих абонентов хранилище на 1Пбайт.

2 Пбайт. In/Out-же.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Зачем вот эти все технологии и архитектура сетей для распределения нагрузки и отказоустойчивости. Извольте поставить один фильтр для РКН и одну систему хранения и гнать трафик через единую точку отказа!

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Извольте поставить один фильтр для РКН и одну систему хранения и гнать трафик через единую точку отказа!

Такие же ощущения. Но учитывая как активно CKAT DPI проталкивает inline-режим (только так, мол, не будет пропусков) и отзывы довольных операторов, которые такой схемой пользуются, создается ощущение, что все нормально, так и должно быть. Как-то неправильно это...

Изменено пользователем Умник

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

По поводу РКН-овских списков в 2012 году тоже кричали, мол, невозможно все заблокировать, это же все равно что "зубную пасту заталкивать обратно в тюбик", дикие деньги, нужен DPI... А спустя всего 4 года выяснилось, что все очень даже возможно - просто постарались некоторые производители ПО, не буду показывать пальцем. Вот и с Яровой так же будет, к сожалению. :(

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Как-то неправильно это...
«Как-то неправильно» началось, к сожалению, с момента появления CIDR. Уж больше 20-ти лет как...

 

А DPI... Вот взять одного широкоизвестного провайдера, фильтруют, умники, TLS через анализ SNI. Нет бы сертификата подождать, и тогда уж точно. При «любой погоде». Но нет... Нетерпеливые мы!

 

И все, главное, довольны... Даже я, ибо мало в этой жизни поводов для искреннего веселья.

 

Запад в эти игрушки играть начал намного раньше нас. Намного. И чё? Да ноль полный: кто-то свыкся, найдя разумный компромисс, кто-то дощёл до своих конституционных судов. С вполне предсказуемым результатом.

 

Главный вред-то от этого уже нанесён, к сожалению, уже давно. Тотальная TLS'изация. И вы, братцы кролики мелокопоместные операторы, несёте за это часть ответственности. Нефиг было лезть своими кривыми загребущими ручонками в трафик больших дядь и корёжить глобальные телекоммуникации своими кривыми мидл-боксами!

 

Большие дяди малость обиделись, и наняли п..ков из EFF и ещё кой кого похуже. А политиканы и разнообразные борцуны (которые искренне считают что MITM-атака — самое страшное) просто довершили начатое. Хомячьё радостно хрюкая копается в ВПН'ах. «Чё, крута! Я теперь борцун с системой!» И стоим мы на пороге такого п..ца, что даже *мне* страшно делается. Фреймворк для тотального овладевания он уже здесь, на каждом девайсе. Осталось его только запустить.

 

Не трусь, — сказал он. — Это все игрушки. С Выбегаллой только связываться неохота... Этого ты не бойся, ты вон того бойся!

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А спустя всего 4 года выяснилось, что все очень даже возможно

 

А есть у кого-нибудь данные по динамике изменения количества записей в реестре?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Динамика, я так понимаю сильно поперла вверх, когда начали старые судебные решения забивать и пустили козла в огород всякие другие ведомства..

А так сегодня там 53676 записей. (при чем в части записей и куча URL и куча IP). 40% - суд. А собственно надзора 11%. Если бы список не разбавили наркоманами итд, то было бы 6к записей.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

По поводу РКН-овских списков в 2012 году тоже кричали, мол, невозможно все заблокировать, это же все равно что "зубную пасту заталкивать обратно в тюбик", дикие деньги, нужен DPI... А спустя всего 4 года выяснилось, что все очень даже возможно - просто постарались некоторые производители ПО, не буду показывать пальцем. Вот и с Яровой так же будет, к сожалению. :(

Дык, верно-же все написано:

 

1) HTTPS блокируется только огульно. Иначе невозможно.

2) Деньги - реально дикие.

3) Без реализации DPI фиг результата получишь.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А спустя всего 4 года выяснилось, что все очень даже возможно

 

А есть у кого-нибудь данные по динамике изменения количества записей в реестре?

А зачем?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А зачем?

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А спустя всего 4 года выяснилось, что все очень даже возможно

 

А есть у кого-нибудь данные по динамике изменения количества записей в реестре?

 

2016-12	4862
2016-11	4811
2016-10	3888
2016-09	3113
2016-08	3369
2016-07	3316
2016-06	2674
2016-05	2984
2016-04	2196
2016-03	1983
2016-02	2408
2016-01	1198
2015-12	2195
2015-11	1763
2015-10	1767
2015-09	1442
2015-08	927
2015-07	1128
2015-06	682
2015-05	811
2015-04	929
2015-03	617
2015-02	480
2015-01	391

 

Первый столбик, дата добавления в реестр (include_date), второй столбик кол-во активных записей (то есть которые на тек. момент должны быть заблокирован)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Яровая - злейший враг, говорите? А вы советника президента почтайте! :-)

 

Россия должна быть готова к тому, что ее отключат от мирового интернета. Об этом в эксклюзивном интервью RT предупредил советник президента России по интернету Герман Клименко.

 

Он объяснил это "высокой вероятностью тектонических сдвигов в отношениях с Западом в сторону ухудшения". В связи с этим встает задача отрегулировать российский сегмент интернета так, чтобы защититься от подобных сценариев.

 

https://rg.ru/2016/12/29/klimenko-rf-dolzhna-byt-gotova-k-otkliucheniiu-ot-mirovogo-interneta.html

 

"Чебурнет" уже виден невооруженным глазом и о нем говорят публично!

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Главный вред-то от этого уже нанесён, к сожалению, уже давно. Тотальная TLS'изация.

и это правильно, потому что при доступе к каналу передачи(тот же public wifi) можно много чего плохого сделать при отсутствии tls.

 

Большие дяди малость обиделись, и наняли п..ков из EFF и ещё кой кого похуже.

EFF как раз всё правильно делают. и никто не обиделся, всё куда проще: изменились реалии.

 

Хомячьё радостно хрюкая копается в ВПН'ах. «Чё, крута! Я теперь борцун с системой!»

да какая ещё борьба системой? просто чем чаще человек будет сталкиваться с заглушкой о блокировке, тем сильнее его мотивация использовать vpn.

 

3) Без реализации DPI фиг результата получишь.

DPI не панацея. просто потому что у их авторов дилемма: либо быстро, либо без ошибок.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

Во-первых, охраняют его даже от конечных пользователей, особая «жопа» в мобильном секторе, где возможности контроля и так слабы.

 

Во-вторых, главный принцип TLS — end-to-end шифрование. Это подразумевает, что данные проходящие по каналу одинаково важны для обеих сторон. На деле же, для интернет-компаний важна только защита целостности в диапазоне последней мили и некая защита от того что я называю «случайным прочтением». На конфиденциальность в строгом понимании они просто срали.

 

В-третьих, ничто не мешает интернет-компаниям сливать ключи. И не секретные ключи своих сертификатов как свято веруют попогандоны TLS, и не каждый сессионный ключ по отдельности. В рамках TLS 1.2 достаточно сливать ключ который используется для шифрования расширения «SessionTicket» RFC5077.

 

Вот например, креатив от твиттера https://blog.twitter.com/2013/forward-secrecy-at-twitter-0 Краткое содержание: ключ ротируется раз в 12 часов, SessionTicket действителен в течение 36-часов. И как написано! Какой слог! Они, оказываются, неусыпно заботятся о нас.

 

Есть более свежее исследование, повящённое в т.ч. и другим способам слива: Drew Springall, Zakir Durumeric, and J. Alex Halderman «Measuring the Security Harm of TLS Crypto Shortcuts» полюс несколько других статей на тему за авторством Хальдермана. Там тоже всё плохо.

 

Вопиющий п..ц в виде SessionTicket пофиксили в TLS 1.3. Но есть и другие способы слива. Ведь схема Диффи-Хеллмана помимо режима «MITM» может работать и в режиме «крыса». Одной стороне просто достаточно «зажать» секретный ключ. И до недавнего времени это являлось повсеместной практикой. Пока, реально, жареный петух (т.е. Heartbleed) в жопу не клюнул. Но и это без разницы, просто достаточно чтобы одна из сторон генерила ключи по определённому закону. С помощью нистовского генератора ПСП, например.

 

В TLS 1.3 много всего пофиксили, и я первый как только настанет время отрублю TLS 1.2 везде где только можно. Но картина вырисовывается просто чудовищная. а) PSK; б) преаутентификация; в) post-handshake authentication. И вроде бы всё верно, и вроде бы всё «маст хэв». Только вот как ты правильно заметил «реалии-то изменились».

 

Из вышеперечисленного меня больше всех волнует «post-handshake authentication». Что раньше мешало интернет-компаниям просить ClientCertificate? Во-первых, отсутствие опыта массовой выдачи сертификатов. Давно уже пофикшено всякими глупыми инициативами типа Let's Encrypt. Во-вторых, лишний RTT и соответственно лишняя латентность которая у TLS 1.2 совсем не фонтан даже без этого. Пофикшено в TLS 1.3. В большинстве случаев никакого негативного влияния на латентность теперь нет. И главное, сервер в любое время может запросить у клиента его сертификат, уже после того как отослал нужные данные чтобы пользователя не раздражали левые задержки. Опять же, просить нужно будет только один раз на PSK, так как сервер будет прекрасно уметь ассоциировать разные соединения как в пространстве так и во времени.

 

Хотели «интернет по паспорту»? Встречайте, в феврале 2017-го. На всех устройствах планеты.

 

Какая «Яровая»? Интернету настал полный карачун, и совсем не из-за того что на вас тут пытаются навесить некий груз социальной ответственности.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Из вышеперечисленного меня больше всех волнует «post-handshake authentication». Что раньше мешало интернет-компаниям просить ClientCertificate?

...

Хотели «интернет по паспорту»? Встречайте, в феврале 2017-го. На всех устройствах планеты.

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

 

Тут существенно, что не у одни общий, предъявляемый везде, а именно у каждого сайта/учетки - свой.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

просто чем чаще человек будет сталкиваться с заглушкой о блокировке, тем сильнее его мотивация использовать vpn.

в чем паника?

 

я за все время блокировок сталкивался с заглушкой два раза. один раз вместо торрентрекера и второй вместо лурка.

 

2016-12 4862

остальные 4860 записей меня не побеспокоили ни разу.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

можно будет отказаться от древнего дурного способа логина и поддержки сессии, когда в куку что-то пишется да логин-пароль
Ага, и суперкуки в нагрузку с криптографической привязкой юзера к сессии, доступной для подтверждения третьими лицами. Нафиг-нафиг.

 

Если интересно, как это должно делаться, можно посмотреть протокол Signal'а (дальнейшее развитие OTR).

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

суперкуки в нагрузку с криптографической привязкой юзера к сессии, доступной для подтверждения третьими лицами.

Это же в TLS1.3 починили?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

суперкуки в нагрузку с криптографической привязкой юзера к сессии, доступной для подтверждения третьими лицами.

Это же в TLS1.3 починили?

Нет. И не починят. Разбрасываться своими ЭЦП направо-налево — дурной тон и источник проблем в будущем.

 

Третья сторона их не увидит, т.к. ранняя выработка ключа, а вот сервер вполне сможет сохранить до «лучших времён».

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Интересно, сервис типа http://neva.pp.ru/help/www4mail_ru/ тоже заглушки будет показывать?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

суперкуки в нагрузку с криптографической привязкой юзера к сессии, доступной для подтверждения третьими лицами.

Это же в TLS1.3 починили?

Нет. И не починят. Разбрасываться своими ЭЦП направо-налево — дурной тон и источник проблем в будущем.

 

Третья сторона их не увидит, т.к. ранняя выработка ключа, а вот сервер вполне сможет сохранить до «лучших времён».

Если я правильно понимаю, (тут, странца 31), то сертификат клиента видит только сервер.

Т.е. посторонние могут определить, кто с сервером общается, - только по IP.

 

Так все равно не понимаю, какой риск увеличивается. Если сервер злонамеренный - он и так может весь обмен с собой запомнить и слить, без запоминания сессионных ключей до лучших времен. Что касается разбрасывания ЭЦП - я же явно указал, что конкретно это ЭЦП - она только для этого сервиса. Другой сервис - другой сертификат.

Ну вот вместо придумывания логин-пароля брузер Certificate Request сервису шлет, а тот его подписывает. И при авторизации - браузер пишет 'тут сервер nnn хочет учетку узнать, какую будем использовать?'

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Если я правильно понимаю, (тут, странца 31), то сертификат клиента видит только сервер.
Правильно. Только пойми, наконец. Сервер — это и есть главная крыса!!! TLS для интернет-компаний — такой способ защиты «своего» трафика в области последней мили. На всё остальное они — срали.

 

Если сервер злонамеренный
Мир он не чёрно-белый, даже не серый, мир — цветной.

 

он и так может весь обмен с собой запомнить и слить, без запоминания сессионных ключей
Гигантский объём трафика. Вызывает проблемы с маржинальностью и репутационные риски.

 

Что касается разбрасывания ЭЦП - я же явно указал, что конкретно это ЭЦП - она только для этого сервиса. Другой сервис - другой сертификат.
Ещё хуже. Повышается гранулярность: вот секретный ключ для сервиса «ваньки-встаньки», а вот для сервиса «сиськи-письки».

 

Да забудь ты слово «MITM», наконец! Нет такого слова. Нет такой атаки в реальном мире. Она живет только на страницах научных статей, в лабораториях, и в виде пугала для наивных хомячков, чтобы они быстрее TLS'изировались. Как только твоя цепочка рассуждений упёрлась в MITM — смело выкидывай её в помойку и начинай всё с чистого листа.

 

Если интересно, найди выступления Яна Гольдберга — создателя OTR. У него много полезного по данной тематике. То же самое у Signal, но у них куда меньше научпопа. Смысл в том, что «вторая» сторона — суть такая же крыса, но в отличие от мифической «третьей» стороны, она присутствует здесь и сейчас. И не нужно её кормить вкусняшками в виде электронно-цифровых подписей.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Да забудь ты слово «MITM», наконец! Нет такого слова. Нет такой атаки в реальном мире.

Гы, да тут пол форума MITMдлит трафик, а кто-то даже не стесняется рекламу пихать!

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.