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

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

(Дополнение, 17/12/2024: в 2024 году Kyber768 была стандартизована NIST под обозначением ML-KEM; ML-KEM, как алгоритм, имеет некоторые отличия от Kyber768, поэтому две криптосистемы, хоть и совпадают по математической основе, но не совместимы на уровне операций. Браузеры, чтобы не поддерживать несколько максимально похожих криптосистем, использование которых сопряжено с передачей больших блоков данных, перешли с Kyber768 на ML-KEM, но тоже в составе “гибрида” X25519 + ML-KEM. Способ встраивания ML-KEM логически полностью совпадает с описанным ниже для Kyber768, отличается только порядок блоков данных.)

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-сессии, какие-то другие параметры – не изменяются.

Всё же я пока восстановил свой экспериментальный сервер 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-сервиса, потому что возможны и другие каналы утечки метаинформации.

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

Так вот, если у вас есть устройства “на местах”, которые приносят дополнительную информацию, а не только “координатные данные” GPS, то можно на центральном сервере выстраивать динамику изменения реального навигационного поля по сравнению с моделью, учитывающей только положение и состояние спутников. Это позволяет не просто получить корректирующую величину для всех участников системы, но также увидеть возникающие на местах пространственные дефекты и искажения с развёрткой по времени (то есть, не просто спуфинг), что весьма ценно.

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

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

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

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

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

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

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

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

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

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

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

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

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

В 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).

Иногда приходится слышать, что “нейросети и машинное обучение работают с действительными (вещественными) числами”. Звучит занимательно, потому что практически никакое действительное число в отдельный компьютер или даже в дата-центр, набитый специализированными “тензорными процессорами”, по записи не уместится. Более того, если бы действительные числа были доступны на этом технологическом направлении, то почему бы тогда не взять десятичную запись π и, вместо “обучения”, не найти там уже готовый набор коэффициентов под нужную задачу?

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

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

Что касается STARTTLS. Для доставки электронной почты между почтовыми серверами в Интернете повсеместно используется протокол SMTP. SMTP – это “текстовый протокол”, то есть, его работа основана на командах, отправляемых в виде человекопонятного текста (ну, с точностью до числовых кодов состояний, которые, впрочем, тут тоже записываются ASCII-текстом) через любой подходящий транспорт. Многие достаточно древние протоколы в Интернете – текстовые. Потому что текстовые протоколы – это очень удобно и понятно. Там, где применимо. Сейчас, постепенно, этот подход возвращается (примеры: текстовые, REST-подобные API с JSON и др.), но, конечно, не везде.

Вернёмся к SMTP. Классические SMTP-сессии проходят в открытом виде, это означает, что содержание письма, доставленного электронной почтой, будет нетрудно просмотреть на любом промежуточном узле, которых легко могут быть десятки. (Обратите внимание, что дополнительные методы зашифрования содержания письма – PGP, S/MIME и т.д. – они относятся к другому уровню, не к SMTP.) Чтобы иметь возможность дополнительно защитить содержание писем в процессе доставки и используется STARTTLS: этот механизм позволяет SMTP-клиенту и SMTP-серверу перейти на защищённый канал “точка-точка” (см. пояснение ниже) после того, как они уже начали сессию в открытом варианте.

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

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

Поскольку сам SMTP полностью открыт, его не так уж трудно проксировать с изменениями, даже подменяя IP-адреса узлов. Серверное сообщение о поддержке STARTTLS можно просто вырезать из соответствующего ответа – если клиент допускает доставку без TLS, то он уже не будет пытаться установить TLS-соединение, а перейдёт к доставке в открытом виде. Это давно известная особенность, указанная в RFC.

В практике SMTP, при доставке писем между почтовыми серверами, принято не особенно строго подходить к обработке параметров TLS. Причина в том, что иначе почта перестанет ходить совсем. Поэтому TLS тут является примером того, что называется “приспособительным” (или “ситуативным”) подходом в использовании криптографии для защиты от прослушивания: “если удалось, то будем зашифровывать, а если нет – тогда ладно”. (В английском варианте – “opportunistic encryption”; однако переводить тут opportunistic на русский как “оппортунистическое” – не верно: соответствующие коннотации слишком сильно отличаются; это даже хуже, чем Чарльз, превращающийся в Карла.) Для защищённой работы SMTP есть и вариант использовать TLS-соединение сразу, до начала SMTP-сессии (SMTPS и др.), однако этот подход уже не имеет отношения к STARTTLS.

IDN – это “многоязычные доменные имена” (Internationalized Domain Names), подразумевающие преобразование кодировок на стороне клиента: Unicode кодируется при помощи Punycode, поскольку в DNS, пока что, Unicode не используется (полезная технология, вообще говоря, полезна лишь там, где действительно нужна и может быть внедрена, но это история для другой записки). Весьма неудобный дополнительный слой, который образуется из-за обработки IDN, постоянно приводит к проблемам. Самая “заковыристая”, а поэтому постоянно вылезающая тут и там, проблема – нормализация unicode-записи. Собственно, не так давно мне пришлось исправлять эту проблему в одном из сервисов, работающих с доменными именами. Но если сейчас посмотреть и потестировать те или иные профильные веб-интерфейсы, преобразующие IDN, то, думаю, данная экзотическая проблема проявится у многих (это особенно близко регистраторам доменных имён). Кстати, если этот текст читают разработчики подобных инструментов, то потестируйте имеющиеся реализации. Строки для тестирования я привожу ниже, вместе с описанием логики проблемы (впрочем, она уже упоминалась в прошлогодней записке про шумерские цифры, которую вряд ли много кто прочитал).

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

Посмотрите на две строки: “биткойн.рф” (1) и “биткойн.рф” (2) – они должны выглядеть одинаково. Эта одинаковость обманчива, потому что в первом случае “й” записано как U+0438 + U+0306 – буква “и” + “знак бреве”, два значения; а во втором случае – это просто буква “й” (U+0439, одно значение), где, так сказать, всё включено.

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

Возвращаемся к IDN. Эта технология требует преобразования кодов Unicode к DNS-записи, алфавит которой допускает (без учёта регистра) для подстрок имён хостов символы [a-z] (от “a” до “z”), [0-9] и “минус” “-” (точки тут не считаем). Для кодирования этими ASCII-символами байтовых значений Unicode используется алгоритм, называемый Punycode. Принцип тут аналогичен тому, как работает, например, Base32 (или “кодирование в рунах”), детали отличаются, но нам это здесь не так важно. Важно, что Punycode ничего не знает про особенности Unicode и просто отображает в подмножество ASCII значения unicode-байтов (и обратно), то есть, разные кодовые записи одной буквы отобразятся в разные punycode-последовательности. Что не так трудно продемонстрировать на нашем примере: “биткойн” == “qsa11dvaajue4a”, а “биткойн” == “90aoddqe0a” (выглядит занятно, да).

Однако с точки зрения DNS “qsa11dvaajue4a” и “90aoddqe0a” – разные значения, поэтому имена, их содержащие, тоже будут разными. Разный способ записи одного и того же графического представления для целей DNS не подходит – в реестрах имён, на серверах имён, первоочередное значение имеет ASCII-представление. Поэтому и используется процесс, называемый нормализацией, который описывает соглашение о том, как разные “чёрточки” так приклеить к буквам, чтобы привести всё к одной последовательности кодов, а уже её использовать, например, в DNS. Естественно, unicode-нормализация важна не только в DNS, но подробное описание принципов остаётся за рамками этой записки – его можно найти в соответствующем документе. Отмечу, что современные библиотеки для работы с IDN, обычно, позволяют прозрачно использовать нормализацию, нужно только не забыть её правильно включить при вызове функций преобразования. И, вообще говоря, алгоритмов нормализации – несколько, что делает ситуацию интереснее. А полагать, что столкнуться с подобным на практике невозможно, будет ошибкой – копирование символов иностранных письменностей в составе имён, которые не удалось ввести с клавиатуры, вполне себе встречается.

SPF (Sender Policy Framework) в Интернете позволяет администратору домена через DNS определить перечень адресов узлов, которые могут доставлять email-сообщения с адресами в данном домене. SPF публикуется в TXT-записях. Распространено мнение, что SPF – чрезвычайно простой инструмент, “всего лишь список IP-адресов”, который легко проверить, не получив фактического письма от почтового сервера. Конечно, если рассматривать практику массового применения SPF, то, действительно, так как большинство администраторов используют SPF в самом простом варианте записи, может показаться, что никаких дополнительных уровней логики там и нет. Это, однако, не так: спецификация достаточно сложная, определяет “макросы”, а поэтому позволяет реализовать весьма экзотические настройки. Один из примеров такой экзотики – использование механизма аутентификации exists.

Тип exists позволяет встроить в SPF произвольные имена DNS, которые генерируются на стороне проверяющего узла на основе данных конкретного подключения. То есть, эффект от работы таких фильтров нельзя предсказать простым опросом DNS – нужна ещё и SMTP-сессия.

Например, запись exists:%{ir}._relays.example.net обозначает, что нужно IP-адрес (i) отправляющего узла (как он виден на стороне принимающего) использовать в запросе A-записи в зоне _relays.example.net, и при этом запись IP-адреса нужно перевернуть по октетам (r). То есть, если почтовое сообщение пытается доставить узел с адресом 10.11.12.13, то сконструированное имя для запроса в DNS будет таким: 13.12.11.10._relays.example.net. Если IP-адрес не известен, то и обработать такой фильтр нельзя. Помимо i в спецификации определены и другие макроподстановки, например, домен отправителя, имя из EHLO/HELO и т.д. Впрочем, exists встречается даже реже, чем другой экзотический вариант – exp.