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

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

Сейчас такие же идеи предлагаются для защиты TLS-соединений с веб-сервисами, да и не только TLS, и, вообще говоря, не только для веба. Например, в SVCB/HTTPS.

“Инфраструктурная” логика тут довольно простая и сводится к построению некоторого “тумана войны” (fog of war) на уровне базового транспорта глобальной Сети. После внедрения таких технологий, для пассивного анализатора трафика, даже обладающего обширными наборами инспектирующих узлов, вся метаинформация о сессиях на уровне приложений сведётся к двум элементарным транспортным слоям: в первом слое будут IP-адреса обменивающихся пакетами узлов; а во втором слое – минимальные “транскрипты”, соответствующие начальному обмену ключами. Более того, воссоздать второй слой будет весьма трудно, так как его отдельные элементы окажутся размазаны по разным протоколам разных уровней (UDP, IP, TCP, DNS, TLS и др.). Хитрость в том, что и клиент, и сервер могут использовать при поиске подходящих узлов метод “угадывания с предварительной информацией”, а именно – осуществлять попытки соединения, перебирая адреса и ключи по известному алгоритму, извлекая их из известного списка. Это требует дополнительных вычислительных затрат, однако для пары узлов, действующих кооперативно, эти затраты будут несравнимо меньше того объёмы вычислений, которые нужны прослушивающей стороне для раскрытия небольшой части метаинформации о соединении. (Да, некоторые из перечисленных принципов используются продвинутыми ботнетами, но тут уж ничего не поделать.)

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

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

Цитата из моей статьи, опубликованной в “Открытых системах” в 2019 году, про развитие методов контроля над интернет-трафиком:

Среди перспектив развития систем контроля трафика (именно контроля) можно отметить пропуск только авторизованного трафика. Конечно, такой вариант пока кажется фантастикой. Авторизация трафика — это развитие схемы с белыми списками. В этом случае доступ по спискам IP-адресов и имен не ограничивается, но промежуточные узлы пропускают только трафик, который содержит специальные криптографические маркеры, подтверждающие его легитимность. Коммуникация остается двусторонней, поэтому маркеры выставляются источником и получателем — приложениями, работающими на оконечных узлах, а также всеми промежуточными узлами. Для генерации валидных маркеров требуется секретный ключ, который находится внутри приложения, а для получения ключа приложение должно пройти сертификацию.

https://www.osp.ru/os/2019/01/13054741

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

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

Итак, список свойств. Некоторые из них совсем очевидны, некоторые – очевидны в меньшей степени, есть и неочевидные.

1. Ни в каком виде не должно быть авторизации по телефонному номеру. Тем более – привязки аккаунта к телефонному номеру. Телефонный номер – это ресурс оператора связи. Следует считать, что оператор связи решает собственные задачи и вовсе не собирается участвовать в обеспечении безопасности очередного “безопасного” мессенджера.

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

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

4. Протоколом обмена сообщениями должен быть предусмотрен механизм внешней доверенной проверки подлинности ключей и идентификаторов. Это, грубо говоря, некоторый способ, позволяющий без использования самого мессенджера проверить, что предъявленный конкретному пользователю ключ другого пользователя – действительно принадлежит этому другому пользователю, а не промежуточному серверу (например).

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

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

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

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

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

На сайте ТЦИ опубликована моя статья о технологиях DNS-over-HTTPS и DNS-over-TLS, о том, как эти технологии повлияют на развитие Интернета, на методы блокирования доступа и фильтрации трафика – “DNS-доступ под защитой: DoT и DoH“. Цитата:

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

Интересно, что современный “распределённый” глобальный веб-сервис Facebook.com достаточно регулярно падает полностью. Как, например, сегодня (8-9 апреля). Падает он настолько полностью, что даже вместе с Instagram. Казалось бы, можно попытаться устроить системы таким образом, чтобы отключались какие-то элементы, но не всё сразу и глобально. Однако на практике, очевидно, такая архитектура потребует неприемлемых затрат, как денежных, так и административных, не только на проектирование, но и на поддержку. А поскольку потерей пользователей подобные отказы не грозят, то и беспокоиться не о чем.

В блоге Cloudflare подробная статья, рассказывающая популярно про технологию сокрытия имени сервера в TLS: Encrypted Client Hello (ECH).

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

(Как работает ESNI – можно посмотреть на моём тестовом сервере https://tls13.1d.pw/, а вот поддержку ECH я ещё не собрался дописать.)

На сайте ТЦИ опубликована моя статья с результатами измерения распространённости поддержки TLS 1.3 на HTTPS-узлах Рунета. Под Рунетом подразумеваются имена второго уровня в зонах .RU, .SU, .РФ. Измерялось наличие поддержки TLS 1.3 для TCP-соединений на номере порта 443 (это номер HTTPS). TLS 1.3 уже довольно широко поддерживается, несмотря на относительную новизну протокола. Описание методики и результаты – в статье.

Важный момент про DNS-over-TLS (DoT) и DNS-over-HTTPS (DoH): в случае, когда валидацию DNSSEC проводит внешний рекурсивный резолвер, использование DoT/DoH на “последней миле” позволяет эффективно продолжить цепочку доверия DNSSEC до клиента; правда, через дополнительный шаг – аутентификацию сервера в рамках TLS. То есть, если некоторый клиентский stub-резолвер использует гугловый сервис 8.8.8.8 и доверяет его валидации DNSSEC, но сам валидацию не проводит, то, в классическом случае, никто не мешает на транзитном узле вмешиваться в трафик и присылать фиктивные ответы от имени 8.8.8.8, в которых будет что угодно. Использование же DoT/DoH позволяет клиенту аутентифицировать узел (DNS-сервер) и проверять подлинность ответов, что распространяет доверие к валидации DNSSEC на случай, когда клиент не верит транзитным узлам (а им верить давно нельзя).

(Первоначально опубликовано на Facebook.com, 22/11/2019.)

Выпустил очередное (ежегодное) обновление технического описания TLS: tls.dxdt.ru. Это подробное изложение всех особенностей протокола, который является важнейшим инструментом защиты информации в Интернете. Ключевые моменты разобраны до отдельных байтов.

В новой версии:
1) добавлено описание режима использования шифров CCM;
2) актуализировано описание механизма защиты поля имени сервера (SNI);
3) добавлен небольшой фрагмент про постквантовую криптографию в TLS (это существенное направление, которое заметно изменит практику применения протокола).

Описание доступно здесь: tls.dxdt.ru/tls.html