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

Схема организации подписей и зон DNSSEC для dxdt.ru:

Картинка сгенерирована при помощи полезного сервиса DNSViz.

Кстати, довольно давно я завёл специально испорченную, в смысле DNSSEC, зону – dotsu.su. С её помощью удобно тестировать различные анализаторы DNSSEC. Текущая версия DNSViz выдаёт вполне корректную картинку для dotsu.su (раньше были сбои).

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

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

Небольшая подборка записок по теме TLS/SSL (и близким к ней), появлявшихся на dxdt.ru:

• HTTPS и “открытые веб-страницы”;
• Heartbleed, OpenSSL: работа над ошибками;
• Система прослушивания TLS/SSL от NSA. Часть 1;
• Система прослушивания TLS/SSL от NSA. Часть 2;
• Популярно о перехвате HTTPS;
• Цифровые нотариаты и административное значение TLS/SSL;
• Политика браузеров и история с SSL/TLS;
• Технология DANE: отличия от работы УЦ;
• Новинки безопасности, практикум: настройка DANE и dane.nox.su.

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

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

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

Бэкдор должен быть защищённым от перехвата. Возможность использовать его для организации утечки должна быть доступна только “уполномоченной стороне”. Это свойство очень близко к скрытности, но не является её эквивалентом: например, побочные излучения аппаратуры можно принимать, даже не зная о том, какая именно аппаратура является источником.

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

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

Конечно, большинство практических бэкдоров лишены некоторых из перечисленных выше свойств. Но где-то могут быть и идеальные представители. Просто их не так легко обнаружить.

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

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

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

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

Ещё немного про 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 увеличивает её в разы, но, надеюсь, скромных ресурсов хватит.)

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

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

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

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

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

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

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

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

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