dxdt.blog: занимательный интернет-журнал

В рамках проекта КЦ и ТЦИ “Домены Россиии” (statdom.ru) – мы добавили статистику TLS по российским зонам. (Официальная новость.) Приведено несколько основных отчётов, позволяющих понять, как развивается HTTPS: общая статистика, а также данные по алгоритмам и ключам. Данные собираются именно для HTTPS – то есть, это 443/tcp. Приведены результаты, начиная с июля прошлого года (2015). У меня на dxdt.ru есть некоторые данные по TLS/SSL в Рунете за 2011 год, это почти пять лет назад (да и методика сбора там другая). За это время, например, число самоподписанных сертификатов сократилось более чем в два раза: 52173 (тогда) против 23931 (сейчас). А ECDSA тогда просто не было.

Если посмотреть в выборку по корректным HTTPS-узлам (это узлы, вернувшие валидный сертификат, совпавший по имени), то видно, как стремительно растёт проникновение HTTPS: за семь месяцев в зоне .RU число HTTPS-узлов выросло почти, примерно, на 21 тыс. с 34205 до 55781. Из новинок: Let’s Encrypt – добавляет почти по тысяче в месяц, это видно в отчёте по Top 10 удостоверяющих центров.

Методика кратко описана на соответствующей странице statdom.ru.

Шумная история: после обновления iOS, некоторые аппараты iPhone, которые ремонтировались в неавторизованных мастерских, оказались нерабочими (вроде бы, причина – замена сенсора-считывателя отпечатка пальца). Есть множество историй, в которых “выкатка” обновления ПО убивает то или иное устройство. Но в этот раз опять вспомнили о том, что системное программное обеспечение используется и при управлении различными производствами (набравшая наконец популярность тема безопасности АСУ ТП). А раз “внешний” владелец ПО может отключить iPhone, то почему бы не проделать то же самое и с промышленными системами? Про станки, которые дистанционно получают обновления, а также могут быть дистанционно заблокированы разработчиком, если, например, не продлён срок договора обслуживания, – давно известно. Но ещё старше предлагаемое решение: мол, давайте отключим станки и оборудование от Интернета (а программное обеспечение, стало быть, всё равно оставим без изменений), чтобы обезопасить систему управления от отключения извне. В современной ситуации – неправильное решение, и очень наивное.

Зловред Stuxnet, портивший иранские центрифуги на урановом производстве, был занесён в промышленную сеть на “флешке”. Реальность информационной безопасности на производствах, в типичных корпоративных сетях, такова, что если сеть вообще работает, то сейчас для проведения атаки не так уж и важно, подключена она к Интернету или нет. Главное, чтобы компьютеры были соединены между собой, а точка проникновения через наивный “воздушный зазор” (air gap) – найдётся. На практике, из-за человеческого фактора, отсутствие подключения к Интернету и массовое перемещение “флешек” – делают ситуацию хуже, потому что для атаки со стороны USB системы гораздо более уязвимы, чем для атаки из Интернета. (Интернет, кстати – всё равно всегда находится рядом, буквально в одном “хопе”: будь то смартфон или “нелегально” пронесённый 4G-модем, который подключен к компьютеру на рабочем месте. Поделать с этим ничего нельзя, так как отказываться от глобальной Сети, мягко говоря, невыгодно в стратегическом смысле.)

Конечно, не следует делать вывод, что нужно все производственные системы подключить напрямую к Сети. Нет, подключать не нужно. Но в современной ситуации рассчитывать на то, что отсутствие такого подключения как-то защищает “чужую” систему от отключения в критической ситуации – наивно. От легитимного отключения, реализованного банально – да, защитит. Но уже чуть более продвинутое решение, подразумевающее закладку в оборудовании, срабатывающую по времени отсутствия обновлений, вопрос с таким отключением полностью снимает. Кроме того, если говорить о промышленных системах, там передача сигналов возможна иными методами. Если аппаратура, техпроцесс, или управляющее программное обеспечение, хотя бы один из этих элементов – что-то вроде чёрного ящика для тех, кто оборудование использует (а это, обычно, так, к сожалению), то “отключающая закладка” может быть активирована при помощи сигнала, полученного через тот или иной датчик, или, если хотите, даже через изменение химического состава сырья. Или производство останавливается из-за того, что смартфон одного из рабочих “пропищал” своим динамиком кодовую последовательность на высоких частотах, её принял ультразвуковой дальномер, измеряющий уровень масла в котле-смесителе, принял – и просигналил в центральную автоматическую систему управления, которая быстренько сломала весь цех и сама вырубилась (на всякий случай, вместе с телефонией и электричеством). Кажется фантастикой. Но это только кажется, да и казаться будет не долго: потому что к популярной теме “кибербезопасности” АСУ ТП подходят с навыками защиты офисного “домена Windows”, а с промышленными системами ситуация сложнее.

Кстати, что касается Windows XP, которая, якобы, “управляет британскими подводными лодками с ядерным оружием”: возможно, эта система и работает на каких-то компьютерах, находящихся на борту, но вряд ли чем-то на лодке управляет. Дело в том, что Windows XP – не является системой реального времени: с ней всегда были проблемы при попытках управления тем или иным оборудованием. Соответственно, встроенные системы используют другие ОС, обычно, это UNIX-подобные (из-за POSIX, но это детали) ОС реального времени.

Вообще, если речь идёт о системах из 90-х годов прошлого века (это означает, что разрабатывались-то они в конце 80-х), можно было бы поверить, что на борту есть управляющие вычислительные машины, работающие под MS-DOS. Это маловероятно, но такое можно представить, потому что под MS-DOS приложения реального времени работают хорошо, мне, в 90-х, приходилось такие видеть лично. Но XP – это что-то журналисты напутали (особенно, если учитывать, что система выпущена в 2001).

На фотографии из коллекции Библиотеки Конгресса – кормовой отсек подводной лодки, которая обозначена как германская. Как пишут, фотография сделана около 1915 года. Видны двигатели, гребные валы (два) и прочее оборудование.

(Та же картинка – в более высоком разрешении.)

Появился новый робот, быстро собирающий кубик Рубика – он справляется примерно за секунду (по ссылке с картинки – видео на Youtube.com):

Конкретно это решение можно, конечно, покритиковать: там четыре камеры; нужен специально подготовленный кубик (насадки на валах электродвигателей входят в механическое зацепление с центральными элементами сторон кубика); кубик устанавливается в заранее заданном положении (манипуляторы размечены по цветам) и так далее, и тому подобное. Однако интереснее подумать, насколько вообще можно улучшить результат. Вычислительные мощности доступны, поэтому механическая составляющая робота оказывается важным фактором, устанавливающим границы.

Если я не путаю, то сейчас известно, что из любой конфигурации кубик (3×3) собирается не более, чем за 26 ходов, если ходом называется поворот грани на 90 градусов. При этом большинство конфигураций лежат на два-три хода ближе к собранному кубику. Для оценки точное число ходов не так важно. Примем, что типичная сложная конфигурация – 25 ходов. То есть, если поворачивать грань за 10 миллисекунд на 90 градусов, то с преобразованиями конфигурации можно уложиться в 250 мс (плюс затраты на “переключение” граней – но не будем их учитывать). 10 мс – это 9000 градусов или 25 оборотов в секунду. Сама по себе, скорость вращения не очень большая, добротный кубик её наверняка выдержит. Заметные потери времени при “миллисекундном разрешении” будут связаны с разгоном грани – отсюда и идеи с механическим зацеплением. Для немодифицированного кубика быстрый разгон при начале вращения грани составит серьёзную техническую проблему.

Работа робота сводится к определению начальной конфигурации кубика, вычислению оптимального (или близкого к оптимальному) пути из этой конфигурации к собранному кубику, выполнению ходов. Интересно, что оптимальный путь здесь не обязательно кратчайший. Дело в том, что оптимизировать нужно с учётом исполнительного механизма, а он может какие-то ходы выполнять быстрее, а какие-то – медленнее. Например, очевидно, что все повороты должны осуществляться в одну сторону, что некоторые ходы поддаются механическому “распараллеливанию”, а некоторые – нет, и так далее. Изображение кубика требуется получить только один раз, для определения начальной позиции. Причём это изображение может быть низкого разрешения и известной геометрии, так что сколь-нибудь заметного времени на передачу и распознавание не потребуется. Основное вычислительное время – поиск оптимального пути сборки. После того, как получен список ходов – он отправляется в контроллер механизма, который максимально быстро выполняет их, передавая команды исполнительным механизмам. Логично использовать простейший контроллер, а максимум вычислений проводить на управляющем компьютере: результатом работы программы будет являться набор команд на поворот валов электродвигателей, который и передаётся в контроллер (алгоритм выполнения команд должен учитывать параллельное выполнение, так что контроллеру потребуется память и логика, позволяющая одновременно управлять несколькими двигателями).

В общем, тема эта весьма интересная, а особенное техническое развитие она получает после преодоления секундного барьера. (Человеческий рекорд, кстати, чуть менее 5 секунд.)

Сейчас в СМИ очередная волна сравнения различных программных систем по числу обнаруженных уязвимостей. При этом во многих публикациях системы, с меньшим числом обнаруженных уязвимостей называют “более безопасными”, сравнивая их с теми системами, где уязвимостей нашли больше. Однако это неправильно. Такой показатель, как число обнаруженных за некоторый промежуток времени уязвимостей – очень слабо связан с реальной безопасностью использования той или иной системы, даже в случае, если речь идёт о ситуации “при прочих равных”, например, когда сравнивают два распространённых браузера. Число обнаруженных уязвимостей может, разве что, косвенно свидетельствовать о том, какая система более популярна у исследователей. (Это если опустить тот факт, что корректное определение понятия “безопасности” вообще весьма сложно для программного продукта.)

Почему это так? Прежде всего потому, что процесс обнаружения уязвимостей – нестабильный, а сами уязвимости – весьма различны по своему влиянию на степень безопасности использования программной системы. Более того, у разных разработчиков – разные методики и планы реагирования на обнаружение уязвимости. А также – не существует универсального “закона сохранения уязвимостей”. Другими словами: то, что в браузере “Имярек” обнаружили лишь десять уязвимостей, приводящих к отказу в работе, не означает, что в этом браузере нет ещё одной, но уже позволяющей удалённо выполнить произвольный код. А то, что в операционной системе “Имярек-2” обнаружили тысячу уязвимостей, скорее всего никак не повлияло на наличие или отсутствие уязвимостей в другой, не менее распространённой, операционной системе, в которой уязвимостей нашли пока что только сотню. (Хотя, в последнем случае можно предположить, что разработчики второй системы чему-то научились на опыте авторов первой, да и залатали дыры заранее; но, к сожалению, практика показывает, что это скорее фантастика, чем реальность.)

Основа практической работоспособности криптовалюты Биткоин – вычислительная мощность сети узлов-майнеров, которые вычисляют заголовки блоков. Если посмотреть на статистику по текущему распределению (предполагаемому) мощности сети на сайте blockchain.info, то нетрудно подсчитать, что около 60% этой мощности контролируют китайские пулы (AntPool, F2Pool и BTCC Pool). (Пулы – это объединения майнеров, действующих согласованно, и делящих полученную от майнинга биткоин-прибыль.)

Вообще, согласно протоколу, 60% мощности позволяют полностью контролировать сеть и, соответственно, саму валюту. Это довольно интересное положение дел. Пока, впрочем, каких-то активных контролирующих воздействий не заметно, ну, кроме странной ситуации вокруг увеличения размера блока (то есть, грубо говоря, увеличения числа транзакций, проводимых сетью в единицу времени).

В самом конце прошлого года вышел второй номер журнала “Интернет изнутри” (он издаётся при поддержке “МСК-IX”). Журнал рассказывает детали о технологиях, лежащих в основе Сети, посвящая читателя (предполагается, что это достаточно подготовленный читатель) в особенности применения тех или иных решений. Например, во втором номере – статьи про утечки маршрутов (BGP) и рефлекторные атаки. В этом номере также опубликована моя большая статья про TLS: “TLS: двадцать лет спустя”. Журнал доступен в формате PDF на сайте – рекомендую.

Сайт dxdt.ru в действующем сейчас формате заработал десять лет назад: в январе 2006 года. Традиционно, день рождения сайта назначен на 5 января, то есть, сегодня. Блок статистики в панели управления CMS подсказывает, что на сайте опубликовано 2392 записки и 10878 комментариев. В прошлом году, тоже 5 января, записок было 2257 – прирост чрезвычайно мал (135 новых записок), но будем надеяться, что не количество тут важно. (Комментариев добавлено 418.) Надо заметить, что сайтов, действующих и сохраняющих парадигму в течение десяти и более лет, в Рунете не так уж и много.

Основное преимущество десятилетнего возраста dxdt.ru в том, что можно от случая к случаю удачно ссылаться на старые записки, в стиле: “а я ещё пять лет назад писал, что так будет, и вот – посмотрите”. Я иногда позволяю себе так делать.

Спасибо, что читаете!

Занятная статья Кори Доктороу о потенциальном “конфликте интересов”, связанном с тем, какие решения принимает автомобиль-робот в критических ситуациях – кого приносить в жертву. Речь о том, что владелец может вмешаться в логику распределения ущерба, “перепрошив” автомобиль. Интересное наблюдение: программно-аппаратная система должна бы включать защиту от перепрошивки базовых функций, но от этой защитной схемы, традиционно, могут потребовать наличия “официальных бэкдоров”, необходимых для специальных случаев: например, управление автомобилем перехватывает полицейский дрон. Бэкдоры, при этом, могут оказаться доступными для злоумышленников. Это означает, что о том, какие алгоритмы распределения ущерба будут в реальности применяться – останется только догадываться. И вряд ли стоит рассчитывать на победу наивной концепции, согласно которой достаточно “зашить” в управляющий компьютер строгое следование правилам дорожного движения, чтобы снять все этические и юридические проблемы, возникающие в момент, когда автомобиль будет делать выбор – наехать ли на группу пешеходов, перебегающих дорогу, или отвернуть, врезавшись в стену, пожертвовав, таким образом, своим пассажиром.