Здравствуйте, Константин Б., Вы писали:

T>>И еще потом каждому роутеру объясняй, как роутить пакеты для каждого адреса, что вот эти два адреса принадлежат одноу клиенту, им можно друг с другом общаться, а вот другим адресам нельзя. И как только выдаем новый адрес кому-то, то не забыть сходить переконфигурировать роутеры и фаерволы. Спасибо. Чтобы этой голимотьей не заниматься, и придумали IPv6, на нем можно построить гораздо более простую и надежную инфраструктуру. Без центральных реестров адресов, без натов, без переконфигурирования фаерволов и роутеров на каждый чих.
КБ>Люди делится на два типа. Те кто восхищаются ipv6 и те кто на самом деле администрирует сети.
А как насчёт третьего типа, у кого ipv6 уже настроен и работает?

КБ>Для доступа в интернет ipv6 работает конечно замечательно.
КБ>А вот если надо выставить что-то в интернет.... без "not recomended (tm)" костылей не настроишь ни маршрутизацию, ни фаерволы, ни dns.
А конкретно? По сути всё то же самое, все те же проблемы что в 4, но упрощается вся система, т.к. протоколы становятся stateless. Вместо NAT, DHCP сервера+клиента, вся логика в конечном устройстве.

S>В то время как классическая схема без излишних поддиапазонов — сможет использовать хеш-табилицу.
Ничего не понял, как 128 битные адреса провоцируют диапазоны?
Типа раз 128 бит — то все будут юзать по 100500 адресов на условное рыло, а было бы 64 — то экономили бы, и банить конкретное рыло было бы проще? Класс логика. Ну опять же в ipv6 per-рыло-диапазоны вполне фиксированный размер имеют, так что не вижу проблем просто отрезать лишнюю часть и сделать хэштаблицу.
А вообще даже в ipv4 выдают диапазоны. И банят тоже диапазонами частенько. Так что проблема если она есть — то она есть уже давно и никому не мешает.

Здравствуйте, Pzz, Вы писали:

Pzz>Не то, чтобы я был готов оспаривать твой тезис, но не могу по случаю не вспомнить про светлую идею подключить через JS к web-у USB и Bluetooth.

А что не так-то? Шикарное API. Особенно USB.

Моё мнение, как человека, который этим API пользуется такое.

Постановка задачи: сайт из локального USB устройства получает данные и отсылает на сервер. Постановка задачи обсуждению не подлежит.

Вариант 1, как это делалось раньше. Техподдержка по anydesk заходит к юзеру на компьютер, скачивает ему "драйвер", устанавливает и прописывает его в автопуск. "Драйвер" из себя представляет программу на Java Spring Boot, которая занимает 200 MB, стартует 30 секунд и жрёт 500-1000 MB памяти. Некоторые юзеры работают на Windows 7 с 2 GB RAM (вот на днях видел), так что можете себе представить user experience. Эта программа подключается к USB устройству, а также слушает вебсокет на tls 0.0.0.0:12345 (да-да, не 127.0.0.1). У неё самоподписанный сертификат на 20 лет, который прописывается при установке юзеру в доверенные корни. Антивирус на эту программу ругается, поэтому антивирус и фаервол отключаются, "чтобы не глючило". Далее веб-сайт подключается по вебсокету к этой программе и через некоторое API пользуется USB-устройством.

Я даже не буду перечислять, что тут плохо. Тут всё плохо. Добавлю только, что механизма обновления в этой программе не предусмотрено, поэтому у всех юзеров версии программы разные.

Вариант 2, как это делается сейчас. Сайт один раз спрашивает разрешение на использование конкретного USB-устройства. У сайта нет больше никаких доступов, ни к одному другому устройству. На компьютер пользователю не ставится никакой дырявый софт. Весь код работы с устройством обновляется автоматически вместе с сайтом.

Боже, как же это хорошо. Дай бог здоровья тому, кто придумал и реализовал WebUSB.

С Bluetooth, кстати, всё плохо, насколько я помню — там при каждом открытии сайта надо устройство выбирать заново, пользователю это неудобно, поэтому привет спринг бут.

Здравствуйте, vsb, Вы писали:

vsb>Вариант 2, как это делается сейчас. Сайт один раз спрашивает разрешение на использование конкретного USB-устройства. У сайта нет больше никаких доступов, ни к одному другому устройству. На компьютер пользователю не ставится никакой дырявый софт. Весь код работы с устройством обновляется автоматически вместе с сайтом.

Мне как-то совершенно не близка идея, от слова "совсем", предоставлять доступ к моим УСБ-устройствам какому-то внешнему сайту. Понятия не имею, что он может сделать через баги драйвера, хост-контроллера и самого устройства. Но явно совершенно, что всё это хозяйство никогда не проектировалось, не рассчитывалось и ие испытовалось в условиях, когда внешний совершенно код, не заслуживающий вообще никакого доверия, шарится по шине.

vsb>Боже, как же это хорошо. Дай бог здоровья тому, кто придумал и реализовал WebUSB.

И вечной жизни, да. Пусть своими глазами посмотрит на своё творение и на последствия.

Pzz>С этими IP6-ми адресами есть другая проблема. О которой Шмыжа, конечно, не в курсе.
Pzz>Адрес такой ни записать ни произнести. В отличии от IP4-го.
Лучше всего с этим обстояло в фидо, потом, как водится, стало только хуже.

Здравствуйте, ·, Вы писали:

N>>1. Отсутствие видимой со стороны корреляции нужно как раз для безопасности. Иначе оно вообще ни для чего не нужно.
·>Нет, это для приватности. Закрыться полотенцем на пляже когда передеваешься — это приватность. Но полотенце никакую безопасность не обеспечивает.

Именно что безопасность. Приватность на пляже — безопасность против двух вещей: 1) что о тебе что-то узнают и воспользуются (например, опознав особенности твоего состояния здоровья), 2) что на тебя возбудятся. Что это безопасность — очевидно по тому, что ты не будешь защищаться таким образом от своей собаки или кошки, и минимально будешь защищаться (или вообще нет) от супруга (или, наоборот, намеренно не защищаться) Точно так же и приватность в том, кто пришёл с запросом по IP, это безопасность против того, что информацию, которую ты выдаёшь приходом разных запросов/соединений с одного IP, можно сравнить и найти корреляции — а потом применить против тебя. Мне странно, что такие базовые вещи приходится разъяснять.

N>>2. Я так и не получил ответ на свой вопрос в его точных терминах. Что ж, тут кроме "слив засчитан" сказать нечего.
·>Ты просто в терминах путаешься.

Нет. Спасибо за подтверждение.

N>>>>И снова, NAT у них не участвует вообще как концепция.
N>>·>Угу, потому что в ipv6 он не нужен.
N>>Абсолютно необоснованное утверждение. Зачем нужен NAT при IPv6, я неоднократно тут упоминал.
·>NAT64 в смысле? Ну да, нужен, конечно. Но есть нюанс.

NAT66 точно так же.

·>Об этих троих ты заговорил первым, меня ещё в дискуссии не было. Так в чём смысл твоего "тогда познакомься: вот аж целых трое из в общем-то уважаемой организации IETF"?

К тому, что они подумали только на ¼ от нужного для адекватного решения проблемы.

N>>А вы не ограничивайтесь мобилками. Типовой виндовый десктоп-лаптоп, особенно в корпоративной локалке, имеет несколько таких сервисов. А дальше принтеры, файловые серверы и тому подобное.
·>И? Чем поможет NAT?

Резко (а то и полностью) сократит возможности нежелательного доступа снаружи.

N>>И вот тут начинается то, что доказывает рядом Sinclair — что минимальные защиты во внутренней сети (а иначе неудобно) вместе с дырками в защите (а этот RFC фактически способствует таким дыркам) приводят к открытости всему миру.
·>Нет, не приводят.

Реальность, описанная хотя бы в виде списков CVE, показывает обратное.

N>>По сути: при том, что предположение о временности такого адреса способствует его использованию для более сложных по поведению сервисов (начиная с VoIP), а это приводит к меньшей защите файрволлом.
·>Не понял. Т.е. ты хочешь сказать, что если кто-то по не знанию и не пониманию сделает какие-то глупые предположения, то они могут получить плохую защиту? Эээ.. ну очевидно, ясен пень. И? Причём тут ipv6?

Сам по себе ни при чём, но выдача временных дополнительных адресов предложена только для IPv6 (и только через SLAAC, но это уже второй вопрос).

N>>·>В ipv6 — не надо. В этом и цимес.
N>>И снова откровенная ложь. Светить внутреннее устройство сети соглашается не каждый даже с IPv6, а все сказочки типа "вам не нужен NAT, потому что вам достаточно адресов" разбиваются о нормальный уровень паранойи.
·>Так вот RFC как раз про то, как не светить внутреннее устройство сети, реализуя ту же хрень, что делает NAT+DHCP, но технически проще. Прочитай и разберись, в конце концов.

Я прочитал и разобрался. Теперь твоя очередь сделать то же самое.

Здравствуйте, ·, Вы писали:

·>Здравствуйте, m2l, Вы писали:

m2l>>Вообще случайная генерация 64 бит — это уже доработки и костыли, когда выяснили насколько же кривое поделие вышло.
m2l>>Ты просто обоснуй необходимость в каждом пакете через всё сеть слать 64 + 64 бита случайных данных. Условно говоря 1-2% всего трафика — никому не нужный мусор, просто из-за изумительно квалификации авторов IPv6.
·>Сразу видно что ты не занимался распределёнными сетевыми решениями. Случайные данные нужны для возможности реализации stateless протоколов, что даёт бОльшую масштабируемость, надёжность и производительность. Вот тут, например rfc8981 упомянут был.

Он никаким образом не относится к этому утверждению (сомнительному самому по себе).

Здравствуйте, Stanislaw K, Вы писали:

SK>>>Собственно, NAT не является каким бы то ни было препятствием. Плохим мальчикам известно как минимум 3 техники проникновения за NAT.
N>>При отсутствии доступа сквозь раутер этих техник нет.
SK>В том-то и дело что есть.

Список — в студию!

SK>>> Его единственное оправдание существования — дефицит IPv4 адресов и административная сложность их получения (вся вот эта бумажная волокита с выделением, регистрацией, оплатой).
N>>Его главное оправдание на сейчас это сокрытие данных о внутренней сети.
SK>Не имеет значения. Единственное условие — плохим мальчикам нужно знать что за этим IP расположено нечто (интересное или за что платят интересные деньги), что эта внутренняя сеть существует.

Это если предполагать, что всё что угодно можно сломать (в данном случае шлюз).
Практика показывает, что это таки неверно, всегда надо сравнивать стоимость взлома и цену результата,
защититься обычно можно. Тем более если защита концентрируется в одном месте — в данном случае, шлюзе.

SK>Какие либо дополнительные сведения просто немного сократят вторую фазу "рукопожатия".
SK>>>При этом на прикладном уровне NAT-костыль создает проблемы (с той-же телефонией видеосвязью и др) на преодоление которых приходится тратить огромные ресурсы.
N>>Протоколы, с которыми тут проблема, постепенно уходят — не в последнюю очередь из-за этих проблем.
SK>Как только NAT сократится, они быстро вернутся.

С чего бы это? Если уже наработано 100500 замен, а возврат это снова огромные затраты?

N>>Какая доля видеосвязи в последнее время приходится на SIP, а какая — на Zoom, Google Meet, Microsoft Teams, и ещё 100500 аналогов, которых не назвал?
SK>Последние и живы только благодаря тому что с NAT не работает P2P, приходится гонять весь трафик через сервера. При этом у них собственные фундаментальные проблемы с интерконнектом.

Прошу описать эти самые "фундаментальные проблемы с интерконнектом".
А P2P точно так же не будет работать с достаточно жёстко параноидальным файрволлом, который необходим, чтобы не открывать всё всему миру.

Здравствуйте, netch80, Вы писали:

N>Мне странно, что такие базовые вещи приходится разъяснять.
Т.е. ты не понимаешь разницу между безопасностью и приватностью. Не хочу спорить о терминологии, бесполезно, да и оффтоп. Вернёмся к теме: расскажи, какую _безопасность_, по-твоему, эти трое предложили обеспечивать в том rfc? С цитатой, твоя интерпретация не нужна.

N>>>·>Угу, потому что в ipv6 он не нужен.
N>>>Абсолютно необоснованное утверждение. Зачем нужен NAT при IPv6, я неоднократно тут упоминал.
N>·>NAT64 в смысле? Ну да, нужен, конечно. Но есть нюанс.
N>NAT66 точно так же.
Гы.. И зачем же он _нужен_? И тем более в stateful виде с динамическими таблицами трансляции как в ipv4?!

N>·>Об этих троих ты заговорил первым, меня ещё в дискуссии не было. Так в чём смысл твоего "тогда познакомься: вот аж целых трое из в общем-то уважаемой организации IETF"?
N>К тому, что они подумали только на ¼ от нужного для адекватного решения проблемы.
Ты вначале обозначь проблему-то и куда ¾ потерялось. В rfc проблема чётко обозначена и решена полностью, и я уже цитировал.

N>>>А вы не ограничивайтесь мобилками. Типовой виндовый десктоп-лаптоп, особенно в корпоративной локалке, имеет несколько таких сервисов. А дальше принтеры, файловые серверы и тому подобное.
N>·>И? Чем поможет NAT?
N>Резко (а то и полностью) сократит возможности нежелательного доступа снаружи.
Доступом снаружи занимается firewall, а не NAT.

N>·>Нет, не приводят.
N>Реальность, описанная хотя бы в виде списков CVE, показывает обратное.
Причём тут ipv6?

N>>>По сути: при том, что предположение о временности такого адреса способствует его использованию для более сложных по поведению сервисов (начиная с VoIP), а это приводит к меньшей защите файрволлом.
N>·>Не понял. Т.е. ты хочешь сказать, что если кто-то по не знанию и не пониманию сделает какие-то глупые предположения, то они могут получить плохую защиту? Эээ.. ну очевидно, ясен пень. И? Причём тут ipv6?
N>Сам по себе ни при чём
Именно. Так что твой аргумент тоже ни при чём. Хочешь делать защищённые сетевые сервисы, хоть на ipv4, хоть на ipv6 — ты должен знать и понимать, а не делать предположения, очевидно.

N>, но выдача временных дополнительных адресов предложена только для IPv6 (и только через SLAAC, но это уже второй вопрос).
Ээээ... В ipv4 это тоже есть, ровно то же самое, но через жо dhcp+nat.

Здравствуйте, netch80, Вы писали:

m2l>>>Вообще случайная генерация 64 бит — это уже доработки и костыли, когда выяснили насколько же кривое поделие вышло.
m2l>>>Ты просто обоснуй необходимость в каждом пакете через всё сеть слать 64 + 64 бита случайных данных. Условно говоря 1-2% всего трафика — никому не нужный мусор, просто из-за изумительно квалификации авторов IPv6.
N>·>Сразу видно что ты не занимался распределёнными сетевыми решениями. Случайные данные нужны для возможности реализации stateless протоколов, что даёт бОльшую масштабируемость, надёжность и производительность. Вот тут, например rfc8981 упомянут был.
N>Он никаким образом не относится к этому утверждению (сомнительному самому по себе).
rfc относится тем, что он использует случайные данные для геренации адресов.
У тебя, похоже, проблемы с пониманием распределённых и децентрализованнных систем. Вспомнился этот

Автор: ·
Дата: 23.02.22

флейм, когда у тебя было непонимание принципов работы git.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, netch80, Вы писали:

N>>Apple создала структуру ради своей прибыли. А её решила обеспечить ориентацией на выравнивание требований пользователей по линейке имени Джобса.
N>>Если ты согласился подровняться под неё — это говорит о тебе.
S>Ну, я не очень хочу участвовать в религиозном споре о том, является ли Apple империей зла. Как продукт менеджер, я вижу её феноменальный успех. Как пользователь — вижу способы, которыми она этого успеха достигла.
S>И нет, это не "агрессивная реклама".

А я не про "империю зла". А про империю универсального прокрустова ложа, в которой такому императору удобно работать, потому что можно выпускать одежду одного цвета, автомобили одного цвета и у всех жителей одно второе имя. Пока из неё можно уезжать, это ещё (хотя бы частично) внутреннее дело.
Но это всё тут оффтопик, я продолжать не хочу.

N>>Интернет через спутник есть везде. А вот ближайший СЦ Apple может быть и в другой стране.
S>Ну, раз интернет через спутник работает, то и перепривязка устройства сработает.

Я таки напомню, что некоторые операции подобного рода умеют делать только сервисы (им даны всякие пароли-ключи).

S>Он обычно нужен как раз для того, чтобы обходить "идиотские ограничения".
S>Вопрос только в том — сколько из ограничений являются идиотскими, а сколько — весьма и весьма осмысленными. И насколько обход ограничений нужен лично вам, а насколько — социальному инженеру, который уговаривает вас дать root access "невинному приложению", которое вот-вот сделает вас миллионером.

Ну вот Apple перегибает в одну сторону, а те, кто даёт рута направо и налево — в другую.
И почти полностью это потому, что оба действуют по концепции "или рут, или ничего", и все вендоры стараются накидать своих дебильных ништяков.

N>>Три года — это вы по какой стране судите?
N>>IP телефоны даже в условиях США спокойно жили и по 10 лет. А у индийских клиентов жило и по 15, если повезёт (плесенью изнутри не покроется). Могло быть при этом 20 раз перепродано — всё равно в статистике маячили древние модели.
S>Речь об РФ. У нас официальные рекомендации по амортизации для примерно любой цифровой техники — от 1 до 3 лет. Понятно, что в быту можно и 25 лет её эксплуатировать; но речь не о технической прочности, а о периоде полезного использования, на который рассчитывает бизнес.

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

N>>Его не используют без DHCP. Используют тогда уже полноценный FTP, или HTTP.
S>Ну, вот я сейчас не помню, был ли там FTP или всё же TFTP. В обоих сценариях хрен редьки не слаще — потому что никакого DHCP, а просто предпрошитый в конфиге фиксированный адрес хоста, с которого девайс запрашивает файл с именем равным собственному MAC-адресу.

А этот конфиг откуда такой предпрошитый взялся? Впрочем, я тут уже не вижу смысла обсуждать — потому что действительно видел такие кривые использования. Мало, но было.

N>>Почему вы думаете, что не по опросам участников рынка?
S>Скажем, это просто смелая гипотеза.
N>>Или у вас какие-то особо дуболомные инженеры-проектировщики, или одно из двух. Потому что сколь-нибудь нормальные знают, что пароли это как раз то, что у всех должно различаться.
S>И тем не менее, админский пароль на жопе моего роутера таки напечатан, и я сомневаюсь, что он случайный и именно мне достался единственный на всю галактику пароль "password".

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

N>>И это не голые слова. В одном из недавних проектов я как раз с таким имел дело. Там не SIP, другое, но тоже есть M центральных железяк и N (N≫M) юзерских, но жёстко руководимых из центра (клиент имеет право только втыкать-вытыкать шнурки). С завода приходят железяки с заводским паролем. Отдел эксплуатации ставит в сеть и меняет на один пароль и один SSH ключ на всех. Вариант персонального пароля на каждый не рассматривается.
S>Ну, это как раз примерно и есть идея "давайте зашьём в каждый девайс публичный ключ сервера, которым будет управляться устройство".

В общем да. Но в пределах конкретной сети эксплуатации.

N>>С принципом согласен. И всё равно, повторюсь, это не причина после того выставлять все устройста голым задом в интернет, сколь бы этот зад ни казался бронированным.
S>Ок, да, вы правы.

Спасибо Осталось бы ещё понять, чего остальные участники этого треда хотят от этого принципа...

Здравствуйте, netch80, Вы писали:
N>Но это всё тут оффтопик, я продолжать не хочу.
+1
N>Я таки напомню, что некоторые операции подобного рода умеют делать только сервисы (им даны всякие пароли-ключи).
Это не вопрос объективной необходимости, а вопрос дизайна экосистемы. Если производитель железки сделает так, чтобы это мог делать только сервис — то это сможет сделать только сервис.
А если нет — то я, скажем, могу отвязать свой телефон от своего аккаунта для перепродажи безо всякого сервиса, одним лишь спутниковым интернетом.

N>Ну вот Apple перегибает в одну сторону, а те, кто даёт рута направо и налево — в другую.
Сторона Apple — правильная, потому что "открыть" закрытые привилегии можно аккуратно: гранулярно и поэтапно.
А "закрыть" дыру в безопасности нельзя никак — потому что в устройстве уже стоит левая прошивка, и класть оно хотело на ваши обновления.

N>Всё равно даже с потоками нефти я плохо представляю себе, чтобы за 3 года такой телефон мог самортизироваться в любом смысле. Пепельницы в нём вроде нет
При чём тут потоки нефти? Просто прогресс цифровой техники идёт настолько быстро, что устройство трёх-пятилетней давности даже бесплатно отдать бывает трудно. У нас в конторе норматив на замену лаптопа был полтора года.

N>А этот конфиг откуда такой предпрошитый взялся?
Я же говорю — если заказываешь у вендора партию от нескольких десятков устройств, то конфиг предзальют. Можно и для меньших партий, но уже за денежку.
N>Впрочем, я тут уже не вижу смысла обсуждать — потому что действительно видел такие кривые использования. Мало, но было.
Ну, ок. Мой опыт явно значительно меньше вашего.

N>Админский пароль... да, я бы тоже менял. Но я вижу некоторое оправдание в том, что по умолчанию чтобы его применить, надо таки зайти в сеть (или явно разрешить админский веб на WAN).
Ну, я тоже вижу в этом некоторое оправдание. Хотя это всё — опять необоснованные предположения. Потому что выходит так, что у любого получившего доступ к WiFi, автоматом получаются админские привилегии

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, netch80, Вы писали:
N>>Но это всё тут оффтопик, я продолжать не хочу.
S>+1

Так чего ж продолжаем?

N>>Ну вот Apple перегибает в одну сторону, а те, кто даёт рута направо и налево — в другую.
S>Сторона Apple — правильная, потому что "открыть" закрытые привилегии можно аккуратно: гранулярно и поэтапно.
S>А "закрыть" дыру в безопасности нельзя никак — потому что в устройстве уже стоит левая прошивка, и класть оно хотело на ваши обновления.

Нет, зависит от дизайна. Напомню, что в тех же телефонах — в >99% их, если у меня данные не устарели — радиочасть сделана отдельным модулем со своим процессором, который просто принимает команды (раньше вообще AT команды были!) и при этом умеет, например, сам исполнять чего-то по особым SMS. Мне так один телефон заражали регулярно, пришлось выкинуть. Производитель через год после выпуска перестал обновления поставлять.

По такому же принципу дать возможность чего-то нажать-дёрнуть чтобы снести всё неположенное и поставить казённую прошивку — нефиг делать. Возможно, это даже в возможностях основного процессора (я только краем уха слышал про секьюрити в загрузке типовых ARM чипсетов телефонов, но у многих такое есть во много хитрых стадий).

Но если сэкономили... увы.

N>>Всё равно даже с потоками нефти я плохо представляю себе, чтобы за 3 года такой телефон мог самортизироваться в любом смысле. Пепельницы в нём вроде нет
S>При чём тут потоки нефти? Просто прогресс цифровой техники идёт настолько быстро, что устройство трёх-пятилетней давности даже бесплатно отдать бывает трудно. У нас в конторе норматив на замену лаптопа был полтора года.

В лаптопе — могу поверить — хотя последние годы это потеряло актуальность. А с IP телефоном даже тогда срок в полтора или три года уже не имел смысла. Пять — уже на что-то похоже. Десять — вполне правда, но и тогда аппарат можно использовать где-то во внутренней сети.

На одной из моих работ так Meridian от Nortel использовали больше 15 лет. (Ну да, это не IP.)

N>>А этот конфиг откуда такой предпрошитый взялся?
S>Я же говорю — если заказываешь у вендора партию от нескольких десятков устройств, то конфиг предзальют. Можно и для меньших партий, но уже за денежку.
N>>Впрочем, я тут уже не вижу смысла обсуждать — потому что действительно видел такие кривые использования. Мало, но было.
S>Ну, ок. Мой опыт явно значительно меньше вашего.

Сарказм оценён, но вряд ли настолько уместен. Я повторюсь, что подавляющее большинство всё-таки было достаточно разумным даже без выделенного админа, чтобы не делать тут настолько тупые диверсии. 100% не нужно, достаточно 95-98%. Как и везде.

N>>Админский пароль... да, я бы тоже менял. Но я вижу некоторое оправдание в том, что по умолчанию чтобы его применить, надо таки зайти в сеть (или явно разрешить админский веб на WAN).
S>Ну, я тоже вижу в этом некоторое оправдание. Хотя это всё — опять необоснованные предположения. Потому что выходит так, что у любого получившего доступ к WiFi, автоматом получаются админские привилегии

Да. Увы.
Но опять же с учётом кнопки ресета к заводским настройкам это в пределах того, как домашнее секьюрити понимается ширнармассами... и тем не менее взломов сотнями тысяч и миллионами не наблюдалось. Индустрия смогла пройти между "открыто всем" и "не покупают потому, что слишком сложно".

Здравствуйте, ·, Вы писали:

N>>Мне странно, что такие базовые вещи приходится разъяснять.
·>Т.е. ты не понимаешь разницу между безопасностью и приватностью.

Это ты показал принципиальное непонимание, что такое безопасность.

·> Не хочу спорить о терминологии, бесполезно, да и оффтоп. Вернёмся к теме: расскажи, какую _безопасность_, по-твоему, эти трое предложили обеспечивать в том rfc? С цитатой, твоя интерпретация не нужна.

Уже всё сказано раньше в треде, рекомендую перечитать.

N>>·>NAT64 в смысле? Ну да, нужен, конечно. Но есть нюанс.
N>>NAT66 точно так же.
·>Гы.. И зачем же он _нужен_? И тем более в stateful виде с динамическими таблицами трансляции как в ipv4?!

И это было сказано.

N>>>>А вы не ограничивайтесь мобилками. Типовой виндовый десктоп-лаптоп, особенно в корпоративной локалке, имеет несколько таких сервисов. А дальше принтеры, файловые серверы и тому подобное.
N>>·>И? Чем поможет NAT?
N>>Резко (а то и полностью) сократит возможности нежелательного доступа снаружи.
·> Доступом снаружи занимается firewall, а не NAT.

Как обычно на RSDN, знак facepalm означает "у меня нет аргументов, но я не в состоянии это признать".

[skip остаток за бессмысленностью]

Здравствуйте, ·, Вы писали:

·>У тебя, похоже, проблемы с пониманием распределённых и децентрализованнных систем. Вспомнился этот

Автор: ·
Дата: 23.02.22

флейм, когда у тебя было непонимание принципов работы git.

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

Спасибо, мне всё ясно.

Здравствуйте, Pzz, Вы писали:

N>>И к системам внутри это тоже относится. Передаваемое по PCI или USB обычно не шифруется и не подписывается, эти меры применяются уже снаружи от них. Точно так же поставить внутренние серверы с доступом только через VPN и расслабиться, допуская общие для всех ресурсы видимыми без паролей — нормальная идея.

Pzz>Не то, чтобы я был готов оспаривать твой тезис, но не могу по случаю не вспомнить про светлую идею подключить через JS к web-у USB и Bluetooth.
Pzz>Уверен, что по мере внедрения этих дивных технологий мы прочтем еще много интересных новостей из загадочного и увлекательного мира компьютерной безопасности.

Ну там, наверно, хотя бы HTTPS

N>>А теперь скажи мне, как сделать простой и удобный (и межвендорски универсальный) раздатчик https сертификатов для локалки, раз уж ты предлагаешь, чтобы даже поход на местный файловый сервер шифровать. И чтобы все браузеры автоматом подтягивали всё нужное. Q?

Pzz>Прям даже и задачу могу конкретную подкинуть. Современные принтеры-сканеры общаются с внешним миром по протоколу на основе HTTP (IPP, eSCL), и он, естественно, бывает и в варианте HTTPS. Но только толку от этого HTTPS-а не много, потому, что сертификаты в ентих принтерах самоподписанные и припаянные на фабрике.
Pzz>Интересно, можно ли получить от этого HTTPS-а больше пользы, чем есть сейчас?
Pzz>P.S. Кстати, если у CUPS-а на знакомом ему принтере поменяется сертификат, то CUPS встанет в положение "в принтере завелся хакер, требуется вмешательство админа", и больше печатать не будет, пока не придет админ и не починет.

Вариант самоподписи для данной ситуации достаточно неплохой. Потому что когда у тебя железка перестаёт работать, потому что промежуточный элемент цепочки сертификатов просрочился по not after constraint, а обновить прошивку фиг, как-то обидно. Это одна из существеннейших проблем PKI.
Но ничто не мешает делать промежуточные варианты типа "все принтеры HP выпуска 2022 года", если корневой приватный ключ потом торжественно уничтожен со своим носителем (лаптоп в железной коробке) методом сожжения термитом на камеру под пляски мумбо-юмбо

Здравствуйте, netch80, Вы писали:

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

N>Ну там, наверно, хотя бы HTTPS

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

N>>>А теперь скажи мне, как сделать простой и удобный (и межвендорски универсальный) раздатчик https сертификатов для локалки, раз уж ты предлагаешь, чтобы даже поход на местный файловый сервер шифровать. И чтобы все браузеры автоматом подтягивали всё нужное. Q?

N>Вариант самоподписи для данной ситуации достаточно неплохой. Потому что когда у тебя железка перестаёт работать, потому что промежуточный элемент цепочки сертификатов просрочился по not after constraint, а обновить прошивку фиг, как-то обидно. Это одна из существеннейших проблем PKI.

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

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

Здравствуйте, netch80, Вы писали:

N>>>Мне странно, что такие базовые вещи приходится разъяснять.
N>·>Т.е. ты не понимаешь разницу между безопасностью и приватностью.
N>Это ты показал принципиальное непонимание, что такое безопасность.
Конечно, твоё личное понимание самое правильное, спорить не буду, т.к. интересно оно только тебе. Но я, по крайней мере, по этому вопросу я нахожусь в компании трёх из уважаемой организации IETF.

N>·> Не хочу спорить о терминологии, бесполезно, да и оффтоп. Вернёмся к теме: расскажи, какую _безопасность_, по-твоему, эти трое предложили обеспечивать в том rfc? С цитатой, твоя интерпретация не нужна.
N>Уже всё сказано раньше в треде, рекомендую перечитать.
Врёшь. Цитат уж точно не было, а твои фантазии интересны только тебе.

N>>>NAT66 точно так же.
N>·>Гы.. И зачем же он _нужен_? И тем более в stateful виде с динамическими таблицами трансляции как в ipv4?!
N>И это было сказано.
Были лишь перепевки очередных безграмотных мифов: "а давайте сделаем NAT, так безопаснее".

N>>>·>И? Чем поможет NAT?
N>>>Резко (а то и полностью) сократит возможности нежелательного доступа снаружи.
N>·> Доступом снаружи занимается firewall, а не NAT.
N>Как обычно на RSDN, знак facepalm означает "у меня нет аргументов, но я не в состоянии это признать".
В данном случае означает, что ты просто игнорируешь аргументы. NAT никогда не был и не должен быть security feature. Это костыль для 4. Addressable не означает reachable. Секьюрностью занимается firewall, encryption и прочий IPSec.

Здравствуйте, Pzz, Вы писали:

Pzz>Прям даже и задачу могу конкретную подкинуть. Современные принтеры-сканеры общаются с внешним миром по протоколу на основе HTTP (IPP, eSCL), и он, естественно, бывает и в варианте HTTPS. Но только толку от этого HTTPS-а не много, потому, что сертификаты в ентих принтерах самоподписанные и припаянные на фабрике.
Для дома этого хватит более-менее. А в случае:

Pzz>P.S. Кстати, если у CUPS-а на знакомом ему принтере поменяется сертификат, то CUPS встанет в положение "в принтере завелся хакер, требуется вмешательство админа", и больше печатать не будет, пока не придет админ и не починет.
Значит уже это организация с админами и они будут поддерживать свою инфру с сертами и заливать свои, заменяя дефолтные в принтерах. А других-то вариантов нет. Либо мы отвечаем за безопасность и имеем безопасность, либо не отвечаем и не имеем; чудес не бывает.

Здравствуйте, netch80, Вы писали:

N>·>У тебя, похоже, проблемы с пониманием распределённых и децентрализованнных систем. Вспомнился этот

Автор: ·
Дата: 23.02.22

флейм, когда у тебя было непонимание принципов работы git.
N>Ну это вообще уже суперхуцпа — взять совершенно другую дискуссию, в которой ты ничего не смог доказать кроме собственной вкусовщины, и связать с текущей темой намёками в стиле "он меня рыбкой назвал, значит, сукой обозвал".
В том топике я описал рекомендуемый способ работы с распределённой СКВ, поддерживающей мержи. Собственно ради возможности реализации таких спосбов работы такие СКВ и стали придумывать.
Ты вкусным называл подходы, традиционно принятые в централизованных СКВ, не умеющих мержить, типа svn.
Так и в этом топике ты не понимаешь суть архитектурных решений в ipv6, позволяющих создавать stateless схемы и добиться децентрализации. Ради этого и придумывали ipv6.

N>Спасибо, мне всё ясно.
У тебя систематическая ошибка мышления.