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

Появился новый робот, быстро собирающий кубик Рубика – он справляется примерно за секунду (по ссылке с картинки – видео на 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 в том, что можно от случая к случаю удачно ссылаться на старые записки, в стиле: “а я ещё пять лет назад писал, что так будет, и вот – посмотрите”. Я иногда позволяю себе так делать.

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

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

Заканчивается и 2015 год. Следующий, что логично, 2016. За прошедший год на dxdt.ru получился некоторый тематический перекос в сторону интернет-технологий: про авиацию и близкие технические области – публикаций стало меньше. (Да, собственно, частота публикаций вообще несколько снизилась.) В следующем году планирую ситуацию поменять, но, впрочем, посмотрим, как оно получится.

По традиции – несколько ссылок на записки из 2015 года:

• Обнаружение небольших беспилотников;
• Техническое: перехват TLS (HTTPS), некоторые тонкости;
• Идентификация пользователей в онлайн-играх;
• Этика, мораль и самоуправляемые автомобили;
• ЦРУ и картинка в журнале “Огонёк”.

С наступающим Новым годом!

Так как появились странные (невнятно сформулированные) слухи о недоступности DNS от Google из Рунета, я померил доступность при помощи сервиса RIPE Atlas – доступ есть, вот результат, на карте:

Измерение я проводил для 8.8.8.8, через 252 RIPE-зонда (probes), расположенных в Москве и ближайших регионах, в качестве запроса использовалось имя iana.org. Полученный адрес (верный) указан в легенде на картинке.

HPKP (HTTP Public Key Pinning) – технология, позволяющая привязать к серверу открытый ключ. Для этого служит специальное поле в заголовках HTTP. Я писал про HPKP на dxdt.ru ранее. Как и в случае практически любой технологии обеспечения информационной безопасности – интересно посмотреть, как реализация работает в деталях. Для этого я добавил HPKP на “тестовую площадку”: 1d.pw.

Напомню, кратко, как эта технология работает. При первом визите на сайт по HTTPS браузер запоминает отпечаток некоторого ключа, который передаётся в заголовке; это может быть отпечаток серверного ключа (так, например, сделано на dxdt.ru) или любого другого ключа, входящего в цепочку валидации сервера (можно добавлять ключи сертификатов удостоверяющих центров и так далее). При повторном соединении с сайтом по TLS браузер проверяет, что какой-то из ключей, предъявленных сервером, соответствует ранее записанному отпечатку. Если найти такой ключ не удалось, выдаётся сообщение об ошибке и соединение не устанавливается (именно этот вариант воспроизведён на тестовой площадке). Ситуация напоминает случай, когда браузер не смог провести успешную валидацию цепочки SSL-сертификатов, с той лишь разницей, что привязывание ключа позволяет защитить соединение от перехвата при помощи валидных сертификатов.

Отлаживать HPKP непросто. Запись отпечатка производится только в том случае, если браузер успешно установил соединение по TLS и получил ответ с корректно форматированным полем Public-Key-Pins – то есть, требуется работающий по TLS веб-сервер с валидным SSL-сертификатом. Для того, чтобы вызвать ошибку проверки отпечатка также требуется валидный сертификат: иначе браузер выдаст сообщение об ошибке раньше, чем доберётся до проверки отпечатков. При этом требуется серверный сертификат, выпущенный для другого ключа, отличающегося от “правильного”. Как-то узнавать браузер на сервере, чтобы имитировать подмену ключа, – не получится: проверка отпечатка происходит на самом раннем этапе установления TLS-соединения, ни куки-файлы, ни какие-то ещё данные “уровня приложения” к этому моменту переданы не будут. Идентифицировать по IP-адресу в наше время NAT-ов и прочих трансляторов – тоже неправильно.

Я поступил следующим образом. По адресу https://1d.pw/ откликается веб-сервер, который передаёт заголовок с отпечатком ключа и флагом, обозначающим, что отпечаток действителен для всех поддоменов (ниже я привожу поле Public-Key-Pins для 1d.pw полностью). А по адресу https://pin.1d.pw/ – откликается другой виртуальный хост, который использует другой серверный ключ (но в паре с валидным сертификатом). Если ваш браузер ещё не был на 1d.pw, то вы можете с его помощью успешно посетить pin.1d.pw. Однако если ваш браузер зайдёт на https://1d.pw/, то он запомнит отпечаток ключа. Если после этого попытаться открыть https://pin.1d.pw/, то должно появиться сообщение об ошибке (“невозможно установить защищённое соединение” или подобная формулировка) – это означает, что HPKP поддерживается браузером. Время жизни отпечатка указывается в поле Public-Key-Pins – для 1d.pw это 3600 секунд (или 1 час).

Вот заголовок HPKP:

Public-Key-Pins:pin-sha256=”afLVIYy6nD4LIkratYg295p89kYfqChllWQGYs7K8/A=”; pin-sha256=”K/QRriVzZo54i+9qeLPgP+22zWsL4rMZGFU9F0QJn/M=”; max-age=3600; includeSubdomains; report-uri=”http://hpkp-reporter.dxdt.ru/api/hpkp.pl”

Здесь есть ещё один интересный элемент – report-uri. Это адрес, по которому браузер передаёт сообщение о неудачной проверке отпечатка ключа (POST-запрос с данными в формате JSON). Я поднял отдельный обработчик для этих сообщений (планирую вынести его на другой домен и подключить, в том числе, к HKPK на dxdt.ru). Пока что данная функция работает только в Chrome, но это весьма распространённый браузер, поэтому, в теории, можно будет увидеть попытки перехвата TLS-соединений.

Посмотрим, как использование HPKP будет развиваться дальше.

Первая ступень ракеты-носителя SpaceX Falcon 9 совершила успешную посадку, а сама ракета при этом успешно вывела на орбиту несколько спутников.

Всё это обещает существенное удешевление доставки на околоземную орбиту.

В ScreenOS (это система, управляющая целым рядом сетевого оборудования Juniper Networks) обнаружили “неавторизованный” код, который позволяет получить полный доступ к системе, в том числе, можно расшифровывать VPN-трафик. То есть, обнаружили бэкдор, как пишут, в рамках внутреннего аудита:

During a recent internal code review, Juniper discovered unauthorized code in ScreenOS that could allow a knowledgeable attacker to gain administrative access to NetScreen® devices and to decrypt VPN connections.

Кстати, после выявления подобных уязвимостей – устройство нужно полностью “перепрошивать”, сбросив настройки, так как получивший доступ к системе злоумышленник мог настроить для себя другие бэкдоры.