Вы на канцелярит, кстати, особо не наезжайте: относитесь к нему как к языку программирования, только не для электронной машины, а для бюрократической. Причём язык весьма низкоуровневый и начисто лишенный сахара. Отчего две с половиной строчки бизнес логики теряются в абзацах бойлерплейт кода.
И, да, "светочувствительные проводники" (и даже "проводники светочувствительные") это не канцелярит, а некомпетентность (хотя нельзя исключать и того, что такой кривой термин был внесен совершенно осознанно)
Не столь давно были времена, когда контроллер памяти был интегрирован не в процессор, а в чипсет (а самих производителей чипсетов для x86 было больше двух). И что-то и тогда не наблюдалось массового применения ECC в customer сегменте. Да и не массового, откровенно говоря, тоже не вспомню. Так что сегментировал рынок интел вполне следуя уже сложившейся традиции.
И это только про x86. Всякие ARM и причий MIPS интел под себя не подмял, но опять же не наблюдается что-то ECC ни в телефонах с хромбуками, ни в soho (и даже части не совсем уж и soho) маршрутизаторах. В последних, кстати, вполне уместно было б.
Исходная статья про ошибки связанные с воздействием ионизирующего излучения на электронные компоненты (в первую очередь - память), а не про помехи в линиях связи. Впрочем, это не столь важно: ибо описанная в статье атака пытается эксплуатировать предположение, что у кого-то из пользователей в результате искажения бита станет испорчен адрес доменное имя целевого ресурса. Процессу же разрешения доменного имени абсолютно безразлично, будет ли разрешенный адрес дальше использоваться для UDP, или TCP с TLS.
ps: нет во всяких Ethernet никакого избыточного кодирования. Лишние битики в поток данных добавляют (плюс скремблируют) не для коррекции ошибок, а для упрощения приемо-передающей части (в частности - возможности использования трансформаторной развязки, и синхронизации тактовых последовательностей).
Вот за эту избыточность (место для ее хранения) деньги и берут. Не важно, по старинке ли она отдельным корпусом на модуле распаяна, или как в DDR5 непосредственно на кристалле. А в потребительских устройствах деньги экономят.
Да и к тому же в потребительских устройствах 90+% памяти занято картинками с котиками и прочей устойчивой к искажениям единичных бит информацией: ну слетит один пиксель в каком-то элементе GUI, да и фиг с ним.
Несомненно они врядли дождутся. Но какой вклад в это вносит tls over tcp ? Вероятность того, что при безопасном для оператора радиационном фоне бит в адресе доменном имени будет испорчен непосредственно в момент установки соединения настолько мала, что ей можно полностью пренебречь. А в ситуации когда где-то в памяти доолго лежит (попорченная за время лежания) строчка c адресом доменным именем не так уж важно по udp ли будет идти коннект после резолвинга, или по tcp, а сверху - tls. Да, могут быть (а могут и не быть) нюансы с проверкой сертификата клиентом, но в логи сервера такие (попытки установки) подключения все равно попадут (при их правильной настройке).
Какой бы алгоритм не применялся, в какой бы части системы он бы не был реализован, для того, чтобы распознать (а тем более - скорректировать) ошибку в хранимой информации должна присутствовать избыточность. Т.е. в случае памяти - дополнительный физический объем. Это стоит денег.
ЕСС это уже профессиональное решение с коррекцией более сложных паттернов ошибок.
Ну прям. Классический вариант - одну [ошибку в слове] исправляем, о двух и более - сигнализируем (если повезет).
Можно, нужно и давно делается в ecc-памяти. Проблема только в том, что используется ecc‑память в основном в серверном оборудовании. В ПК, ноутбуках, планшетах‑телефонах по традиции продолжают экономить. Ну и в том, что SEU возможны не только в [основном объеме] памяти.
на компьютере с 4 Гб оперативной памяти есть 96% шанс переворота битов в течение трех дней.
ввел в адресную строку браузера домен windows.com, бит перевернулся
Пусть даже не "ввел в адресную строку" (что требует переворота бита не за три дня, а за три секунды) а "где-то в памяти хранится". Мы же понимаем, что даже при 100% вероятности переворота одного бита в 4GB памяти, вероятность того, что этот переворот произойдет именно в 16 байтах time.windows.com - , т.е. 0,0000004 %. А если учитывать то, что из этих 16 байт реально доступны для атаки всего 8 (.windows), а в этих байтах можно атаковать далеко не все биты, то шансы еще меньше.
Впрочем количество количество windows ПК столь велико, что единичные (но никак не 200000) события с обусловленным SEU доступом к условному windo7s.com представляются относительно вероятными.
А вот затея со sbis.ru практически наверняка обречена на провал: во-первых буковок меньше, а в главных - на многие порядки менше количество ПК.
А сталкивались ли вы с космической проблемой?
Каждый раз, покупая ECC-память вы сталкиваетесь с ее решением (не 100%, но близким к тому).
Если выводы в статье верные, то выходит что саботировать работу всех windows пк в одном broadcast сегменте можно простым скриптом, рассылающим ssdp-пакеты ?
Именно. И это гораздо более удобно, гибко и при этом не менее безопасно, чем огораживаться vpn.
Печаль в том, что как минимум официальное android приложение nextcloud в клиентские сертификаты не умеет.
Если же вы про использование nginx на стороне условного смартфона (приложение коннектится к nginx на localhost, который дальше проксирует соединение с использованием клиентского сертификата), то такой сетап конечно рабочий, но далек от удобного и обычным пользователем сложнонастраиваем.
Вы делаете столь общий вывод по одному посту "у меня не получилось" ? Может дело не в бобине?
Если подключение конкретно outlook от подключения конкретно smtplib возможно можно по косвенным признакам отличить друг от друга, то подключение абстрактного "почтового клиента" от абстрактного "скрипта" увы никак совсем-совсем: скрипт это такой же почтовый клиент.
По работе с документами ms office аналогов мс офису нет и вряд ли будет.
По работе с текстовыми документами и электронными таблицами софта альтернатив много. И бытовые потребности они вполне закрывают: 100 станичные экселины с кучей формул, макросов и данных из внешних источников в быту редко встречаются.
Про поддержку сканеров-принтеров и прочего железа - ну да, хуже чем с виндой, но уже давно не ужас-ужас.
Для бытового (не игрового) использования список "любых приложений" у большинства пользователей ограничивается браузером, вордом и экселем офисным пакетом.
Вы на канцелярит, кстати, особо не наезжайте: относитесь к нему как к языку программирования, только не для электронной машины, а для бюрократической. Причём язык весьма низкоуровневый и начисто лишенный сахара. Отчего две с половиной строчки бизнес логики теряются в абзацах бойлерплейт кода.
И, да, "светочувствительные проводники" (и даже "проводники светочувствительные") это не канцелярит, а некомпетентность (хотя нельзя исключать и того, что такой кривой термин был внесен совершенно осознанно)
Я бы подумал на машинный перевод, но ведь речь о наших, российских, нормативных документах?
Не столь давно были времена, когда контроллер памяти был интегрирован не в процессор, а в чипсет (а самих производителей чипсетов для x86 было больше двух). И что-то и тогда не наблюдалось массового применения ECC в customer сегменте. Да и не массового, откровенно говоря, тоже не вспомню. Так что сегментировал рынок интел вполне следуя уже сложившейся традиции.
И это только про x86. Всякие ARM и причий MIPS интел под себя не подмял, но опять же не наблюдается что-то ECC ни в телефонах с хромбуками, ни в soho (и даже части не совсем уж и soho) маршрутизаторах. В последних, кстати, вполне уместно было б.
Исходная статья про ошибки связанные с воздействием ионизирующего излучения на электронные компоненты (в первую очередь - память), а не про помехи в линиях связи.
Впрочем, это не столь важно: ибо описанная в статье атака пытается эксплуатировать предположение, что у кого-то из пользователей в результате искажения бита станет испорчен
адресдоменное имя целевого ресурса. Процессу же разрешения доменного имени абсолютно безразлично, будет ли разрешенный адрес дальше использоваться для UDP, или TCP с TLS.ps: нет во всяких Ethernet никакого избыточного кодирования. Лишние битики в поток данных добавляют (плюс скремблируют) не для коррекции ошибок, а для упрощения приемо-передающей части (в частности - возможности использования трансформаторной развязки, и синхронизации тактовых последовательностей).
Вот за эту избыточность (место для ее хранения) деньги и берут. Не важно, по старинке ли она отдельным корпусом на модуле распаяна, или как в DDR5 непосредственно на кристалле. А в потребительских устройствах деньги экономят.
Да и к тому же в потребительских устройствах 90+% памяти занято картинками
с котикамии прочей устойчивой к искажениям единичных бит информацией: ну слетит один пиксель в каком-то элементе GUI, да и фиг с ним.Несомненно они врядли дождутся.
Но какой вклад в это вносит tls over tcp ? Вероятность того, что при безопасном для оператора радиационном фоне бит в
адреседоменном имени будет испорчен непосредственно в момент установки соединения настолько мала, что ей можно полностью пренебречь.А в ситуации когда где-то в памяти доолго лежит (попорченная за время лежания) строчка c
адресомдоменным именем не так уж важно по udp ли будет идти коннект после резолвинга, или по tcp, а сверху - tls. Да, могут быть (а могут и не быть) нюансы с проверкой сертификата клиентом, но в логи сервера такие (попытки установки) подключения все равно попадут (при их правильной настройке).Какой бы алгоритм не применялся, в какой бы части системы он бы не был реализован, для того, чтобы распознать (а тем более - скорректировать) ошибку в хранимой информации должна присутствовать избыточность. Т.е. в случае памяти - дополнительный физический объем. Это стоит денег.
Ну прям. Классический вариант - одну [ошибку в слове] исправляем, о двух и более - сигнализируем (если повезет).
Можно, нужно и давно делается в ecc-памяти.
Проблема только в том, что используется ecc‑память в основном в серверном оборудовании. В ПК, ноутбуках, планшетах‑телефонах по традиции продолжают экономить. Ну и в том, что SEU возможны не только в [основном объеме] памяти.
Пусть даже не "ввел в адресную строку" (что требует переворота бита не за три дня, а за три секунды) а "где-то в памяти хранится". Мы же понимаем, что даже при 100% вероятности переворота одного бита в 4GB памяти, вероятность того, что этот переворот произойдет именно в 16 байтах time.windows.com - , т.е. 0,0000004 %. А если учитывать то, что из этих 16 байт реально доступны для атаки всего 8 (.windows), а в этих байтах можно атаковать далеко не все биты, то шансы еще меньше.
Впрочем количество количество windows ПК столь велико, что единичные (но никак не 200000) события с обусловленным SEU доступом к условному windo7s.com представляются относительно вероятными.
А вот затея со sbis.ru практически наверняка обречена на провал: во-первых буковок меньше, а в главных - на многие порядки менше количество ПК.
Каждый раз, покупая ECC-память вы сталкиваетесь с ее решением (не 100%, но близким к тому).
Фиг с ним с hisense.
Если выводы в статье верные, то выходит что саботировать работу всех windows пк в одном broadcast сегменте можно простым скриптом, рассылающим ssdp-пакеты ?
360$ в месяц не такая уж и высокая
Именно. И это гораздо более удобно, гибко и при этом не менее безопасно, чем огораживаться vpn.
Печаль в том, что как минимум официальное android приложение nextcloud в клиентские сертификаты не умеет.
Если же вы про использование nginx на стороне условного смартфона (приложение коннектится к nginx на localhost, который дальше проксирует соединение с использованием клиентского сертификата), то такой сетап конечно рабочий, но далек от удобного и обычным пользователем сложнонастраиваем.
А все эти телодвижения из-за того, что не на всех платформах приложения NC поддерживают mTLS.
PETG в большинстве случаев хорош, но ABS гораздо лучше и надежней клеится и меньше плывет под температурой
1000$
Хоть под линукс, хоть под винду
https://addons.thunderbird.net/en-US/thunderbird/addon/mail-merge/
Вы делаете столь общий вывод по одному посту "у меня не получилось" ? Может дело не в бобине?
Если подключение конкретно outlook от подключения конкретно smtplib возможно можно по косвенным признакам отличить друг от друга, то подключение абстрактного "почтового клиента" от абстрактного "скрипта" увы никак совсем-совсем: скрипт это такой же почтовый клиент.
По работе с документами ms office аналогов мс офису нет и вряд ли будет.
По работе с текстовыми документами и электронными таблицами софта альтернатив много. И бытовые потребности они вполне закрывают: 100 станичные экселины с кучей формул, макросов и данных из внешних источников в быту редко встречаются.
Про поддержку сканеров-принтеров и прочего железа - ну да, хуже чем с виндой, но уже давно не ужас-ужас.
Для бытового (не игрового) использования список "любых приложений" у большинства пользователей ограничивается браузером,
вордом и экселемофисным пакетом.