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



Комментарии (9) »

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



Комментарии (3) »

Новая версия протокола 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.



Комментарии (1) »

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



Комментарии (2) »

В инфраструктуре 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 этот факт документирует довольно неплохо.

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

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

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



Комментарии (1) »
Навигация по запискам: Раньше »