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

Технический Центр Интернет (ТЦИ) открыл российский общедоступный удостоверяющий центр (называется “Центр сертификации”) TLS: https://tlscc.ru/ (бета-версия).

Центр позволяет выпускать TLS-сертификаты как с ECDSA, так и с ГОСТ-подписью. Чтобы заказать сертификат, требуется зарегистрироваться на сайте. Для подтверждения права управления доменным именем можно использовать DNS (размещается TXT-запись с кодом) или веб-сервер (публикуется текстовый файл). Однако нужно учитывать, что действующие корневые ключи УЦ не входят в дистрибутивы браузеров (возможно, пока что не входят), поэтому для использования сертификатов их придётся добавить вручную.

В продолжение предыдущей записки, про сертификаты от Let’s Encrypt. RSA и ECDSA – это распространённые в Интернете криптосистемы, которые используют различную математическую основу. ECDSA имеет целый ряд преимуществ. Однако в случае TLS-сертификатов существенный смысл в использовании ECDSA возникает тогда, когда вся цепочка сертификатов использует эту криптосистему.

Дело в том, что валидация (то есть, процесс установления подлинности) серверного сертификата подразумевает проверку подписи на одном или нескольких других сертификатах – это сертификаты удостоверяющих центров (УЦ). Технически, можно серверный (то есть, оконечный) сертификат с ECDSA-ключом подписать при помощи RSA. Именно так и делает Let’s Encrypt. При этом корневой доверенный сертификат с ECDSA у них уже есть, но вот оконечные сертификаты с ECDSA для обычных пользователей не выпускаются. Допускаю, что я не нашёл, где такую возможность включить, но, на мой взгляд, для оконечного сертификата с ECDSA автоматом должна выбираться вся цепочка с ECDSA – использование RSA, в этом случае, выглядит весьма странно (впрочем, учитывая, что сейчас 2022 год, RSA и в других случаях выглядит странно). Тем не менее, сертификат для dxdt.ru, который я вынужден был выпустить через Let’s Encrypt, содержит RSA-подпись. Ничего не поделать. Раньше, когда были доступны и другие УЦ, я использовал PositiveSSL, для которого есть ECDSA-цепочка.

Поскольку добывать платные долгоживушие сертификаты от “хорошо известных УЦ”, корни которых есть в браузерах, стало очень неудобно, да ещё и по совсем неадекватным ценам (это связано с общим современным состоянием интернетов и, в частности, применимо к российским пользователям и доменам внутри .RU), поменял сертификат dxdt.ru на Let’s Encrypt. В этом бесплатном УЦ пока что .RU не заблокировали. Не факт, конечно, что это надолго (не заблокировано), но там и сертификаты-то по три месяца. Кстати, довольно занятно будет, когда сертификаты .RU перестанет выдавать и Let’s Encrypt – почти вся зона .RU, в смысле веб-серверов, использует сертификаты именно этого УЦ.

При переходе на Let’s Encrypt удалось даже без проблем применить особый ключ ECDSA, который я специально подобрал (запись открытого ключа содержит некоторую hexspeak-подстроку в самом начале; если вы, вдруг, интересуетесь экзотической занимательной арифметикой на эллиптических кривых и умеете смотреть серверные ключи TLS-сертификатов (это несложно сделать браузером), то обратите, как говорится, внимание). Но всю цепочку в ECDSA Let’s Encrypt делать отказался – этим пришлось пожертвовать.

(Заметка первоначально опубликована в Facebook, 19/05/2020.) Я вот так устроил, что один сервис, проверяющий TLS, использует специально сконструированное сообщение ClientHello TLS 1.3 (см. скриншот) с посланиями внутри. Небольшая хитрость состоит в том, что там не только поля SessionID и ClientRandom с сообщениями, но и ключ для Диффи-Хеллмана (ECDH) на кривой P-256 – с посланием. Ключ – это два числа, но они должны задавать точку кривой, и хорошие реализации TLS проверяют, что ключ принадлежит кривой. Конечно, вычисление второй координаты Y по известной X-координате – никакой проблемы не составляет, но пришлось урезать пару символов, так как число приводится по порядку базового поля. У тех, кто знаком с ECDH, сразу возникнет вопрос – решил ли я попутно задачу дискретного логарифмирования для P-256? Но нет (а если бы решил, то сообщил бы об этом более занятным способом). Дело в том, что реально в этом сканере общий секрет не нужен, поэтому ответный ключ сервера просто игнорируется. (Конечно, вряд ли кто-то ещё это всё видит в трафике. Но при отладке – помогает.)

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

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

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

А использование подменного УЦ – это довольно грубый метод. Который, во-первых, требует активного перехвата соединения; во-вторых – оставляет надёжные, хорошо заметные следы.

На сайте ТЦИ опубликована моя статья, рассказывающая о технологии ECH (Encrypted Client Hello) и её, возможном, месте в современном наборе защищённых транспортов данных глобальной Сети. ECH – это развитие технологии ESNI, однако от ESNI всё ушло уже достаточно далеко.

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

TLS (Transport Layer Security) предназначен для создания защищённых каналов обмена информацией. Спецификации определяют несколько версий TLS: 1.0, 1.1, 1.2, 1.3. Версия 1.3 является самой современной, допускается использование версии 1.2, а более старые версии – не рекомендованы.

1.

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

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

2.

TLS использует парадигму “клиент-сервер” и работает поверх TCP. Клиентом в TLS является сторона, инициирующая защищённое соединение. В штатном случае, клиент в TLS совпадает с клиентом в соответствующем TСP-соединении.

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

Сертификаты в TLS бывают серверные (их называют “оконечными”), промежуточные и корневые. Фундаментальное отличие серверного сертификата от промежуточного и корневого в том, что серверный сертификат не может быть использован для выпуска других доверенных сертификатов, то есть, он является конечным сертификатом в “цепочке доверия” (откуда и название “оконечный”). Сертификаты, которые подразумевают возможность подписывать другие сертификаты, называются сертификатами удостоверяющих центров (УЦ). Как ни странно, но в технической части TLS роль УЦ на этом заканчивается: УЦ – это просто флаг в сертификате (флаг называется CA).

3.

Аутентификация по TLS-сертфикатам основана на следующем простом алгоритме: сторона, “подлинность” которой проверяется, по запросу подтверждает, что ей известен секретный ключ, соответствующий открытому ключу из доверенного сертификата. Это означает, что если сертификат для аутентификации предъявляет сервер, то сервер должен знать секретный ключ от этого сертификата. Обычно, доступ к секретному ключу тем или иным образом настраивается в конфигурации сервера. В наиболее распространённом сейчас случае, – например, для HTTPS, – секретный ключ просто размещается в файле на сервере, путь к файлу ключа указывается в конфигурации.

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

4.

Доверие сертификатам – эквивалентно доверию представленным в них открытым ключам. Методы управления таким доверием находятся за рамками TLS, но, тем не менее, составляют существенную часть практики TLS.

Обычно, доверие сертификатам строится по цепочке, от корневого, через промежуточные, до серверного (оконечного) сертификата. Цепочка выстраивается через подписи: ключ из корневого сертификата позволяет проверить подпись на промежуточном, а ключ из промежуточного – на серверном. Ранжируются и “сцепляются” сертификаты по именам: в каждом сертификате есть поля Issuer (“Издатель” – тот, кто удостоверил сертификат) и Subject (“Субъект” – тот, кому сертификат выдан); поле Issuer сертификата более низкого уровня должно соответствовать полю Subject сертификата более высокого уровня. Корневой сертификат всегда самоподписанный, то есть, у него значение поля Issuer равно значению поля Subject. Таким образом, корневой сертификат – всего лишь способ публикации доверенного корневого ключа. На практике, в Интернете, серверный сертификат в поле Subject содержит некоторое сетевое имя (реже – IP-адрес) сервера. При этом, если речь идёт о вебе, – а именно, о браузере и HTTPS, – то серверный сертификат обязательно должен содержать имя (возможно, IP-адрес) сервера и в специальном дополнительном поле SAN (Subject Alternative Name), иначе современные браузеры будут считать такой сертификат невалидным (то есть, соединение с сервером будет отмечено как “недоверенное”). На начальном этапе установления TLS-соединения сервер передаёт один или несколько сертификатов клиенту. Так, в современной практике HTTPS, корректно настроенный сервер практически всегда передаёт, как минимум, один серверный и один промежуточный TLS-сертификат.

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

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

5.

TLS защищает передаваемые данные от прослушивания, это делается при помощи шифра. Формально, всё ещё возможно реализовать TLS-соединение, не зашифровывающее данные, но это скорее теоретическое упражнение.

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

Помимо того, что передаваемая информация зашифрована, TLS также обеспечивает её целостность, то есть, позволяет обнаружить изменение защищённого пакета в процессе доставки, провести аутентификацию данных. Для этого служат коды аутентификации сообщений (MAC, а в русскоязычной терминологии – имитовставка). Такой код, вычисленный по особому алгоритму, прикрепляется к сообщению. Чтобы сгенерировать корректный код для заданного сообщения нужно знать секретный ключ. Принимающая сторона, которой секретный ключ известен, может проверить, что код соответствует сообщению, следовательно, сообщение вряд ли было изменено. Современный метод применения шифров в TLS объединяет процесс зашифрования и процесс защиты целостности данных в единый алгоритм, называемый “аутентифицированным шифрованием”. Распространённый пример такого алгоритма – AES-GCM.

6.

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

7.

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

Специальные методы для (пассивного) чтения полезного содержимого TLS-трафика используют ключи защиты трафика. Для того, чтобы внешнее приложение могло просматривать TLS-трафик, в сторону этого приложения достаточно экспортировать сеансовый секрет, который служит основой для генерации ключей защиты трафика, либо сами эти ключи. Возможность такого экспорта определяется настройками TLS-сервера или TLS-клиента. Сеансовый секрет и наборы ключей у сервера и клиента общие (в одной сессии), поэтому извлечь нужное значение можно с любого из узлов. На стороне сервера, обычно, экспорт секретов/ключей настраивается в конфигурации серверного приложения, иногда включить такой экспорт можно через соответствующую переменную окружения (например – SSLKEYLOGFILE). Аналогично – на стороне клиента. Суть данного метода следующая: криптографическая библиотека, обеспечивающая работу TLS, будет выводить в файл с заданным именем некоторый идентификатор TLS-сессии и соответствующий сеансовый секрет; получив секрет, приложение для анализа трафика сможет вычислить сеансовые ключи и расшифровать трафик. Передавать секрет через файл, конечно, необязательно. Очевидно, такой метод создаёт некоторую задержку и лучше подходит для анализа записанного ранее трафика. Аналогичный метод может работать и в режиме онлайн, но это потребует гораздо более плотной интеграции программных пакетов. Экспорт сеансового секрета является сейчас самым универсальным и технологичным способом анализа TLS-трафика, но, обычно, работает для ранее записанных сессий – например, в таком режиме можно использовать Wireshark. Существует устаревший способ, основанный на передаче секретного ключа RSA. Этот способ, по описанным выше причинам, не подходит для сессий, в которых вычисление сеансового секрета происходит по протоколу Диффи-Хеллмана, а это большинство сессий с современными настройками. Специально выбирать ключевой обмен RSA при настройке TLS, чтобы получить простую возможность анализа трафика, крайне не рекомендуется.

8.

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

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

9.

Итак, современный TLS-сервер должен поддерживать версию протокола 1.3 и, в качестве дополнительной версии – 1.2, все предыдущие версии не рекомендуются, и могут присутствовать только в случае строгой необходимости доступа для каких-то устаревших клиентов. Для TLS-сертификата сервера лучше выбрать криптосистему ECDSA, но при этом нужно обратить внимание, что вся цепочка сертификатов поддерживает ECDSA, в противном случае – смысла в ECDSA сильно меньше. Криптосистема RSA, хоть и является устаревшей, но всё ещё может применяться, особенно, когда других вариантов нет, как с современной (2021) версией бесплатного УЦ Let’s Encrypt. TLS-сервер обязательно должен использовать протокол Диффи-Хеллмана для получения сеансового секрета (это актуально только для старых версий TLS). В настройках серверов данный протокол обозначается как DH, ECDH или ECDHE. Шифр для защиты трафика должен работать в режиме аутентифицированного шифрования, подходит, например, AES-GCM.

Если вас заинтересовали подробности, то в качестве отдельной публикации доступно детальное техническое описание TLS.

Некоторые другие записки по теме на dxdt.ru:

Популярно о перехвате HTTPS

DNS-over-TLS на авторитативных серверах DNS

“Ключи на клиенте” и протокол Диффи-Хеллмана

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