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

На dxdt.ru есть страница с избранными записками. Добавил туда вот эти пять:

• “Ключи на клиенте” и протокол Диффи-Хеллмана
• Скрытое управление пограничными маршрутизаторами
• Обнаружение и извлечение документов с пользовательского компьютера
• Антивирусы и “подмена” сертификатов в браузерах
• Сложности стеганографии

Многие слышали про криптографию на эллиптических кривых. Но эллиптические кривые, которые давно являются мощным инструментом теории чисел, можно успешно применить к решению элементарной (по формулировке) арифметической задачки про бананы, яблоки и ананасы. Текст ниже – несколько сокращённая версия моего перевода ответа Quora.com, который дал Alon Amit (англ.).
Читать полностью

Сейчас сайт снова должен быть доступен из сетей российских провайдеров в штатном режиме. Так как некоторое время назад многочисленные сети (миллионы IP-адресов) попали под блокировку, в том числе, и подсеть с адресами dxdt.ru, пришлось добавить IP-адресов сайту. Это делается при помощи внесения дополнительных A-записей в DNS. Я добавил ещё три адреса, сделав на соответствующих узлах TCP-туннели к основному серверу (сейчас уже вернул единственный адрес, так как блокировки пошли на спад).

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

А вот с HTTPS ситуация гораздо лучше: пока что не все провайдеры пытаются подменять TLS-узлы, поэтому соответствующие TCP-соединения просто разрываются, а браузер сразу видит, что этот адрес нерабочий и прозрачно переходит к следующему. Вмешательство же провайдера в TLS-соединение при помощи подмены узла – будет приводить к появлению предупреждения браузера. Так как dxdt.ru использует HPKP, это предупреждение во многих браузерах нельзя “подавить”, кликнув что-нибудь вроде кнопки “Всё равно продолжить”. Таким образом, HPKP тоже очень хорошо помогает в подобных случаях. Кстати, Google собирается убрать поддержку HPKP из Chrome, под совершенно надуманным предлогом. Это, в принципе, понятно: корпорация, с некоторых пор, не желает давать в руки пользователям распределённый, независимый от некоторого центра инструмент проверки подлинности сайтов. Впрочем, это другая история.

Итак, сайт dxdt.ru должен быть опять доступен.

Довольно давно я писал про ультразвуковые излучатели, которые позволяют модулировать звуковые волны в слышимом диапазоне, наводя “голос” в заданном секторе пространства. Сейчас голосовое управление присутствует во многих устройствах. Например, является штатной возможностью смартфонов. Естественно, аналогичным способом, с помощью ультразвука, наводить нужные голосовые команды можно непосредственно в микрофоне смартфона. При этом, находящиеся рядом люди ничего не слышат. Так, в работе по ссылке – DolphinAttack: Inaudible Voice Commands – рассматривается практическая реализация атаки, использующей неслышимые для владельца голосовые команды с целью управления смартфоном.

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

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

Данное направление особенно интересно выглядит в контексте набирающих всё большую популярность систем биометрической идентификации по голосу.

Очередная новость “про блокировки” сообщает, что, якобы, Amazon запретил “использовать свои сети в качестве прокси” (варианты: использовать для “обхода блокировок” и др.). Сообщения сопровождаются ссылкой на публикацию AWS (Amazon Web Services), где, впрочем, рассказывается о другом.

О чём идет речь? Действительно, существует схема маскировки имени сервиса, под названием Domain Fronting. Схема построена на архитектурной особенности HTTPS: данный протокол использует TLS в качестве транспорта, соответственно, появляются два уровня – TLS и HTTP. С каждым из этих уровней связано некоторое имя сервера (имя хоста). В TLS это имя передаётся в поле SNI (Server Name Indication), в открытом виде, то есть, в виде, доступном для просмотра системой DPI. На уровне HTTP есть ещё одно имя сервера, оно входит в состав адреса документа (URI), который запрашивает клиент. Этот адрес, а следовательно и имя, входящее в его состав, передаётся уже в зашифрованном виде, поэтому недоступен для DPI.

Пример: пусть клиент, являющийся браузером, использует веб-сервер под именем “example.com” и пытается с помощью HTTPS извлечь документ по адресу “https://example.com/document.html”. Тогда при установлении TLS-соединения, которое происходит до отправки HTTP-запроса, браузером в поле SNI (TLS) будет передано имя “example.com” (обратите внимание: без полного адреса документа, только имя узла, домен). После того, как TLS-соединение установлено, браузер отправит GET-запрос HTTP, указав, согласно спецификации протокола HTTP, адрес документа “/document.html” и имя узла (в специальном поле заголовка HTTP-запроса, под названием Host) “example.com”. Это имя совпадает с именем на уровне TLS, в поле SNI, но вообще имена могут различаться, так как находятся на разных уровнях абстракции. Приложение, работающее по HTTP, вообще обычно не видит не только имени в SNI, но и самого протокола TLS.

Domain Fronting строится на подмене имён SNI и HTTP. В SNI указывается имя одного сервера, но после того, как TLS-соединение установлено, HTTP запросы отправляются с указанием другого имени. Поясню в терминах примера из предыдущего абзаца: в TLS SNI указывается имя “example.com”, однако GET-запрос уже отправляется с указанием “test.ru” в качестве имени хоста. Теперь на уровне HTTP указано совсем другое имя, но так как TLS и HTTP используют разный контекст, сервис, где размещён исходный узел (адресуемый example.com в нашем примере), может выполнять и HTTP-запросы к test.ru. Это будет являться побочным эффектом реализации HTTPS на стороне сервиса.

Теперь предположим, что из некоторого сегмента Глобальной сети доступ к test.ru по каким-то причинам невозможен. Используя Domain Fronting можно замаскировать запросы к test.ru под HTTPS-сессию с узлом example.com: так как HTTP-запросы передаются в зашифрованном виде, анализирующая трафик сторона видит только имя example.com в поле SNI TLS. Конечно, могут заблокировать и доступ к example.com, в том числе, по IP-адресу, но тут в игру вступает административная часть: представьте, что вместо example.com используется google.com (или какой-то другой массовый сервис) – мало кто готов блокировать условный Google. Конечно, чтобы всё сработало, требуется поддержка описанной схемы со стороны сервиса, используемого как прикрытие. Именно на этом этапе и возникает сервис “Амазон” CloudFront, который позволяет (или позволял, см. ниже) использовать такую схему для ресурсов, которые размещаются за CloudFront. При этом “заехать” за чей-то домен можно без ведома того клиента CloudFront, который этот домен использует штатно, что, конечно, не самая привлекательная особенность сервиса.

Метод маскировки с использованием Domain Fronting известен много лет. Наличие такой особенности объясняется тем, что для массового сервиса удобнее жёстко разделить TLS и HTTP – одни логические узлы обрабатывают TLS-соединение (выполняют “терминирование TLS”), а другие – работают с HTTP, уже в открытом виде. Поводом для новостей про “запрет обхода блокировок” как раз послужило то, что “Амазон” недавно обновил платформу CloudFront, исправив обработку контекстов и, тем самым, удалив возможность использования Domain Fronting. Думаю, понятно, что к “обходу блокировок” это если и имеет какое-то отношение, то весьма и весьма косвенное, и только со стороны тех нестандартных клиентов, которые данную особенность использовали. К ним, например, относится мессенджер Signal, который, впрочем, уже получил предупреждение о нарушении правил использования сервиса от Amazon.

Пишут, что шифры, предложенные АНБ, очередной раз не утвердили в качестве стандартов ISO (для “Интернета вещей”). Как следует из неофициальных публикаций, мотивируют решение против шифров АНБ тем, что агентство могло внести в них бэкдоры. Такая мотивировка сейчас популярна и привлекательна для СМИ, но каких-то внятных описаний бэкдоров, конечно, не предлагается. Шифры Speck и Simon – относятся к классу “лёгких” шифров, предназначенных для устройств, сильно ограниченных в вычислительных возможностях. Обычно, это микроконтроллеры, используемые для управления разным оборудованием, в том числе, бытовым. Я довольно подробно писал про Speck в прошлом году, рассматривая его реализацию для микроконтроллера AVR (точнее, для Arduino), в той записке есть схема шифра и соответствующий исходный код.

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

Сейчас могут наблюдаться проблемы с доступом к dxdt.ru из сетей российских провайдеров. По возможности, используйте ссылки только с прямым указанием HTTPS (в принципе, только такие ссылки и должны бы быть, сайт давно использует HTTPS в качестве основного протокола, но кое-где остались и небезопасные).

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

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

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

Что касается самих ключей: опять же, строго говоря, открытая часть протокола DH доступна для записи, а в открытой части содержится достаточно информации для получения секрета. Стойкость протокола основана только на том факте, что не известно универсальных практических (то есть, работающих на доступном классическом компьютере) алгоритмов быстрого вычисления секрета на основе только открытых параметров DH. Но это не означает, что “ключи есть только на клиенте”. Если центральный сервер записывает трафик, то ключи, вообще говоря, есть и у него, но в представлении, которое сложно обратить (получить из открытого ключа секретный, эта задача называется дискретным логарифмированием). Сложно, но вовсе не невозможно. Более того, считается, что для конкретных параметров DH, обладающих определёнными свойствами, можно провести предварительные вычисления на специализированном суперкомпьютере, а потом очень быстро вычислять секретные ключи. Именно по этой причине рекомендуется при использовании DH генерировать полностью собственные параметры, а не применять заранее известные, которые, например, выдаёт центральный сервер. В случае классического DH (не эллиптического), основным параметром является простое число (модуль), задающее группу, в которой проводятся операции протокола. Это, впрочем, технические детали – я писал о них раньше, применительно к TLS. Главное наблюдение состоит в том, что информация о секретных ключах содержится в параметрах, которыми стороны обмениваются в открытом виде.

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

Про DH и связанные с этим протоколом ограничения я неоднократно писал раньше, например – здесь и здесь.

Ракета ко Дню Космонавтики.

(А. Соколов.)