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

SNI – это Server Name Indication, поле, которое передаёт клиент на начальном этапе установления TLS-соединения. В данном поле указано имя сервера (на уровне приложений), с которым клиент планирует установить соединение. Например, при обращении к dxdt.ru по HTTPS, ваш браузер указывает в SNI строку dxdt.ru. Указание SNI нужно для того, чтобы на стороне сервера по имени различать “виртуальные хосты” (узлы), которые разделяют общий IP-адрес. Например, если у сервера есть несколько наборов TLS-сертификатов и серверных ключей для разных имён, то на основании SNI он может определить, какие сертификаты передавать в данном TLS-соединении. Сейчас, во всех версиях TLS, включая новейшую 1.3, поле SNI передаётся в открытом виде. Это означает, что прослушивающая канал связи третья сторона может определить имя узла, с которым устанавливается соединение, несмотря на то что TLS использует шифрование для защиты от прослушивания.

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

Тем не менее, решения предлагаются. Скорее всего, значение SNI всё же спрячут. Свежий черновик (draft) RFC предлагает использовать для шифрования SNI записи DNS. Точнее, в DNS предполагается публикация открытого серверного ключа, с помощью которого клиент может зашифровать значение SNI. Такая схема позволяет клиенту сгенерировать нужный ключ заранее, сделав запрос в DNS (сопутствующие параметры публикуются там же, в одной TXT-записи), а сервер сможет расшифровать SNI непосредственно на первой итерации установления соединения (сервер знает секретный ключ). Решение весьма логичное, не требует обмена дополнительными сообщениями, кроме запроса-ответа DNS, который может быть выполнен асинхронно. Предполагается, что публикуемый в DNS ключ относится не к одному конкретному ресурсу, а к сервису, обеспечивающему размещение множества ресурсов.

Фактически, представленная в черновике схема стандартизует Domain Fronting: массовые провайдеры хостинга смогут опубликовать свои ключи для шифрования SNI в DNS, клиенты станут использовать эти ключи для доступа ко всем ресурсам, размещённым у провайдера. Удостоверение подлинности ключей – может быть выполнено в рамках DNSSEC. Ну и следует отметить, что ключи для шифрования SNI могут быть переданы не только через DNS.

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

А вот DNS авторам удаётся подменить полностью, несмотря на то, что LTE считается существенно более защищённой технологией, по сравнению с предыдущими поколениями 2G/3G. Суть атаки состоит в подмене части данных внутри UDP-пакетов, представляющих запрос и ответ DNS. Для этого требуется провести активную атаку типа “человек посередине” (MiTM), то есть, абонентское устройство должно подключиться к подменному узлу, который транслирует пакеты между ним и “подлинной” LTE-сетью. Казалось бы, LTE – современный протокол. Тем не менее, для основной части пользовательских данных в нём не используется аутентификация сообщений, хотя данные и передаются в зашифрованном виде. Данные зашифровываются AES в режиме счётчика (CTR), но, так как целостность не проверяется, пакеты могут быть прозрачно изменены.

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

В режиме шифрования CTR, блочный шифр используется для зашифрования некоторого значения, изменяющегося для каждого следующего блока – это даёт ключевую последовательность (или гамму). Далее вычисляется XOR от блоков открытого текста и соответствующих блоков ключевой последовательности: это прямое побайтовое суммирование. Так как атакующий перехватывает все сообщения, ему известно значение блока шифротекста. Также, из структуры пакетов, известны смещения байтов, содержащих запись IP-адреса и значения этих байтов. Соответственно, атакующий может легко вычислить такую маску, которая при последующем суммировании с ключевым потоком на стороне настоящей сети LTE даст в результате нужные значения байтов записи адреса. Эту маску атакующий записывает в нужный фрагмент зашифрованного пакета. Это типовая атака, очень давно известная для режимов CTR (это, конечно, только подчёркивает странность того факта, что в LTE здесь нет контроля целостности). Единственную небольшую проблему создают контрольные суммы, которые есть и в IP-пакете, и в части, относящейся к UDP. Авторы работы справляются с этой проблемой при помощи модификации значений дополнительных полей пакетов, которые также известны заранее (в частности, поле TTL IP).

Модифицированный пакет с DNS-запросом будет успешно обработан подставным сервером, после чего абонентский смартфон получит подставной ответ, тем самым можно переадресовать HTTP-запросы и запросы других протоколов, при условии, что реализация использует DNS. Это, в частности, актуально для распространённых мессенджеров.

Сейчас сайт снова должен быть доступен из сетей российских провайдеров в штатном режиме. Так как некоторое время назад многочисленные сети (миллионы 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 должен быть опять доступен.

Очередная новость “про блокировки” сообщает, что, якобы, 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.

Cloudflare официально запустили сервис DNS-резолвинга 1.1.1.1 (это IP-адрес, второй: 1.0.0.1). Резолвер работал под этим адресом уже некоторое время, но Cloudflare широко заявили о нём только первого апреля (такая вот шутка). Особенности сервиса: заявлена поддержка и DNS-over-TLS, и даже DNS-over-HTTPS (есть и такой новый протокол). По адресу 1.1.1.1 – доступен веб-сайт. При этом 1.1.1.1 в глобальной Сети нередко фильтруется или используется нерадивыми сетевыми администраторами в качестве “локального” IP-адреса, для внутренних тестов (не все готовы поверить, что это “обычный адрес”). Соответственно, сервис Cloudflare может быть недоступен из некоторых сетей. А вот адрес 1.0.0.1 – может трактоваться как синоним 1.1 (да, в короткой записи, две единицы), что позволяет прямо так и обращаться к узлу: $ ping 1.1

(В контексте DNS-over-TLS, напомню, что пару лет назад “Яндекс” занялся встраиванием в свой браузер другой технологии обеспечения безопасности DNS – DNSCrypt, но, похоже, DNSCrypt оказался неверным выбором.)

Новая версия протокола TLS 1.3 в ближайшее время получит статус рекомендации (статус уже одобрен). Я написал статью с обзором этого нового протокола. Он действительно новый, потому что от TLS 1.2 отличается радикально. Статья – TLS 1.3: на пути к внедрению.

ICANN отложила ротацию корневого ключа DNSSEC на неопределённое время. Первоначально, фактическую ротацию планировали провести 11 октября этого года. В качестве причины указаны данные о недостаточном распространении нового KSK (корневого ключа) по резолверам. Напомню, что корневой ключ (RSA, разрядностью в 2048 бит) в DNSSEC не менялся с момента внедрения технологии в глобальной DNS, то есть, с 2010 года. О механизме ротации при запуске просто забыли. За это время такой алгоритм ротации был предложен и утверждён согласно процессу IETF (RFC 5011), но теперь ICANN при помощи другого технологического механизма (RFC 8145) и косвенных данных обнаружила, что алгоритм ротации не работает.

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

Очередное обновление технического описания TLS, которое я поддерживаю и дополняю. Добавлено: подробное описание ряда ключевых атак на TLS (многие из них нашумели – POODLE, Logjam, весьма изящная DROWN и др.), подробное описание шифра ChaCha20 (вероятно, будет альтернативным для AES шифром в TLS 1.3). Текст довольно специальный (я, впрочем, уверен, что некоторые разделы будут понятны и полезны не только специалистам, но и тем, кто просто интересуется темой). Описание – здесь: https://tls.dxdt.ru/tls.html

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

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

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

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