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

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

В работе по ссылке – показано, что механизм наследования достаточно силён для того, чтобы покрыть практически всю популяцию, собрав ДНК лишь у небольшой части людей. И речь тут идёт о том, что публичные “анонимизированные” базы позволяют идентифицировать персон, ДНК которых в базе отсутствует, но нашлись родственники разной степени “отдалённости”. Цитата:

“Используя конкретную модель, мы можем предсказать, что база данных с записями о приблизительно 3 млн жителей США европейского происхождения (2% соответствующего взрослого населения), позволяет найти для 99% населения данной этнической принадлежности как минимум одного троюродного родственника, а для 65% – как минимум одного двоюродного”.

Чтобы сопоставить реальных персон записям в базах ДНК, исследователи используют год рождения, примерное место проживания – это позволяет резко улучшить точность. Собственно, задача складывается в чисто комбинаторную, а комбинаторные соображения очень часто помогают убрать всё лишнее и найти реальную структуру, стоящую за данными. Я довольно давно писал на сходную тему, правда, в привязке к “анонимизированным” данным геолокации.

Новая версия TLS 1.3 получила RFC, а именно – RFC 8446 (обратите внимание: TLS 1.0 – RFC 2246, TLS 1.1 – RFC 4346, 1.2 – RFC 5246). Я уже довольно подробно описывал этот новый протокол, который радикально отличается от всех предыдущих версий TLS/SSL. Вот ссылка на подробную статью про TLS 1.3. В блоге Cloudflare – опубликован хороший популярный обзор TLS 1.3 (но он на английском).

TLS 1.3 – это новая версия протокола, вот-вот должен появиться RFC (пока что актуален черновик – draft-28). По адресу https://tls13.1d.pw/ я разместил тестовый сервер, который позволяет попробовать TLS 1.3 на практике, при помощи браузера. Поддержка протокола пока есть далеко не везде. Для сервера я полностью написал стек TLS версии 1.3 на Go, то есть, реализовал всё, что “выше TCP”, так как в стандартной библиотеке поддержки 1.3 нет. (Ну, строго говоря, криптопримитивы использованы библиотечные, а именно – шифры и алгоритмы на эллиптических кривых для протокола Диффи-Хеллмана (DH) и электронной подписи ECDSA.) Это именно тестовый сервер, поэтому он поддерживает не все возможности TLS 1.3, но базовые – поддерживает. В частности, я реализовал две draft-версии: 28 и 23. Draft-28 – должен стать RFC, а 23-й поддерживается распространёнными клиентами. (Update: c 09.2018 поддерживается и RFC-версия – 0x0304.) Сервер умеет шифры AES (с GCM) и ChaCha20 (c Poly1305). DH для сеансовых ключей и подпись – только эллиптические (возможно, RSA и “мультипликативный” DH я добавлю позже; update: c 26/01/2019 – есть поддержка “мультипликативного” DH). Кроме TLS – есть кусочек, поддерживающий HTTP-запрос GET, он позволяет использовать обычный браузер и выводит в текстовом виде подробную информацию о TLS-соединении. Понятно, что для получения этой информации TLS-соединение нужно установить. Версий TLS ниже 1.3 – тестовый сервер не поддерживает (совсем не поддерживает: всё же, это специальный сервер, я просто не стал их реализовывать, так как от 1.3 они отличаются весьма существенно).

Два самых распространённых браузера – Chrome и Firefox – уже умеют TLS 1.3 в своих самых свежих версиях. Я проверил Chrome 68 (версия draft-23 TLS) под Debian и Android 8, FireFox Quantum 62.0b14 (это бета) под Debian, а также Firefox 61 под Android 8: все эти браузеры соединяются с тестовым сервером, а FF 62 даже поддерживает draft-28 (самый свежий вариант). То есть, вы можете попробовать подключиться к тестовому серверу, если у вас актуальная версия браузера. Кроме того, 1.3 умеет утилита s_client из пакета OpenSSL версии 1.1.1-pre8, но это тоже бета-версия, которую нужно самостоятельно собирать. Все прочие типичные инструменты (wget, curl и т.д.) – скорее всего TLS 1.3 пока что не умеют (но планируют быстро добавить поддержку).

Если браузер сумел договориться с сервером, то вы увидите простую текстовую страницу (англ.) с параметрами TLS, в частности, там отображаются сеансовые ключи. Сервер использует полноценный TLS-сертификат от Comodo (с ECDSA), поэтому предупреждений о безопасности барузер показывать не должен. Если соединиться не удалось, то, скорее всего, браузер выведет ту или иную ошибку SSL/TLS. Возможны варианты, когда соединение просто сбрасывается на уровне TCP (например потому, что мой сервер не присылает фиктивное сообщение ChangeCipherSpec, и такие соединения разрывает DPI, но это технические детали, которые, впрочем, очень интересно отследить). Попробуйте: https://tls13.1d.pw.

(Сервер специально использует статический ключ DH и “не слишком случайное” значение поля Random.)

Update: кстати, если вы хорошо знакомы с TLS и интересуетесь всякими занимательными “гиковскими” штуками, то рекомендую внимательно взглянуть на открытый ключ ECDSA сервера tls13.1d.pw – этот ключ входит в состав TLS-сертификата (смотреть нужно в шестнадцатеричной записи).

Update 13/08/2018: добавил передачу сообщения ChangeCipherSpec сервером; в случае TLS 1.3 – это фиктивное сообщение, которое нужно только для того, чтобы “замаскировать” TLS-соединение под предыдущие версии, обеспечивая прохождение через промежуточные узлы с DPI и прочей фильтрацией трафика.

Update: c 28/12/2018 добавил поддержку ESNI.

English note: there is a test implementation of TLS 1.3 server (RFC 8846, draft-28,-17) with HTTPS support.

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. Это, в частности, актуально для распространённых мессенджеров.

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

p = 2ⁿ – 2ⁿ⁻⁶⁴ + 2⁶⁴(⌊2ⁿ⁻¹³⁰e⌋ + x) – 1

Для чего она нужна и что обозначает?

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

Это формула, по которой генерируются простые числа, задающие группу для DH в TLS. n – требуемая разрядность, e – основание натурального логарифма, x – переменная, принимающая целые положительные значения. То есть, можно сказать, эта формула извлекает из числа e подходящее целое простое число нужной разрядности (подходящее – потому что подходит не всякое, но это детали). Для получения именно простого числа – нужно подбирать значение x (используется минимальное подходящее). Механизм описан в RFC 7919 (но попробуйте “нагуглить” эту формулу).

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

Впрочем, с фиксированными параметрами DH связаны и более простые рассуждения: стойкость DH базируется на сложности дискретного логарифмирования, но для классического варианта и заранее заданной группы (параметра, то есть) известно, что можно предвычислить некоторые алгебраические структуры, которые потом позволят вычислять логарифм быстро. Правда, такие вычисления требуют огромных мощностей и/или затрат времени. Но если вы теоретико-числовая служба специального агентства и заранее знаете, что набор из нескольких групп позволит раскрывать почти весь TLS-трафик, то можно и потратиться. Ключевой момент тут – нужно заранее знать группу, а универсальные методы неизвестны.

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

Довольно давно я писал про ультразвуковые излучатели, которые позволяют модулировать звуковые волны в слышимом диапазоне, наводя “голос” в заданном секторе пространства. Сейчас голосовое управление присутствует во многих устройствах. Например, является штатной возможностью смартфонов. Естественно, аналогичным способом, с помощью ультразвука, наводить нужные голосовые команды можно непосредственно в микрофоне смартфона. При этом, находящиеся рядом люди ничего не слышат. Так, в работе по ссылке – DolphinAttack: Inaudible Voice Commands – рассматривается практическая реализация атаки, использующей неслышимые для владельца голосовые команды с целью управления смартфоном.

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

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

Данное направление особенно интересно выглядит в контексте набирающих всё большую популярность систем биометрической идентификации по голосу.

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