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

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

В заметке, посвящённой этому событию, Брюс Шнайер пишет:
“Imagine a government using this sort of attack against another government, coordinating a series of fake tweets from hundreds of politicians and other public figures the day before a major election, to affect the outcome”. (Представьте, что правительство использует атаку такого типа в отношении другого правительства, скоординировав серии поддельных “твитов” от лица сотен политиков или других публичных фигур за день до важных выборов, чтобы повлиять на их результат.)

Впрочем, Шнайер (ожидаемо) предлагает регулировать Twitter и подобные крупные информационные системы на государственном уровне, аналогично банкам. Цель регулирования – обязать вводить типовые меры обеспечения безопасности. Понятно, что все инструменты, которые предотвратят подобные публикации поддельных “твитов” даже администраторами сервиса, – известны, они существуют, но внедрение требует огромных затрат (не только программно-аппаратных, но организационных, в том числе, касающихся персонала).

Интересно, что, как пишут, аккаунт Президента США Трампа не был затронут атакой. Если это произошло потому, что, силами Секретной службы и АНБ, государственные аккаунты особой важности отдельно защищены, то получается, что определённое регулирование в Twitter уже внедрено. Конечно, подобное скрытое и как бы “неформальное” регулирование – оно, во многих случаях, гораздо удобнее.

На dxdt.ru с 2016 года опубликована небольшая криптографическая библиотека для Arduino, построенная на российском шифре “Магма”. Мне иногда присылают сообщения о проблемах (ошибках, выводимых компилятором), которые возникают при сборке в новых версиях Arduino IDE. Собственно, решение упоминается в комментариях к странице, но я всё же добавил в основной текст подробное пояснение о причине трудностей и о том, как эти трудности победить. Кратко: проблема не в коде библиотеки, а в установленном по умолчанию уровне оптимизации компилятора – в старых версиях Arduino IDE установки были другие. Библиотеку можно использовать без изменений, но нужно подредактировать настройки IDE (штатным способом); второй вариант – использовать обновлённую библиотеку, где параметры оптимизации указаны в исходном коде. Подробности – на странице библиотеки.

Если взглянуть на “график” эллиптической кривой из недавней записки про протокол Диффи-Хеллмана, то практически сразу можно заметить, что эта картинка обладает хорошо различимой симметрией (как минимум, с горизонтальной осью). Поэтому часто задают вопрос: как же так, это же криптография, а картинка настолько регулярная? Предполагается, что криптографические объекты обязательно должны быть неотличимы от шума.

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

Что именно отображено на картинке (см. рисунок выше)? Каждой точке соответствует пара значений — элементов конечного поля. Сами эти элементы, обозначенные натуральными числами, формируют горизонтальную и вертикальную оси. А поскольку значения отображаются парами, то вся картинка соответствует F×F. Пары элементов — это пары, удовлетворяющие уравнению кривой: y² = x³ + 2020x² + x. Обратите внимание, что слева здесь квадрат, и уже из этого вытекает необходимость симметрии на картинке.

Возьмём более наглядный пример. На картинке ниже – нарисованы точки эллиптической кривой y² = x³ + 17x² + 1 над полем из 101 элемента; горизонтальная черта – разделяет “график” на верхнюю и нижнюю части (симметричные). Для двух точек – написаны их координаты: (26, 53) и (26, 48).

Почему точки симметричны? Потому что они обратные, их сумма в группе точек эллиптической кривой равна нулю (нейтральному элементу группы). Координаты X у этих точек совпадают, а координаты Y – обратные по сложению в базовом поле: 53 + 48 == 101, а это 0 (mod 101). Как уже упоминалось выше, левая часть уравнения – квадрат. Это означает, что у нас обязательно есть два элемента поля, соответствующих подстановке элемента 26 в правую часть. Полностью аналогично привычному 2² == (-2)² == 4. Проверяем: 53² (mod 101) == 48² (mod 101) == 82, а 82 == (26³ + 17*26² + 1) (mod 101). Понятно, что в группе, по определению, у каждого элемента есть обратный, поэтому картинка “ветвится” таким образом.

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

В качестве развития технологии ESNI, которая так и не вышла из статуса черновика (draft), сейчас разрабатывается вариант с передачей полного дополнительного сообщения ClientHello, но в зашифрованном виде. Предлагаемая сейчас схема выглядит чрезмерно сложной, в основном, из-за того, что логические составляющие вложены одна в другую, при этом есть ссылки из внутреннего сообщения на элементы внешнего. Вряд ли это удастся реализовать без множества ошибок, порождающих уязвимости. Тем не менее, само направление интересное. Вообще, в теории, большинство прикладных протоколов современной Сети можно сделать полностью зашифрованными, включая этап установления соединения. Конечно, на практике такое если и возможно, то не скоро, однако можно рассмотреть гипотетическую картину, которая возникнет, если схему всё же воплотить. Сейчас, в TLS 1.3, зашифрованы не все сообщения, но, если сравнить с предыдущими версиями, то на защищённый обмен стороны переходят гораздо раньше. Например, в случае развития TLS в выбранном направлении, первое же сообщение клиента будет передаваться полностью в зашифрованном виде.

Возникает традиционная проблема: где клиенту взять ключи? Ключи для такой схемы публикуются в DNS. При этом, использование DNSSEC – позволяет защитить данные от подмены, а доставка запросов и ответов DNS через TLS – защищает от прослушивания трафика.

То есть, опять же, на примере TLS, – клиент извлекает серверные криптографические параметры для установления соединения из DNS, генерирует нужные ключи и зашифровывает первое же сообщение, которое направляет серверу. Это сообщение может вообще не содержать фиксированных заголовков в открытом виде (кроме, понятно, относящихся к TCP/IP или UDP). Третья сторона видит только факт обмена узлов псевдослучайными данными. Более того, даже на уровне DNS – тоже видны только псевдослучайные данные, поскольку обмен защищён TLS, в том числе, на пути между рекурсивным резолвером и авторитативным сервером.

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

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

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

Кроме того, гораздо сложнее станет отлаживать работу сетевого ПО и обнаруживать ошибки, поскольку типы прикладного трафика полностью потеряют “различимость”. Недоступным окажется пассивное блокирование ресурсов на уровне протокола (опять же, с использованием DPI).

И тем не менее, переход на такой уровень – вполне возможен в ближайшие годы.

По адресу audit.statdom.ru заработал полезный сервис Технического центра Интернет (ТЦИ), позволяющий автоматически проверить многие настройки веб-узла, с точки зрения их соответствия современным рекомендациям. Вводите имя (хостнейм, в формате test.ru) – робот опрашивает соответствующие узлы и выводит подробный отчёт, содержащий параметры TLS, HTTP/HTTPS (заголовки безопасности), DNS и MX, с рекомендациями: что включить и что работает не так, как ожидается. Кроме того, вычисляется рейтинг узла в баллах. Одной из особенностей этого сервиса является подробная проверка DNS, например, есть обнаружение доступности DNS-over-TLS (DoT) на авторитативных серверах.

Обратите внимание, что отправной точкой для исследования параметров является введённое имя хоста (имя сервера), при этом робот не следует HTTP-редиректам, а выводит результат для того имени, которое задано. Это означает, что если вы хотите проверить узел www.test.ru, для которого настроен редирект test.ru -> www.test.ru, то вводить нужно имя с www.

Ссылка: audit.statdom.ru.

(Я имею непосредственное отношение к разработке данного сервиса.)

Авторитативные серверы DNS – это серверы, которым делегирована поддержка заданной доменной зоны. Другими словами, это основные серверы, служащие первоисточником информации об адресации внутри доменной зоны. Именно к авторитативным серверам должен обращаться рекурсивный резолвер при поиске значений DNS-записей.

DNS-over-TLS – технология, защищающая трафик DNS-запросов при помощи TLS. Обычно, DNS-запросы и DNS-ответы передаются по протоколу UDP (реже – TCP) в открытом и незащищённом виде. Существует технология DNSSEC, которая позволяет снабдить содержание DNS-ответов электронной подписью, затруднив, таким образом, подмену информации. Но DNSSEC не скрывает сам трафик: то есть, третья сторона всё равно будет видеть состав запросов и ответов. Кроме того, DNSSEC аутентифицирует только передаваемые данные, привязывая их к некоторому открытому ключу, но не позволяет аутентифицировать сервер, который данные передал. В принципе, в модели угроз DNSSEC аутентификация сервера и не требуется: основная идея этой технологии состоит в том, что не имеет значения, каким маршрутом и от какого узла DNS-данные попали к клиенту – если данным соответствует валидная подпись от доверенного ключа, то они, так или иначе, достоверны. То есть, с точки зрения достоверности, канал получения DNS-информации для DNSSEC не важен. Если данные, защищённые DNSSEC, будут как-то изменены на транзитном узле, то клиент сможет обнаружить подмену. С DNS-over-TLS (или DoT) – другая история. Эта технология оборачивает обычный трафик DNS в TLS, создавая защищённый канал связи. DoT позволяет узлам, которые намерены обменяться DNS-запросом и DNS-ответом, аутентифицировать друг друга до отправки запроса. В подавляющем большинстве случаев, конечно, будет использоваться только аутентификация сервера клиентом.

В DNS, как в сервисе, большое значение имеет взаимодействие рекурсивного резолвера с так называемым stub-резолвером. Последний представляет собой самый простой вариант резолвера, который не выполняет поиска в DNS, а лишь перенаправляет запросы рекурсивному резолверу. Stub-резолвер – это типовой резолвер в подавляющем большинстве конфигураций операционных систем. Сервис же рекурсивного резолвера предоставляется либо провайдером доступа, либо отдельным провайдером DNS, как, например, в случае общедоступных резолверов Cloudflare (1.1.1.1) и Google (8.8.8.8).

Так вот, сейчас часто приходится слышать, что технология DNS-over-TLS предназначена лишь для защиты DNS-трафика на пути от stub-резолвера до рекурсивного резолвера, а на авторитативных серверах – не нужна. Это не так. Авторитативным серверам тоже рекомендована поддержка DNS-over-TLS, так как такая поддержка позволит защитить обмен информацией с рекурсивными резолверами. Дело в том, что прослушивание DNS-запросов или подмена данных – возможны и для трафика рекурсивного резолвера, адресованного не клиенту, а авторитативному серверу. Другое дело, что реализовать избирательность такой атаки становится сложнее, поскольку точно не известно, какие запросы какому клиенту соответствуют. Но, например, если используется популярный сервис DNS, то IP-адреса его узлов-резолверов известны, поэтому подмена может осуществляться избирательно. Впрочем, атакующему придётся каким-то образом встать своим транзитным узлом между авторитативным сервером и сервером DNS-резолвера. Это сложно, но возможно. Причём, разными способами. А не раз продемонстрированные на практике BGP-атаки позволяют перехватить трафик между сетями, которые, в смысле маршрутизации, находятся “далеко” от точки перехвата.

Поддержка DoT на авторитативных серверах пока что является большой редкостью и встречается существенно реже, чем даже поддержка DNSSEC. Тем не менее, один масштабный пример внедрения DoT здесь уже есть: технология поддерживается авторитативными серверами Facebook, на которые делегирована зона facebook.com.

Несколько лет назад я написал довольно подробную заметку об эволюции телефонного аппарата как персонального жучка (рекомендую перечитать). Сейчас, пожалуй, к той заметке можно добавить существенную новинку.

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

Эволюция телефонного аппарата продолжается.

Сейчас принято многие идентификаторы строго связывать с конкретной персоной, то есть, с человеком. Например, телефонный номер (мобильного телефона). Или адрес e-mail. Эту контактную информацию просят указывать едва ли не повсеместно для получения доступа ко многим необходимым сейчас сервисам. И это не просто “контакт” – на практике нередко выходит так, что доступ невозможно получить, если у вас, например, нет мобильного телефона. А далее считается, что человек непосредственно идентифицируется по этим “контактам”. Естественно, в таком подходе есть существенная доля практического смысла. Но есть и занятные хитрости, которые принято не замечать. Не замечать – хотя бы до тех пор, пока в списке контактов мессенджера, идентифицирующего пользователей по телефонным номерам, вместо знакомого человека вдруг появляется совсем другой.

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

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

Всё это относится не только к телефонным номерам. Ситуация хорошо иллюстрируется популярным “феноменом” встраивания дополнительной рекламы оператором прямо в TCP-трафик, соответствующий тому или иному веб-сайту, который пытался просмотреть абонент. И здесь ещё не учитывается тот факт, что номер вообще можно присвоить только радиомодулю в смартфоне (или, если хотите, SIM), но никак не непосредственно человеку.

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

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

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

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

Всё бы хорошо. Проблема лишь в том, что люди обычно не умеют обращаться с криптографическими ключами, да и сама непонятность процесса для неспециалиста то и дело приводит к нежелательным эффектам. Но другого варианта, похоже, нет.

По состоянию на декабрь 2019 года для веб-узлов Рунета более 80% TLS-сертификатов (HTTPS) выпущены всего двумя удостоверяющими центрами (УЦ): Let’s Encrypt и Cloudflare Inc. Соответствующую статистику TLS можно посмотреть на сайте проекта Statdom.ru (да, там тоже сертификат Let’s Encrypt).

Лидерство этих УЦ – довольно интересный показатель. Доля Let’s Encrypt, предоставляющего бесплатные сертификаты, уже более двух лет находится в интервале 61 — 68%, а вот Cloudflare – набрали почти 15% примерно за год. Конечно, в случае Cloudflare, это просто переход от одного названия к другому – ранее они использовали сертификаты УЦ Comodo, а потом перешли на собственное имя, – но это никак не отменяет достижений.

Такое “сосредоточение” процедур по выпуску сертификатов может вызвать различные опасения. Поэтому, думаю, полезно коснуться некоторых популярных вопросов по теме.

Означает ли это, что наступила некая “сверхцентрализация” и почти все HTTPS-узлы – захвачены? И да, и нет. Дело в том, что в выборе TLS-сертификатов и УЦ участвует несколько сторон, а определяющую роль играет браузер и операционная система. То есть, чтобы УЦ смог выпускать доверенные сертификаты, корневые ключи этого УЦ должны попасть в перечень доверенных браузера (либо операционной системы – зависит от конкретной среды, но в нашем случае это не важно). То есть, говорить о “сверхцентрализации” рано – теоретически, браузеры могут исключить, например, Let’s Encrypt из списка доверенных (прецеденты известны). Другое дело, что данный УЦ стал слишком большим, чтобы его просто так взяли и исключили: даже в случае существенных обстоятельств – такое исключение будет проводиться постепенно (если вообще будет проводиться).

Можно ли говорить, что эти УЦ теперь имеют доступ к данным почти всех HTTPS-сайтов, потому что там установлены их сертификаты? Нет, так говорить нельзя. Хотя и тут есть тонкости. Let’s Encrypt вообще не получает, при штатном способе выпуска сертификата, доступа к секретным ключам сервера (эти ключи просто не нужны УЦ для выпуска сертификата), соответственно, как-то расшифровать и перехватить данные этот УЦ не может. А вот у Cloudflare доступ к данным веб-узла с их сертификатом, конечно, есть, но совсем по другим причинам, не связанным с работой УЦ: основная услуга Cloudflare – проксирование соединений, предоставление веб-фронтенда; соответственно, они и так имеют доступ к трафику своих клиентов, вне зависимости от того, какой сертификат установлен на узле. (Интересно, что Cloudflare первыми массово внедрили технологию, позволяющую клиенту не передавать провайдеру копию секретного ключа для осуществления проксирования HTTPS-запросов. Addon /07.02.2020/: точнее, они первыми внедрили такую технологию на своём массовом сервисе, но не факт, что она получила большое распространение – это нужно смотреть отдельно.)

Более того, угроза прозрачного перехвата трафика, при помощи подмены TLS-сертификата, связана с любым УЦ, входящим в список доверенных, и никак не зависит от популярности УЦ. (Это общий дефект современной реализации PKI в вебе, с которым давно пытаются бороться отдельными методами.)

Да, в случае каких-то глобальных проблем – сайты смогут перейти на сертификаты других УЦ. Вряд ли переход будет быстрым и простым, но он возможен. А сайты, использующие Cloudflare, так или иначе полностью зависят от работоспособности данного провайдера, поэтому для них использование сертификатов “карманного” УЦ вообще не создаёт существенных дополнительных рисков. Но всё же: 80% узлов – это четыре пятых всех сайтов с HTTPS. С другой стороны, распространённых браузеров тоже всего два.