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

У постановки помех GPS – история давняя. Это интересная тема. Вообще, что касается именно вопроса точной навигации, то блокирование сигнала GPS имеет свои ограничения: дело в том, что есть инерциальные системы навигации, они автономные, а GPS для них полезна лишь в том смысле, что позволяет скорректировать накопленную ошибку. Но если навигационный сигнал недоступен только на небольшой территории, то ограничения для инерциальных систем становятся не так актуальны: ошибка просто не успеет накопиться.

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

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

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

А вот “пропадание навигации” в смартфоне – всего лишь побочный эффект.

(Развитие темы: подделка сигнала GPS, GPS-спуфинг.)

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

О том, что найти секреты DH в произвольной короткой, 1024-битной группе, можно, если у вас есть достаточно мощный, но доступный на уровне современных технологий, компьютер и вы предвычислили нужную “арифметическую структуру” группы, известно довольно давно. Сейчас решение продемонстрировали на практике, подтвердив, что если правильно выбрать модуль, то объём вычислений ещё сокращается на несколько порядков.

Для того, чтобы атака сработала, требуются типовые группы. В более строгом случае, с подготовленным модулем, используемую группу нужно прямо задать. (Более мягкий вариант – работает с любой заранее известной 1024-битной группой, но для каждой потребуется большой объём предварительных вычислений и большой объём памяти для хранения результатов.)

Самое занимательное, что с типовыми группами проблем как раз нет. Например, в Рунете (.RU, .РФ) около 280 тыс. имён аресует узлы, поддерживающие HTTPS/TLS и классический вариант DH, которые используют всего две различных группы с разрядностью 1024 бита. Одна – это группа по умолчанию из mod_ssl, а вторая, насколько я понимаю, из настроек по умолчанию модуля SSL в nginx. Обе группы, очевидно, потенциально уязвимы. (Пояснение, 12/10/16: я скорректировал текст – изначально было написано, что 280 тыс. серверов, но речь идёт о числе доменов – имён TLS-хостов.)

Про то, что генерация общего секрета по протоколу Диффи-Хеллмана вовсе не является эквивалентом симметричных ключей, которые “есть только на узлах”, я не раз писал ранее. Например – в записке про извлечение секрета DH из трафика.

В IETF уже более двух лет разрабатывается новая версия протокола TLS – TLS 1.3. Сейчас соответствующий RFC находится в состоянии черновика, но уже очень близок к финальному документу. Я планирую написать про 1.3 подробнее, а сейчас отмечу несколько ключевых направлений.

TLS 1.3 очень существенно отличается от 1.2 (даже обсуждалось предложение существенно изменить номер версии: например, TLS 2.0). Версия 1.3 полностью несовместима с 1.2 и, соответственно, с предыдущими версиями. Одним из самых радикальных изменений является новый алгоритм установления соединения (Handshake). Появились криптографические ключи нескольких уровней, используемые на разных этапах установления соединения. При этом в ряде режимов установление соединения будет происходить заметно быстрее (а это основной “замедлитель” в TLS). В частности, появляется вариант возобновления соединения 0-RTT (round-trip time) – здесь клиент сразу переходит к отправке данных полезной нагрузки, следом за отправкой начального сообщения (но, естественно, требуется, чтобы клиент и сервер устанавливали соединение ранее).

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

В общем, новая версия пестрит радикальными нововведениями, при этом, как ожидается, протокол станет безопаснее. Можно ли будет то же самое сказать и про реализации – покажет практика.

Update (30/03/2018): TLS 1.3, описание.

Больше и больше пишут про “квантовые каналы” связи, которые “абсолютно” защищены “квантовой криптографией”, и только они смогут спасти от “квантового компьютера”. Здесь интересны несколько моментов.

1.

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

2.

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

3.

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

4.

Квантовые компьютеры. Симметричные системы (шифры), вроде AES, сохраняют стойкость: сейчас считается, что появление квантовых компьютеров достаточной мощности приведёт лишь максимум к “квадратичной” оптимизации перебора. Это очень оптимистичная, в отношении квантового компьютера, оценка, потому что речь идёт о квантовых операциях, реализующих алгоритм поиска – а это совсем другое дело, по сравнению с классическим CPU. То есть, для сохранения стойкости, разрядность ключа симметричного шифра нужно будет увеличить в два раза. Соответственно, AES с 256-битным ключом обеспечит достаточную степень защиты (эквивалентную 128 битам). Если стороны успели в защищённом режиме обменяться гигабайтом ключевого потока, то его, даже при расточительном использовании в качестве ключей AES, хватит надолго. (256 бит – это 32 байта, которые можно смело использовать для шифрования AES примерно 2^32 блоков, каждый блок – это 16 байтов, то есть, одного ключа хватит для 16 * 2^32 ≈ 64 гигабайт передаваемых данных; и это только один ключ, 64 байта из гигабайта).

5.

Квантовые компьютеры достаточной разрядности – полностью побеждают распространённые сейчас асимметричные криптосистемы. Если только такие компьютеры возможны. Как ни странно, первыми падут суперсовременные криптосистемы на эллиптических кривых: это связано с тем, что они имеют малую разрядность, а способность квантового компьютера взламывать такие системы находится в прямой зависимости от числа доступных кубитов. То есть, компьютера, взламывающего ECDSA с ключами в 256 бит, ещё недостаточно для того, чтобы атаковать RSA с разрядностью в 2048 бит. Так что тут у RSA есть преимущество. Другое дело, что как только сумеют построить квантовый компьютер с разрядностью в 256 кубитов, масштабирование на 2048 – вряд ли потребует долгих лет.

6.

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

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

7.

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

^* Примечание от 04/11/2021: здесь речь идёт про TLS в вебе, в HTTPS, но TLS применяется не только в вебе, а исключение составляют варианты использования TLS с заранее распределённым секретным ключом (схемы PSK), которые, впрочем, встречаются довольно редко.

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

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

1.

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

2.

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

3.

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

4.

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

5.

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

6.

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

7.

Инфраструктура сертификатов и УЦ в современном Интернете развивается. Как раз в сторону повышения прозрачности. Соответственно, внедрение MitM будет быстро обнаружено. Для того, чтобы подтвердить факт MitM, тот или иной пользователь может просто опубликовать (отправить, скажем, в Google или в, условный, Facebook) подменный сертификат. Этот сертификат пользователю легко извлечь – в браузере, например, для этого есть функция экспорта. Подделать такой сертификат не выйдет (ну, если бы некий пользователь решил дезинформировать Google), потому что он обязательно содержит электронную подпись, которую можно проверить.

(Про перехват HTTPS я подробно писал в другой заметке.)

Весной этого года ФБР спорило с корпорацией Apple по поводу “взлома” защиты аппаратов iPhone, для того, чтобы получить доступ к одному из таких аппаратов (АНБ из каких-то своих соображений заявило, что помочь не может). Обсуждались самые разные способы получения доступа, в том числе, при помощи физического копирования модуля памяти устройства (NAND mirroring). Почему-то насчёт этого варианта высказывались сомнения относительно реализуемости. Сергей Скоробогатов (Sergei Skorobogatov) продемонстрировал на практике, что задача решаема даже без использования сверхсложного лабораторного оборудования: The bumpy road towards iPhone 5c NAND mirroring – в работе подробно рассмотрены все этапы, начиная от извлечения чипа и до реализации перебора пароля доступа с использованием клонированной памяти (Apple, оказывается, использует некоторые методы аппаратной защиты от такого клонирования, но их можно обойти). Весьма интересно, рекомендую.

Я существенно расширил техническое описание TLS в новой версии. Добавил: раздел про симметричные шифры (с описанием AES), описания криптосистем RSA и ECDSA, существенно расширил описание протокола Диффи-Хеллмана; кроме того – дополнил и актуализировал весь текст целиком. Объём вырос почти в два раза – и, да, там много информации, но зато хорошо охвачены технические моменты. На мой взгляд, теперь это одно из самых полных и детальных описаний TLS на русском. Естественно, есть что дописать в следующей версии: расширенное описание атак, подробности про шифры, приложение с глоссарием по математическому аппарату (тут мне оказалось довольно сложно заморозить версию: исходники всё время обрастают новыми деталями, которые я потом отношу к “слишком техничным”), приложение с примерами конфигураций серверов (надеюсь, что в самом обозримом будущем) и другие дополнения. Это кроме того, что скоро должна выйти из состояния draft новая версия спецификации – TLS 1.3 (или 2.0, или как её обозначат), в которой куча радикальных изменений, а поэтому придётся добавить отдельную главу (сейчас я уже внёс некоторые оговорки по тексту, акцентирующие внимание на запланированных отличиях в новой версии).

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

Надеюсь, что это полезный текст. Вот ссылка: “Как работает ТLS, в технических подробностях“.

(Добавлять ли раздел, посвящённый постквантовым криптосистемам?)

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

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

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

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

DNS Privacy – актуальная тема. Речь здесь о том, как снизить утечки информации об использовании интернет-сервисов, происходящие через DNS. Как именно и какая информация утекает? В типичной пользовательской конфигурации, DNS служит базой данных, хранящей соответствие символьных имён и IP-адресов, а поиск в этой базе данных осуществляет рекурсивный резолвер интернет-провайдера (несколько реже – корпоративный рекурсивный резолвер).

Есть два основных потока утечек. Первый – это сведения об узлах, для которых запрашивались имена; во многих случаях эти данные близки к списку посещаемых веб-сайтов, но содержат и другие разнообразные сведения. Второй поток – “помеченный” трафик, характерный для конкретного браузера и конкретных веб-страниц. Ко второму случаю, например, относятся известные способы деанонимизации пользователей при помощи создания уникальных имён ресурсов, ссылки на которые встраиваются в код веб-страницы. Браузер, пытаясь извлечь ресурс по ссылке, отправит уникальный идентификатор страницы на сервер имён, поддерживающий зону DNS, которая послужила базисом в системе деанонимизации. Обычно маркером служит уникальное имя, созданное для конкретного запроса, например: kf356askg.example.com (уникальный идентификатор здесь – kf356askg). Интересно, что если вы просматриваете пользовательский DNS-трафик, то идентифицирующие маркеры можно распознавать и без использования серверов имён: они будут передаваться в открытом виде.

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

При штатной работе DNS, резолвер всегда начинает опрос серверов с полным именем искомого ресурса в составе запроса. На минуточку предположим, что в нашем простом случае исчезло кеширование. Тогда, если пользователь, например, задумал обратиться на www.example.com, то об этом имени, сопоставленном с IP-адресом используемого резолвера, узнают и корневые серверы глобальной DNS, и корневые серверы .COM, и серверы имён зоны EXAMPLE.COM. Так устроен протокол. При этом, если исходить из необходимости получения А-записи для www.example.com, знать о полном имени запроса нужно только серверам зоны EXAMPLE.COM (строго говоря, серверам WWW.EXAMPLE.COM, но эти детали мы опустим). Борьба с данной утечкой называется QNAME Minimization – есть RFC 7816, со статусом Experimental. Основная идея состоит в том, чтобы резолверы направляли запросы, минимизируя утечки информации. В случае с www.example.com – можно спрашивать корневые серверы сразу об именах серверов имён (NS) зоны .COM, и так далее.

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

Защите DNS-трафика от прослушивания и, частично, подмены, посвящена технология DNS over TLS, описанная в свежем RFC 7858. Мало кто ожидает, что в ближайшее время при помощи TLS будут защищены все DNS-транзакции, но технология позволяет это сделать. Параллельное решение – DNSCrypt, про который я рассказывал не так давно. Вариант с TLS выглядит несколько более предпочтительным, так как вписан в существующую технологическую архитектуру Сети, где TLS является основной для защиты трафика.