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

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

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

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

Ещё немного про 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.

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

Если у вас сайт банка, но “общие” страницы отдаются по HTTP, а не по HTTPS, это означает, что кто-то может легко подменить часть кода веб-страницы на пути к пользовательскому компьютеру (или заменить всю страницу). Такая подмена позволяет внести изменения в тексты на странице (скажем, сообщить об “отзыве” лицензии), при этом у пользователя нет никаких инструментов, позволяющих проверить, получает ли он информацию в неизменном виде.

HTTPS решает эти проблемы: изменить страницы на промежуточном узле простым способом не получится (что, естественно, не отменяет возможного перехвата HTTPS, но переводит задачу на принципиально иной уровень сложности). Конечно, всегда остаётся доступен старый способ: принудительная замена протокола на стороне пользователя, которая хорошо работает для ссылок (простая замена https:// на http://). Однако если пользователь привык заходить на сайт банка по браузерной закладке (типичный сценарий, кстати), попытка подмены протокола, – например, через редирект, – вызовет предупреждение в браузере (потому что для выполнения HTTP-редиректа тоже потребуется серверный SSL-сертификат, а его, скорее всего, у перехватывающего соединение узла нет).

И не стоит забывать о том, что уже есть поддерживаемые браузерами инструменты, позволяющие жёстко назначить HTTPS единственным протоколом для веб-сайта. Пример: HTTP Strict Transport Security.

На сайте журнала “Доменные имена” – появился свежий номер в формате PDF, который можно скачать (сам бумажный журнал есть в офисах RU-CENTER, в том числе, как я понимаю, у региональных представителей; также журнал нередко встречается на профильных мероприятиях).

В Wired публикуют статью о том, что спецслужбы США (АНБ, в основном) не собирают больших справочных баз данных по уязвимостям в ПО, неизвестным широкой общественности. Речь идёт о практике публикации (или, наоборот, сокрытия) информации об уязвимостях, которые находят аналитики АНБ (и других профильных агентств). Если уязвимость сохраняется в секрете, то её можно длительное время использовать для атак на информационные системы. Однако от этой же уязвимости, как пишут, могут пострадать информационные системы США – то есть, лучше бы её опубликовать, чтобы разработчики заткнули дыру. Такая дилемма.

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

Для того, чтобы сведения о найденной уязвимости донести до разработчиков, пришлось бы готовить небольшую операцию прикрытия. А какой в ней смысл? Безопасность государственных программных систем, в которых тоже есть известные АНБ незакрытые уязвимости, можно обеспечить другими способами. А главное – вовсе не факт, что обоюдная угроза от незакрытых уязвимостей вообще как-то беспокоит те подразделения АНБ, которые занимаются проникновением в информационные системы: перед ними стоят другие задачи и самостоятельно лишать себя инструментов они вряд ли станут. Собственно, об этом и говорится в статье по ссылке, но только под соусом из всяких уточнений и оговорок.

На прошлой неделе в Китае впервые продемонстрировали изумлённой публике новый боевой самолёт – многоцелевой истребитель FС-31. У самолёта есть многие внешние признаки малозаметного истребителя, но как там обстоит дело в реальности, конечно, не ясно.

(Больше фото – в первоисточнике: aviationweek.com.)

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

Форма крыла, расположение килей – конечно, некоторым образом напоминают F-22, а ещё больше – F-35 (там, впрочем, один двигатель), но говорить о копировании нельзя, потому что, с точки зрения аэродинамики, различия тут весьма значительные. Достаточно сравнить вид снизу (масштабы для двух самолётов на картинках разные):

(Китайский истребитель и F-22.)

(Китайский истребитель и F-35.)

Разительно отличаются не только крыло в плане, но и компоновка воздухозаборников, и расположение двигателей. В общем, возможно, это не ультрасовременный самолёт, но он показывает, что технологии в Китае двигаются очень быстро. Хотя, конечно, основная проблема – двигатели.

Аппарат NASA Orion, предназначенный для полётов астронавтов на дальние орбиты (выше низкой околоземной орбиты), готовят к первому испытательному полёту. Старт намечен на 4 декабря. Естественно, полёт пройдёт без экипажа. Программа предусматривает вывод аппарата на высоту около 5700 км (это далеко), с последующим снижением и атмосферным торможением, которое требуется для тестирования теплового щита. Окончится всё должно приводнением в Тихом океане. Схема полёта (по клику – в большем разрешении):

(На сайте Universe Today приводят инфографику NASA, где все этапы разобраны подробнее.)