Пишут про перехват TLS-трафика сервиса Jabber.ru, без ведома администраторов: это практическая атака, судя по подробному описанию – там всё как положено: MITM в TLS и подмена серверного сертификата на тоже валидный. Как пишут, выпуск сертификата, скорее всего, проведён при помощи перехвата трафика, идущего на оригинальный сервер – подменные сертификаты попали в CT-логи, в описании есть на них ссылки (это сертификаты Let’s Encrypt, конечно).

Вообще, побороться с подобной подменой, когда возможен перехват трафика на уровне хостера (а это практически всегда так), весьма сложно. Единственный более или менее эффективный способ – прямая авторизация серверных ключей клиентом по отпечаткам, однако, это сложно, плохо масштабируется, ну и так далее. (Отмечу, что применительно к Jabber/XMPP – есть схемы с защитой точка-точка, между пользователями – OMEMO, например). Certificate Transparency (CT), CAA и подобные технологии, направленные на УЦ, от таких атак не особо защищают: CT, несомненно, полезно, но часто работает постфактум, потому что, как минимум, нужно клиентам проверять метки в сертификатах; и это, если вообще считать, что CT тут работает – технически, выпустить быстрый подменный сертификат УЦ может без меток логов, ничто этому не мешает; да и метки можно сделать без публикации в логах, если есть ключи от этих логов; но, конечно, это всё существенно усложняет процесс. Что касается CAA-записей: да, это полезно, но для УЦ, технически, отказаться от проверки CAA ещё проще, чем проигнорировать CT-логи и SCT-метки.

(Ссылка: описание инцидента от OpenNet на русском.)

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



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

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

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

Так что, если где-то утверждается, что ИИ c LLM “понимает текст” и “успешно решает творческие задания”, то нужно к этому относиться с существенной долей сомнения, мягко говоря: “плоская” программа – она есть программа “плоская” (даже если там несколько слоёв “нейросетей”).



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

Исходная мотивация для квантовых вычислений состоит не в кубитах, а в поиске механизма, который позволил бы вычислить “невычислимое”, ну или хотя бы “сложновычислимое”. Кстати, едва ли не первое описание концепции дано в книге Ю. И. Манина “Вычислимое и невычислимое”, 1980 года (изд. “Советское радио”) – там несколько абзацев в предисловии (с.15) посвящено “квантовым автоматам”, уже эти несколько абзацев точно и полно описывают концепцию того, как квантовые вычисления далее и развивались. Сама книга не о квантовых вычислениях. Тем не менее, в тексте предисловия на примере проблем моделирования известными “классическими” методами простых физико-химических явлений, показана связь с несравнимо большей мощностью пространства квантовых состояний – вот эту мощность и предлагается использовать в реализации будущих вычислительных механизмов.

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

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

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

Впрочем, концептуальная идея квантовых вычислений основана на обратной трактовке ситуации: предположим, есть физический процесс, который явно опережает “по скорости сходимости” все известные для моделирования похожих процессов вычислительные методы, – давайте используем сам этот процесс для вычислений, хоть бы и по какой-то другой задаче. Некая запредельная квантовая процедура быстро определяет конфигурации осколков ёлочной игрушки (волка там какого-нибудь, это не так важно) – давайте сводить другие задачи к модели, полезный результат которой отобразится в конфигурацию осколков. Это больше похоже на “квантовый отжиг” (quantum annealing), но, собственно, такой же подход реализуется и в алгоритме Шора, который описывает, как перевести задачу отыскания периода функции в квантовомеханические “операторы”. Алгоритм математический, а для успешной его работы остаётся найти подходящий физический процесс. С этим могут быть трудности. Естественно, это всё напрямую связано с тем, что пока что толком не понятно, откуда именно берётся “мощность”, стоящая за конкретным, пусть и гипотетическим, квантовым вычислением.

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

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



Комментировать »

Идея заменить простой, обозримый и понятный 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 могут быть совсем не такими, как планировалось.



Комментировать »

Развитие полузабытого проекта “Яндекс.Рефераты”: нейросеть YandexGPT “сдала” ЕГЭ по литературе, при этом “усреднённая оценка составила 55 баллов”, что подстёгивает “хайп”, так как, якобы, позволяет поступить в вуз. Интересно, смогла бы данная нейросеть хотя бы заполнить бланк ЕГЭ?

Кстати, цитата из недавнего вывода данной нейросети: “число делится на 2 и на 11, а значит, делится и на 3”. (Новое средневековье уже со всех сторон.)



Комментировать »

Выпустил ежегодное обновление технического описания TLS, которое я поддерживаю: в этом году лишь добавил в раздел “TLS и постквантовая криптография” краткое изложение внедрения X25519Kyber768 в браузере Chrome (и то – только про интеграцию в схему TLS; в принципе, это уже публиковалось на dxdt.ru).



Комментировать »

Открытый ключ Kyber768 (постквантовой криптосистемы) – это 1184 байта, то есть, 9472 бита. Это заметно больше, чем занимает практический 8-килобитный ключ RSA. Для взлома такого RSA-ключа на квантовом компьютере (весьма гипотетическом), требуется количество логических кубитов в разных регистрах не меньше 24576 == 8K * 3. Но это теоретический минимум для логических кубитов, без учёта квантовых схем и возможной физической реальности. Поскольку технологические принципы реализации алгоритма Шора пока что не известны, оценки того, сколько физических кубитов и квантовых элементов потребуется для подобной разрядности, затруднены и сильно различаются, но нетрудно получить оценку в миллион (и более). И этот миллион квантовых эллементов, к тому же, может не сработать.

Естественно, это не отменяет того, что Kyber768 тут выглядит лучше, если обладает классической стойкостью. Кроме того, RSA – устаревшая криптосистема, а для коротких, относительно RSA, ключей ECDSA (например) – и кубитов потребуется поменьше, при этом прямо “растягивать” ту же ECDSA на несколько килобит – так себе идея.



Комментировать »


Комментировать »

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



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

В октябре 2008 года, пятнадцать лет назад, на dxdt.ru, например, вышла записка про загадочную программу DARPA GANDALF – носимую систему поиска, идентификации и определения координат радиопередатчиков:

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

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



Комментировать »