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

Вдруг пришло письмо с предложением “выбрать билет” на РИФ-2025. Билет стоит денег. А РИФ – почему-то теперь осенью. Мало кто помнит, но РИФ – Российский интернет-форум – это такое старинное интернет-мероприятие было. Оно ежегодно проходило в подмосковных пансионатах, но весной и, обычно, в “Лесных далях”. Я даже там бывал несколько раз, довольно давно. Интересно, что домен современного РИФ-2025 – rif.ru – делегирован на серверы Cloudflare.

Мессенджер Signal внедряет платное централизованное хранение резервных копий сообщений на своих серверах. Занятно, что Signal позиционируется как “безопасный мессенджер”. Впрочем, вряд ли какое-то из этих новомодных приложений не позиционируется как “безопасное” или “самое безопасное”.

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

Раскрученные СМИ мессенджеры развиваются по схожим сценариям. Так что теперь в Signal, даже если пользователь уничтожил устройство с приложением, сообщения можно официально и штатно восстановить из центрального хранилища. Собственно, эта возможность и заявлена в качестве основной. Уничтожение устройства не является обязательным условием копирования сообщений из хранилища. А ключи – ключи утекают в результате ошибок или в результате “ошибок”.

Кстати, я в прошлом году писал про особенности хранения копий сообщений мессенджеров.

В Cloudflare выпустили разбор ситуации с выпуском неавторизованных TLS-сертификатов для 1.1.1.1. Пишут, что в логах Certificate Transparency (CT) эти TLS-сертификаты не обнаружили потому, что не отслеживались сертификаты для IP-адресов, в мониторинг приходило слишком много сообщений из CT, а также и не для всех доменов/ресурсов настроили отслеживание сертификатов.

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

В продолжение предыдущей заметки, про подозрительные сертификаты для 1.1.1.1, выпущенные УЦ Fina RDC 2020: интересно, что, согласно crt.sh, соответствующие пресертификаты есть и в CT-логах (Certificate Transparency) Cloudflare. Выпускать такие “странные” сертификаты в данном УЦ начали ещё в прошлом году. То есть, получается, что либо Cloudflare вообще не следит за именами из сертификатов даже в тех CT-логах, в которых является провайдером, либо это всё же по согласованию с Cloudflare выпущено. Естественно, последний вариант – ну уж совсем маловероятен, а вот в то, что Certificate Transparency не отслеживается – поверить как раз нетрудно.

Обнаружились подозрительные TLS-сертификаты, валидные для IP-адреса 1.1.1.1 (в поле SAN), но, видимо, выпущенные без согласия компании Cloudflare, являющейся оператором адреса. Один из сертификатов довольно свежий – 26 августа этого года. Выпущены эти сертификаты УЦ (Удостоверяющим Центром), ключи которого, как пишут, входят в список доверенных Microsoft Windows (но не Mozilla, и не Google Chrome).

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

Такой сертификат, при наличии секретного ключа, позволяет незаметно для пользователя перехватить TLS-трафик в сторону IP-адреса 1.1.1.1, который соответствует нескольким глобальным сервисам Cloudflare (DNS-резолвер и VPN-сервис, как минимум). Чтобы перехват сработал – клиентское ПО должно считать ключи УЦ доверенными, так что, получается, в такой конфигурации сработает только для Windows (ну или только в браузере Edge, если он использует отдельный набор корней, а сама ОС этому УЦ не верит).

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

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

Интересно, что сейчас применение маскирования IP обещают по списку доменов, который доступен на Github; в этом списке, на момент написания записки, значится почти весь “официальный” веб от “Яндекса” (yandex.ru, mc.yandex.com, yandex.st и др.), а кроме того: vk.com, mail.ru и прочие, хорошо узнаваемые в Рунете, доменные имена.

Опубликовал тут на “Хабре” популярный обзор про время в прикладной криптографии. Это, можно сказать, по мотивам недавней записки на ту же тему.

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

Добавил в перечень избранных записок (за все времена dxdt.ru) ещё десять:

• Постквантовые криптосистемы до алгоритма Шора
• Практикум: примеры с dig для DNSSEC и DNS
• Техническое: ошибки делегирования в DNS
• Fewer, less и переключение фокуса интерпретации
• Древние знаки цитирования “дипле”

• Элементарные числа в ML-KEM
• Автоматизация ИИ-агентов и атаки
• Популярная температура как “климатический скаляр”
• “Умные колонки” и отключение микрофона кнопкой
• Целевая подмена приложений и “прокси” для утечек

Некоторые записки, опубликованные на dxdt.ru в августе, отмечу отдельно:

• Техническое: строгая, но избыточная фильтрация email
• Как DNS работает через TLS: DNS-over-TLS на практике
• Моделирование физических экспериментов и превосходство квантовых вычислений
• Реплика: нехорошие проявления LLM
• Обратное синтезирование апертуры антенны РЛС

Дистрибутивность умножения относительно сложения означает, что a*(b + c) = a*b + a*c. В действительных числах, по определению, умножение дистрибутивно относительно сложения. Запишем это на Pyhton и посмотрим, что напечатает простая программа.

import math

q = 11*(math.sqrt(5) + math.sqrt(17))    # q = a*(b + c)
p = 11*math.sqrt(5) + 11*math.sqrt(17)   # p = a*b + a*c
print(p == q)                            # q == p => (q - p) == 0

q = 34*(math.sqrt(5) + math.sqrt(17))
p = 34*math.sqrt(5) + 34*math.sqrt(17)
print(p == q)                            # ???

Запускаем (Python 3.11.2) и смотрим:

True
False

В коде, в первом случае, написано:

p = 11*(√5 + √17),
q = 11*√5 + 11*√17.

Значения p, q сравниваются. Программа выводит True – значения равны. Что и следовало ожидать, если бы это были действительные числа: по определению, q и p – это одно и то же число.

Во втором случае написано всё то же самое, алгебраически, но другой множитель:

p = 34*(√5 + √17),
q = 34*√5 + 34*√17.

Удивительно, но результат сравнения p и q теперь False – числа не равны.

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

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

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

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

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

Естественно, в хороших практических разработках это учитывается. Существенная часть практических алгоритмов в том же “машинном обучении” (Machine Learning – ML) как раз относятся к преобразованию подобных погрешностей. Корректная работа с погрешностями вообще очень важна при вычислительной обработке экспериментальных данных. Но почему-то всё равно приходится постоянно встречать утверждения, что “ML работает в действительных числах”.