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

В инфраструктуре DNSSEC существует самый верхний ключ – KSK корневой зоны. К этому ключу ведут все (штатные) цепочки валидации DNSSEC, соответствующие общепринятой структуре DNS с единым корнем. Главный корневой ключ не менялся с момента запуска DNSSEC в 2010 году: спроектировать и согласовать механизм замены ключа каким-то образом забыли. Сейчас такой механизм появился, и начался процесс подготовки ротации KSK корня DNS: 11 июля в корневой зоне опубликован новый ключ (KSK) – KSK-2017. Так как новый KSK подписан действующим, можно произвести его замену автоматически, используя только DNS. Алгоритм описан в RFC 5011. То есть, если валидирующий резолвер поддерживает RFC 5011, то можно ожидать, что он автоматически заменит старый ключ на новый. Тем не менее, лучше заранее проверить, что резолвер смог получить новый ключ и включил его в список доверенных. Фактическая замена ключей (rollover) намечена на осень этого года (11 октября 2017) – до этого момента нужно убедиться, что ваш резолвер сможет использовать новый ключ, иначе валидация, спустя какое-то время после ротации, полностью сломается.

KSK-2017 можно добавить в резолвер и в ручном режиме, например, скопировав значение ключа из корневой зоны и проверив подписи. Информация о корневых ключах также доступна на сайте IANA.

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

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

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

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

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

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

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

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

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

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

Google намеревается в браузере Chrome резко ограничить доверие SSL-сертификатам, выпущенным удостоверяющим центром Symantec. Это касается и других брендов Symantec: GeoTrust и Thawte, главным образом, а также прочих “партнёрских” линеек. Речь идёт о принудительном снижении допустимого срока валидности (не более девяти месяцев – коммерческие сертификаты обычно выпускаются на год и более, это одна из их важных особенностей) и отключении EV-статуса (“расширенная проверка”, самые дорогие сертификаты). Это реакция на выявленные нарушения политик и требований к работе УЦ.

С удостоверяющим центром (УЦ) WoSign приключилась неприятность – из-за нескольких достаточно серьёзных нарушений требований (и, в частности, из-за кривого аудита), сертификатам, выпущенным от корней данного УЦ, перестали доверять браузеры (в одном пакете с WoSign оказался и другой УЦ – StartSSL: последний, как неожиданно выяснилось, был ранее куплен и, фактически, объединён с WoSign). Напомню, что и WoSign, и StartSSL выпускали бесплатные TLS-сертификаты.

Я использовал несколько сертификатов WoSign. В частности, на dxdt.ru серверный сертификат от WoSign служил в качестве входа во вторую ветку валидации для RSA (основной веткой я считаю ветку с ECDSA). То есть, сервер поддерживал обе криптосистемы для аутентификации: и ECDSA, и RSA. Сейчас я удалил RSA-сертификат WoSign и, соответственно, отключил поддержку RSA. Осталась только ECDSA – схема подписи, работающая на эллиптической кривой. Это означает, что устаревшие конфигурации браузеров/операционных систем больше не имеют доступа к сайту. Полагаю, что Windows XP с браузером IE 8 – так или иначе плохой набор для работы с Вебом. Для всех современных браузеров (и ОС) проблем быть не должно (если проблемы есть, то пишите в комментарии, если, конечно, вы как-то читаете этот текст). Стандартный набор для подключения: ECDSA + AES в режиме GCM. На всякий случай, я оставил в заголовках HPKP отпечатки ключей RSA (вдруг, они потребуются в будущем). Кстати, так как внедрение HPKP прошло успешно, попутно увеличил время кэширования отпечатков ключей до 30 суток.

Сертификат WoSign также использовался на сервере tls.dxdt.ru – пришлось заменить его на сертификат от Comodo: я провёл замену некоторое время назад, когда из обсуждения в сообществе Mozilla стало ясно, что WoSign удалят из списка доверенных корней. Ведь не очень правильно держать сайт с техническим описанием TLS под сертификатом, выпущенным проблемным УЦ.

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

Другой эффект проблем с WoSign: из бесплатных решений теперь только Let’s Encrypt, с их короткоживущими сертификатами и внешними скриптами на сервере. Да, скрипты можно написать собственные, реализовав протокол ACME, но это всё равно не тот вариант, который хотелось бы видеть.

Появилась новая работа, посвящённая быстрому вычислению секрета протокола Диффи-Хеллмана (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 некоторую существенную дополнительную информацию удавалось извлекать из статистики заголовков передаваемых записей, а также из длин передаваемых пакетов.

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

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 я подробно писал в другой заметке.)

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

BGP – или Border Gateway Protocol – это строго описанный формальный интерфейс, который автономные системы используют для формирования представления о маршрутах в Интернете. Фундамент BGP – обмен информацией о возможностях доставки пакетов. То есть, это внешний протокол взаимодействия между AS. Элементарную основу такого взаимодействия составляет распространение информации о желании автономных систем, являющихся соседними, доставлять пакеты в адрес того или иного IP-префикса. Под “соседними” подразумевается, что пограничные маршрутизаторы этих AS взаимодействуют непосредственно (заметьте, это не означает, что маршрутизаторы физически соединены напрямую). На логическом стыке между маршрутизаторами появляется понятие анонса: одна автономная система анонсирует префикс, а вторая – принимает или не принимает данный анонс. Отсюда же вырастают все другие конструкции, определяющие пути пакетов в глобальной Сети. Самой известной такой конструкцией является таблица Full View – глобальная сводная таблица путей (маршрутов), построенная для той или иной точки Сети.

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

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

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