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

Идея заменить простой, обозримый и понятный HTTP, построенный по схеме “запрос-ответ”, на вариант, инкапсулирующий часть логики TCP внутрь ещё одного, более сложного, протокола, с мультиплексированием и приоритизацией, который, тем не менее, сам работает внутри TCP-соединения, ожидаемо приводит к появлению новых, хитрых направлений DoS-атак, эффективно использующих “перемешивание логики” между этими вложенными протоколами. В данном случае – речь про HTTP/2: такую атаку и разбирают в блоге Cloudflare.

(Кстати, об особенностях мультиплексирования HTTP/2 регулярно забывают, что приводит к попыткам ограничить поток HTTP-запросов для проксирующего веб-сервера, который работает по HTTP/2, “силами iptables” по TCP-соединениям.)

Anycast (в Интернете) – это, грубо говоря, способ распределить один IP-адрес на несколько узлов. Глобальный anycast подразумевает, что некоторый IP-адрес обозначает разные узлы, расположенные в совсем разных сетях и, возможно, разных регионах. Применяется данная технология, обычно, для того, чтобы сделать входные узлы некоторого глобального распределённого сервиса ближе к локальным пользователям, сохранив нумерацию в IP-адресах (“ближе” здесь обозначает расстояние в смысле сетевых маршрутов пакетов).

Есть занятный, пусть и не самый точный, способ определения того, что какой-то глобальный и маршрутизируемый IP-адрес соответствует anycast-узлу: нужно измерить время ответа (ICMP) при помощи утилиты ping, но сделать это из двух базовых точек, заведомо находящихся в существенно разных регионах, а потом измерить ping между этими точками. Если сумма для времени от точек измерения до измеряемого узла существенно меньше, чем время между базовыми точками, то, скорее всего, тут присутствует anycast. Это неравенство треугольника, и оно тут при помощи anycast нарушается.

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

Один из самых старых способов скрытого получения доверенного доступа к не менее скрытым сервисам в Интеренете (как IP-сети) это port knocking (метод “секретного портового стука”). Суть метода изложить не трудно: скрываемый сервис работает на закреплённом за ним номером порта, но доступ для TCP-соединений (например) к этому номеру порта открывается только для тех IP-адресов, которые выполнили установленный набор попыток подключений по другим номерам портов. Чуть более развёрнутое объяснение для тех, кто не сетевой инженер (опять же, используем TCP): TCP-соединение – это соединение “точка-точка”, на каждом из концов соединению соответствует IP-адрес и номер порта, где номер порта, можно считать, это просто 16-битное число; например, 10.11.12.13:14395 -> 10.101.102.103:22 – соединение клиента с номером порта 14395 на серверный номер порта 22 (это обычный номер для SSH); предположим, что доступ на сервере по порту 22 закрыт межсетевым экраном (брандмауэром), то есть, попытка соединения на этот номер порта будет проигнорирована сервером; но если некоторый клиент с IP 10.11.12.13 выполнит попытки TCP-подключения на другие номера портов сервера по заданной ключевой последовательности: 1011, 1022, 1033, то брандмауэр, который фиксирует у себя попытки подключения, откроет подключения по номеру порта 22, но только для соответствующего IP-источника.

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

Почему-то данный метод и известен не столь широко, как можно подумать, да и нередко его необоснованно относят к способам защиты из разряда Security through obscurity (“Безопасность через неясность”, в одном из переводов), которые, как бы, “заведомо слабые”, что как раз и есть хороший пример неверного обобщения “принципа Керкгоффса”. Однако данный метод хорош, если используется по назначению и в верном контексте. А если излишне настойчиво обобщать, то и авторизация SSH по ключу может показаться “безопасностью через неясность” – действительно, а как если бы он знал значения байтов секретного ключа и их последовательность? Впрочем, это лирическое отступление.

Идея port knocking очень гибкая, потому что достаточно общая: во-первых, годится и TCP, и UDP, и ещё что угодно “с номерами”; во-вторых, последовательность “стука” не обязательно фиксированная – если есть общий секретный ключ и общее время, то номера можно генерировать псевдослучайным образом; в-третьих, вежливо постучать клиент может в один узел (IP-адрес), а доступ ему откроется на совсем другом (так тоже бывает). Поэтому именно “портовый стук” представляет собой эффективный дополнительный инструмент, затрудняющий обнаружение скрытого сервиса разными активными сканерами (что называется – connection probe). Если последовательность стуков неправильная, то, понятно, никто на неё просто не ответит, поэтому и никакой новой информации получить не выйдет.

Действительно, номера портов, которые открывают возможность соединения, видны в сетевом трафике. Но если это псевдослучайная последовательность, толку, в плане анализа трафика и сервисов, от этого не очень много – мало ли кто и какие порты сканирует? Добавление же контекста в DPI тут существенно повышает сложность анализа трафика. К port knocking можно добавить пакеты (UDP, например), содержащие дополнительные ключи, что, вместе с заменой адресов, совсем хорошо перемешает информацию, ещё больше затруднив анализ и построение контекста. Интересно, что через номера портов, в принципе, можно передавать и выбранный номер входного узла, к которому требуется получить доступ. То есть, конкретный вход в туннель и его свойства определяются выбранной последовательностью “стуков”. Впрочем, если простой port knocking в линуксах, например, относительно легко реализуется силами iptables (типовой межсетевой экран), то расширенные, хитрые способы – потребуют отдельного специализированного модуля, обрабатывающего низкоуровневую информацию о соединениях.

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

(Надо заметить, что Google, в сходном “порыве монетизации”, старые аккаунты GoogleApps, которые идут ещё с какой-то там “закрытой бета-версии”, всё же пока оставил бесплатными – по крайней мере, в моём случае. Не ясно, конечно, останется ли оно так и дальше.)

Очень полезный тест SSLLabs для TLS пока что не умеет обнаруживать поддержку криптосистемы X25519Kyber768 сервером – см. фрагмент результатов для tls13.1d.pw на скриншоте ниже (Supported Named Groups). Это, собственно, понятно и логично: использование данной криптосистемы всё ещё находится в экспериментальном статусе, а поддержка на стороне сервера совсем не распространена.

(Кстати, в результатах указано, что имена групп/криптосистем выведены в порядке предпочтений сервера, но для tls13.1d.pw это не так – сейчас “предпочтение” есть только для X25519Kyber768, остальные криптосистемы выбираются по наличию клиентских key_share, перечню поддерживаемых групп, но при этом ещё и случайным образом отправляется HelloRetryRequest – именно из соображений, что иногда нужно отправить HelloRetryRequest, а не по составу полученных клиентских параметров; обычные TLS-серверы так вряд ли делают.)

В продолжение недавней записки про X25519Kyber768 на TLS-сервере – подробности встраивания данной гибридной криптосистемы в схему работы TLS 1.3.

1. Как нетрудно догадаться, X25519Kyber768 состоит из X25519 и Kyber768, поэтому криптосистема и гибридная. X25519 – это хорошо известный вариант протокола Диффи-Хеллмана (DH), здесь используется без изменений, обычным образом (см. кстати, заметку с задачей про 2^255 – 19). Kyber768 – схема KEM (инкапсуляции ключа), построенная на криптосистеме Kyber с “постквантовой стойкостью”. Эта криптосистема реализует зашифрование с открытым ключом (важный момент).

2. В TLS рассматриваемая криптосистема используется для получения симметричного сеансового секрета. Открытый ключ передаётся клиентом в составе ClientHello, в расширении key_share, а ответная часть сервером – в ServerHello, key_share. В логике сообщений тут ничего не меняется.

3. Изменяется часть внутри key_share, соответствующая X25519Kyber768 – клиент передаёт результат конкатенации байтов, составляющих клиентскую часть DH X25519 и открытый ключ клиента Kyber768. Эти данные имеют фиксированную длину, определяемую алгоритмами: 32 начальных байта для X25519 и 1184 для Kyber768, 1216 байтов всего. На сервере данные разделяются (просто, по длине) и используются для обеих криптосистем. А именно: для X25519 сервер вычисляет общий секрет DH и серверную открытую часть DH (B), так же, как это делалось бы в случае отдельной криптосистемы X25519; для Kyber768 – сервер генерирует общий секрет и оборачивает его в KEM (то есть, зашифровывает исходное секретное значение, используя открытый ключ Kyber, присланный клиентом – тем самые 1184 байта). Два секрета сервер объединяет в один массив – здесь, опять же, простая конкатенация: BaseSecret = x25519[] + Kyber_Shared_Secret[]. Обратите внимание на важное техническое отличие: для X25519 общий секрет, на сервере, это результат умножения открытой части DH клиента (A) на секретный скаляр сервера d: s = d*A; а для Kyber – сервер выбирает исходное значение, которое отправляет клиенту в зашифрованном виде (очень похоже на устаревшую схему с RSA-шифрованием в TLS, но устроенную наоборот). При этом внутри KEM Kyber для вычисления секрета по исходному значению используется отдельная функция (KDF), подмешивающая ещё и значение открытого ключа, это необходимый шаг, но, с точки зрения логики получения секрета, это не так важно. Секрет, генерируемый в рамках Kyber768 в TLS – это тоже 32 байта (256 бит). После завершения данного этапа – сервер получил общий симметричный секрет, представляющий собой объединение выдачи двух алгоритмов: 32 байта и 32 байта. Также сервер получил открытую часть DH и зашифрованный Kyber симметричный секрет (это только часть, предназначенная для Kyber, результат X25519 сюда не попадает).

4. Сервер формирует ответное расширение key_share, присоединяя к 32 байтам открытой части DH X25519 байты шифротекста с симметричным секретом, который зашифрован Kyber – длина шифротекста 1088 байтов, всего 1120 байтов. Ответное key_share сервер отправляет клиенту в открытой части сообщений, в ServerHello, после чего генерирует на основе общего секрета набор симметричных сессионных ключей и переходит к зашифрованному обмену данными.

5. Клиент, получив key_share X25519Kyber768, разделяет данные на открытую часть обмена DH X25519 (B) и шифротекст Kyber768. По значению B DH клиент вычисляет общий секрет DH X25519 (здесь – 32 байта), который совпадает с серверным. Используя секретный ключ, клиент расшифровывает шифротекст и вычисляет общий секрет Kyber. Оба полученных значения объединяются, результат должен совпасть с серверным. (Тут слово “должен” использовано потому, что в Kyber, к сожалению, есть вероятностный элемент: так как это схема, концептуально происходящая из кодов с коррекцией ошибок, то имеется очень небольшая вероятность, что “ошибка” всё же останется, а клиент и сервер получат разные значения секрета.) На основе объединённого секрета клиент вычисляет набор симметричных ключей и может проверить подлинность и расшифровать следующие сообщения сервера.

Таким образом, Kyber простым и понятным способом добавляет 256 бит “постквантовой стойкости” к исходному симметричному секрету TLS-сессии, какие-то другие параметры – не изменяются.

Кстати, индекс 0x6399, который позволяет отличить ключи криптосистемы X25519Kyber768Draft00 в TLS-сообщениях, внесён в соответствующий реестр номеров IANA, в раздел под именем TLS Supported Groups. Название раздела – ещё один пример исторически сложившихся особенностей спецификаций: понятно, что X25519Kyber768 – никакая ни группа, а сразу две криптосистемы, построенные на различном математическом аппарате (но, естественно, группы нетрудно найти и в X25519, и в Kyber768). Изначально, упомянутый раздел параметров TLS содержал индексы именованных эллиптических кривых, то есть, сочетаний из параметров, определяющих конкретную кривую в прикладном смысле. Но так как для криптосистем существенны были именно операции в группе, а кроме эллиптических кривых ещё использовались (и используются) мультипликативные группы колец вычетов, то раздел, довольно давно, переименовали в “Поддерживаемые группы”, теперь туда записывают наборы криптосистем.

Развивающаяся “битва за банхаммер” приводит к тому, что в “этих интернетах” появляются новые плоскости для осуществления сегментации, поскольку блокирование сейчас модно делать на достаточно высоком уровне – на уровне приложений. Недавний пример – стена (временная) регистрации в Twitter. Есть масса других примеров, где администраторы вроде бы “глобального” массового сервиса ограничивают к нему доступ для некоторых IP-адресов, но не на уровне транспорта, а средствами HTTP или внутри приложения на смартфоне. Вообще, может показаться, что, с точки зрения “маршрутов” и BGP – ничего не меняется: пакеты если ходят, то так и ходят, как ходили. Для инженера NOC, допустим, прежде всего важно, что отправленный по заданному адресу пакет до этого адреса добрался, а что там происходит на уровнях, которые строятся из пакетов, HTTP это или QUIC какой-нибудь, – дело десятое.

Однако, хоть популярное нынче блокирование и выполняется на один или два уровня выше, чем IP, это самое блокирование может спуститься ниже, но уже в виде технологического спагетти. Это происходит в тот момент, когда просят как-то повзаимодействовать с этим блокированием (неважно, в какую сторону) на сетевом уровне. Всем знакомый пример: VPN-доступ, позволяющий прийти на сервис с другим (географически) сетевым адресом. IP заворачивается внутрь UDP, а туннели неожиданным образом проходят между логическими уровнями. А IP в туннеле используется для создания TLS-соединения со скрытым сервисом. Туннелирование туннелей. Сегментация на уровне приложений спускается в маршрутизацию, где порождает неожиданные эффекты доставки пакетов, особенно, если пересекается с anycast-узлами. Попробуйте зарисовать логику на листочке бумаги – получится путаница из спагетти, напоминающая нехорошую практику в области кабельных соединений.

Дело в том, что хоть блокировать многие предпочитают на разных уровнях, но привычный идентификатор, по которому ставят задачи блокирования, это всё равно IP-адрес (не всегда, но очень часто). Конечно, никто не отменял локального блокирования на уровне физических портов, на уровне приёма BGP-анонсов, однако для массовых и популярных сервисов, которые работают поверх Интернета, – это всё ещё применяется редко. Напротив, сейчас видно, как довольно быстро выстраивается новый перемешивающий уровень (хороший пример – технология ECH, создающая каналы “TLS внутри TLS”). Это нивелирует возможности прицельного блокирования на уровне базового транспорта или, условно, “физических портов”, но позволяет построить банхаммер уровня приложений. Если, конечно, сохранится связность Сети, пусть и через спагетти-коммутацию транспортного уровня.

Всё же я пока восстановил свой экспериментальный сервер TLS 1.3 – tls13.1d.pw (некоторое время назад я писал, что собираюсь его совсем отключить). А чтобы восстановление выглядело поинтереснее, я реализовал на сервере поддержку постквантовой схемы получения общего секрета (KEM) X25519Kyber768. TLS с Kyber768 там реализован вручную, но я, впрочем, использовал криптопримитивы из удобной библиотеки Cloudflare.

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

Вообще, открытый блок клиентского KeyShare в X25519Kyber768 весит аж 1216 байтов (32 + 1184, потому что это ключ X25519, 32 байта, плюс ключ постквантовой части Kyber768, который большой). Тем не менее, я всё же пока что сделал вывод этого ключа без сокращений, что, возможно, выглядит тяжеловато, но видно будет только в браузере с поддержкой данной криптосистемы. (Дополнение, 12/09/2023: технические подробности об использовании криптосистемы.)

Поддержка есть только в самых свежих версиях Chrome (>=116), а включать её нужно через флаги: chrome://flags, набрать “TLS13” в поиске, флаг называется “TLS 1.3 hybridized Kyber support”.

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

Обычно, DNS-резолвер должен работать внутри VPN-сервиса – то есть, это может быть буквально обособленный резолвер, используемый именно в составе VPN (желательно, с DNSSEC). Но так делается далеко не всегда. Напомню, что DNS-резолвер (в данном случае, речь про рекурсивный резолвер) – это сервис, который проводит опрос серверов DNS, отыскивая, например, IP-адреса по именам узлов – адрес, по которому нужно браузеру обращаться к веб-серверу под именем test.ru. Резолвер выполняет то, что называется рекурсивным опросом: обращается к авторитативным DNS-серверам разных уровней. Эти серверы видят IP-адрес резолвера, но не клиента резолвера, который (вероятно) будет подключаться к сервису по обнаруженному в DNS адресу. При этом, для целей балансировки нагрузки на “целевой” сервис, DNS-серверу удобно было бы знать что-то о клиенте, для которого работает конкретный резолвер – потому что балансировка выполняется именно для клиента сервиса, а не для клиента DNS (сервис доменных имён (DNS) в этот момент уже на нужной стороне отработал). Это особенно актуально для больших открытых сервисов DNS-резолверов, например, Google Public DNS, так как эти сервисы обслуживают клиентов из самых разных точек сети. Чтобы как-то помочь оптимизации, довольно давно придумали расширение DNS под названием EDNS Client Subnet (ECS).

Данная технология (ECS) позволяет резолверу передать в сторону авторитативного сервера сведения об IP-подсети клиента, который обратился с запросом. Проще говоря – авторитативный сервер увидит IP-адресный блок, который соответствует клиенту, находящемуся за резолвером, что позволит определить провайдера. ECS как раз поддерживается Google Public DNS (и не только). Предполагается, что авторитативный сервер, определив провайдера клиента резолвера, сможет применить какие-то правила оптимизации. Если VPN используется для сокрытия IP-адреса пользовательского подключения, но DNS-трафик направляется не через VPN в какой-то DNS-сервис, то наличие ECS в этом сервисе (при прочих равных) означает, что внешние авторитативные DNS-серверы увидят скрываемую подсеть. Об этом нередко забывают.

Технический пример (не учитывающий NAT и другие тонкие настройки): предположим, клиентское устройство использует провайдерский доступ с адресом 10.11.12.13, ему соответствует подсеть 10.11.12.0/24; выход из VPN использует подключение с IP 10.22.22.22 (подсеть 10.22.22.0/24); DNS-трафик направляется напрямую (не через VPN) резолверу 10.53.53.53, резолвер поддерживает ECS. Тогда, при попытке определить значение A-записи (адрес), внешние серверы DNS узнают, что к ним подключается резолвер с адресом 10.53.53.53 для клиента из подсети 10.11.12.0/24. А вот на веб-сервере, к которому обращение произойдёт через VPN, адрес клиента будет виден как 10.22.22.22 – внешняя точка VPN. Естественно, если DNS-трафик маршрутизируется устройством через VPN, то внешний DNS-сервис с ECS сможет передать наружу только подсеть точки выхода VPN (10.22.22.0/24), поскольку именно адрес из этой подсети он видит в качестве источника запроса. Но лучше, конечно, если вообще используется собственный резолвер без ECS в составе VPN-сервиса, потому что возможны и другие каналы утечки метаинформации.

В Chrome свежих версий добавлена экспериментальная поддержка “постквантового алгоритма” получения общего симметричного секрета для TLS 1.3 – X25519Kyber768. Это гибридный вариант, в котором в дополнение к “обычной” схеме X25519 используется криптосистема Kyber с заявленной высокой стойкостью ко взлому на гипотетическом универсальным квантовом компьютере (естественно, в дополнение к классической стойкости).

Технически это работает следующим образом: при установлении TLS-соединения Chrome добавляет в начальное сообщение ClientHello клиентскую часть данных X25519Kyber768 (и, естественно, индекс данной криптосистемы указывается в перечне поддерживаемых), если TLS-сервер может использовать данную криптосистему, то он выбирает соответствующий ключ из ClientHello, вычисляет симметричный секрет и использует его на дальнейших этапах. Это работает для TLS 1.3, при этом никак не изменяет каких-то других аспектов процесса установления соединения – не влияет на сертификаты и ключи к ним, не меняет шифров и т.д. На серверной стороне – обещают поддержку от Cloudflare и на некоторых узлах Google. Не вдаваясь в детали, можно смело считать, что X25519Kyber768 – это просто присоединение байтов секрета, полученного Kyber768, к байтам секрета, полученного X25519, на входе функции вычисления ключей для симметричного шифра, в полном соответствии с имеющейся схемой преобразования симметричных ключей TLS 1.3. То есть, схема, как минимум, не хуже криптосистемы X25519, которая уже давно используется, но не обладает постквантовой стойкостью (поскольку это вариант протокола Диффи-Хеллмана с логарифмированием в группе точек эллиптической кривой).

Насколько близки квантовые компьютеры, позволяющие быстро решать задачи отыскания соответствующих секретов асимметричных криптосистем, пока что не очень понятно. Однако постквантовые криптосистемы внедряются из предположения, что такой компьютер всё же может быть создан и позволит расшифровать ранее записанный трафик, из этого делается логичный вывод, что защиту нужно начинать внедрять заранее. Кстати, тут возникает не менее логичный вопрос: почему данный подход не применялся к разнотипным криптосистемам в том же TLS ранее, без требований о квантовых компьютерах? Например, можно же взять какую-нибудь экзотическую криптосистему и прикрепить её к распространённой реализации классического протокола Диффи-Хеллмана (DH), чтобы, если через двадцать лет будет найден неквантовый метод эффективного взлома классического DH, записанный трафик всё ещё оказался бы защищён (улучшения вычислительных атак на классический (“мультипликативный”) DH есть весьма существенные). Вопрос интересный, да. С одной стороны, задачи, на которых строятся распространённые сейчас асимметричные криптосистемы, нередко имеют математически эквивалентную структуру, с точки зрения сложности: то есть, одну задачу можно перевести в другую “с точностью до некоторой константы” (но тут есть куча оговорок – иногда “константа” получается слишком большой, например). С другой стороны, использование отдельного симметричного секрета, распределяемого по защищённому каналу, возможно и в TLS (называется PSK – Pre-Shared Key).