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

Собственно, добавил в зону dxdt.ru TLSA-запись, содержание которой соответствует отпечатку (SHA-256) серверного сертификата – это означает, что для dxdt.ru теперь заработала поддержка DANE (технологии, позволяющей с помощью DNSSEC защитить домен от подмены SSL-сертификата). Вот бы ещё DANE, наконец-то, стали поддерживать браузеры.

После того, как я перевёл dxdt.ru на HTTPS, можно сказать, что на сайте используются обе современные ключевые интернетовские технологии обеспечения безопасности. Вторая – это DNSSEC: домен dxdt.ru подписан с декабря 2012 года (пора, наверное, поменять ключи). Для полноты картины осталось добавить запись DANE TLSA, как это сделано на тестовом сервере 1d.pw.

(Кстати, предлагали сразу добавить SPDY – это разработанный с подачи и при ключевом участии Google перспективный протокол, оптимизирующий загрузку веб-страниц через TLS-соединение. На мой взгляд, хоть SPDY и поддерживают современные браузеры, но это всё ещё экзотика, не хуже DANE или даже DNSSEC, так что можно подождать HTTP/2.)

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

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

Symantec публикует описание (не очень-то подробное) архитектуры пакета шпионского ПО (платформа Windows) под названием Regin. На первой же странице утверждается, что разработка подобного пакета требует несколько человеко-лет деятельности высококвалифицированного специалиста (речь идёт о рабочей группе). И, естественно, в СМИ уже намекают, что Regin – инструмент, созданный на уровне государственных служб.

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

Занятно, что 64-битная версия Regin не использует модулей, устанавливаемых как системные драйверы – в 32-битной версии такой метод используется. В Symantec объясняют это тем, что для 64-битной ОС Windows драйверы, подключаемые в ядро, должны быть подписаны электронной подписью. Выходит, разработчики продукта не смогли получить нужных ключей. Или – не захотели вводить в свой продукт единую точку блокировки.

Наиболее популярные автономные роботы, которые сейчас строят энтузиасты, это, без сомнения, беспилотники. Летательные аппараты оснащаются автопилотами, построенными на базе готовых решений, и уверенно осуществляют автономный полёт по программе. Естественно, следующий шаг – плавучие роботы: используя аналогичные средства навигации, такой робот, если его добротно сконструировать, мог бы пересечь даже океан (проекты уже есть). Роботу важно не пойти ко дну – остальное, при правильно выбранной точке старта, сделают ветер и течения. Но если робот всё же начал тонуть? Это ещё интереснее: подводный автономный робот – вот действительно занимательная задача.

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

Следующая масштабная проблема – навигационная система. Из-под воды нет доступа к GPS, поэтому придётся либо городить некий перископ с GPS-антеннами, либо использовать только автономную инерциальную навигационную систему. Конечно, возможен и комбинированный вариант. Предположить, что построенный энтузиастами подводный автономный аппарат сможет ориентироваться по рельефу дна или каким-нибудь гидроакустическим маякам, будет слишком смело. Впрочем, инерциальная навигационная система нужной точности выглядит ещё более сомнительно: сконструировать и построить её силами энтузиастов едва ли возможно (да и силами специалистов – тоже). То есть, потребуется комбинированная система, с коррекцией по GPS. Всё равно неподъёмная, пока что, задача.

И остаётся целый пласт других проблем: как управлять движением аппарата, как обеспечивать его энергией в течение длительного времени подводного хода, как поддерживать связь. И, кстати, как уберечься от морских животных, будь то рыбы или какие-нибудь любопытные китообразные?

Как известно, между пользователем и Интернетом существует компьютер (или другое сходное вычислительное устройство) – напрямую в Сеть всегда выходят именно устройства, которыми управляют пользователи. Поэтому инструменты, позволяющие построить пользовательский профиль на основе анализа трафика, постоянно сталкиваются с проблемами: ведь они профилируют компьютеры, а не реальных пользователей.

Конечно, есть персональные аккаунты на разных сайтах, но их всё равно заводит компьютер, хоть и, вероятно, на основе команд пользователей. Вопрос с идентификацией реальных людей, а не компьютеров, принципиален для массовой интернет-слежки: источник активности в Сети должен быть точно известен. Процитирую свою статью в “Доменных именах”:

Если точной дифференциации источников нет, а ваша система не умеет отличать одного гражданина от другого, то следы начинают путаться, потому что деятельность двух различных граждан в Интернете оказывается приписана одному собирательному образу. Эта оплошность тут же рушит общую картину, ведь носителя этого собирательного образа в мире не существует. Это означает, что построенный поведенческий профиль будет содержать большую ошибку, что потянет за собой проблемы с предсказанием действий и, на следующем шаге, с сопоставлением новых следов, найденных в трафике. Аналитика, работающая на пользовательском трафике, сложна, а ее алгоритмы содержат много внутренних связей. Так что, если на одном участке базы данных ваша система не смогла отличить Петра Владимировича от Владимира Петровича, будьте уверены: из-за этого на другом участке базы данных перепутаются Ольга Семеновна и Марина Ивановна.

Ещё немного про TLS/SSL: Let’s Encrypt – это инициатива по созданию общедоступного бесплатного удостоверяющего центра (УЦ), а также программных инструментов и сервиса автоматической выдачи сайтам SSL-сертификатов, признаваемых браузерами. Более того, обещают, что сопутствующее ПО будет автоматически настраивать веб-сервер для работы по HTTPS.

Чуть подробнее: предполагается, что утилита Let’s Encrypt, будучи запущенной на сервере, сама сгенерирует ключи, свяжется с удостоверяющим центром, подтвердит управление сайтом (владение доменом), закажет и получит SSL-сертификат и настроит веб-сервер для работы с ним. Всё это с использованием специального протокола, который был разработан ранее. И бесплатно.

Выглядит, конечно, привлекательно. Но вызывает сомнение высокая степень автоматизации: всё ж SSL/TLS иногда требует обдумывания действий, иначе безопасность не повышается, а скорее наоборот. Всякое тиражное решение несёт с собой риск тиражирования не только хороших, правильных практик, но и ошибок, которые сделали разработчики решения. Можно спорить, насколько сильно нужно ошибиться в сервисе, автоматически внедряющем HTTPS на сервере, чтобы в результате ошибки уровень безопасности для этого сервера снизился – предполагается, что до момента запуска Let’s Encrypt сервер вообще использовал открытый протокол HTTP. Всяческие сценарии с захватом управления веб-сервером и автоматическим выпуском сертификата для его домена не очень пугают, так как если кто-то получил управление сервером, то он и так может сделать с ним всё что угодно, в том числе заказать сертификат (тут, впрочем, может потребоваться ещё и контроль электронной почты под доменом). Но, естественно, бесплатность процедуры несколько упрощает атаку.

Нет сомнений, что подобный сервис, к сожалению, окажется удобен для различных фишерских доменов, среди которых есть и простые тайпсквотерские (yanclex.ru), и более хитрые, комбинированные: например, что-нибудь вроде ssl-yandex.ru. Возможность быстро выпустить бесплатный сертификат и поднять HTTPS, вызывающий дополнительное доверие пользователей – она не может быть лишней. Впрочем, сейчас для этих же целей успешно выпускаются платные сертификаты DV (с валидацией по домену), с подставными реквизитами: возможности определить степень легитимности домена УЦ не имеет. Так что радикально Let’s Encrypt тут ситуацию не изменит.

Запуск сервиса обещают летом 2015 года. В числе участников инициативы значатся Mozilla и IdenTrust (это действующий УЦ), то есть можно ожидать появления нового УЦ как минимум в одном распространённом браузере. Как я понимаю, на первых порах Let’s Encrypt планирует вообще использовать для работы корень IdenTrust, с отдельным промежуточным сертификатом (по крайней мере, сейчас у них на сервере HTTPS устроен именно так). В общем, посмотрим, что получится.

Сделал HTTPS основным протоколом на dxdt.ru. Теперь, при обращении по HTTP, сервер отвечает редиректом (301) на соответствующий URL с HTTPS.

Каких-то проблем тотальная замена протокола не вызвала, что удивительно. Пришлось, впрочем, поправить все ссылки в базе WordPress-а: эта CMS генерирует абсолютные ссылки с указанием протокола (было – http://) и пишет их в БД. Задача решалась в лоб: выгрузкой дампа базы и заменой силами Perl-а http на https в подходящих местах, с последующей загрузкой дампа обратно; так что, в принципе, могут быть некоторые накладки (но пока что обнаружить их не удалось).

Сейчас никаких предупреждений о “небезопасном содержимом” быть не должно, всё работает только по HTTPS. Если обнаружите ошибки и дефекты – просьба сообщить в комментариях к этой заметке или по электронной почте.

(Основная стратегическая трудность – нагрузка на сервер: HTTPS увеличивает её в разы, но, надеюсь, скромных ресурсов хватит.)

Пробую постепенно переводить dxdt.ru на HTTPS, в качестве основного протокола. Получил и уже установил на сервер SSL-сертификат от хорошо известного (браузерам) удостоверяющего центра COMODO. Раньше использовался сертификат, выпущенный моим собственным УЦ, который, естественно, в стандартный браузерный набор корней не входит. Поэтому, при обращении по HTTPS, можно было наблюдать предупреждение системы безопасности (если только корень моего УЦ не был импортирован в браузер). Сейчас такого предупреждения быть уже не должно: https://dxdt.ru/.

Осталось поправить ссылки на элементы страниц: разные картинки и, например, файлы CSS, загружаются по HTTP, потому что так указано в коде. Соответственно, сейчас страницы dxdt.ru, загруженные по HTTPS, содержат “небезопасные” элементы. Но это исправимо. Следующий этап: безусловный редирект с HTTP на HTTPS, то есть, по HTTP страницы передаваться не будут.

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

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

Очередной раз обновил список избранных записок dxdt.ru.