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

Пишут, что в Microsoft не сумели корректно поменять SPF-запись для hotmail.com, а поэтому почта из данного домена попадает в категорию “Спам”. Детали я не проверял, но, похоже, IPv6-блоков в SPF там сейчас нет совсем. SPF – среди магических методов Нового Средневековья.

(Update: починили, через полсуток.)

Что касается 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.

Сервис audit.statdom.ru проверяет разнообразные настройки по доменному имени и выводит отчёт. В том числе, проверяются настройки электронной почты (по MX-записям). Недавно добавили проверку TLS для STARTTLS. STARTTLS в SMTP означает возможность использовать TLS при доставке сообщений на сервер. О поддержке STARTTLS сервер может заявить в перечне опций, который передаёт клиенту в ответ на начальную команду EHLO. Собственно, раньше сервис audit.statdom.ru проверял только наличие флага STARTTLS, но не пытался установить TLS-соединение. В очередном обновлении – добавили фактическую проверку наличия TLS и сопоставление имён из сертификата, если сертификат сервера удалось получить. (Вообще, в практике SMTP, проверка соответствия имени в TLS-сертификате имени хоста не относится к необходимым процедурам: уже хорошо, что сервер хоть какой-то всё ещё валидный сертификат прислал – это позволяет перейти к защищённому соединению, а это часто лучше, чем открытый канал. Но, конечно, ещё лучше, если сертификат соответствует по имени.)

Ссылка: audit.statdom.ru

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

Подборка ссылок: “Тысячи спутников или орбитальный радар”, “Спутниковая группировка Starlink от SpaceX как замена GPS”, “Инфракрасные сенсоры на орбите”, “Наземные терминалы Starlink как элементы радара”; и не совсем по этой теме, но тоже занимательная записка из 2010 года: “Воскресный юмор: глобальная навигация на очень чужих планетах”.

(Источник картинки: NSF’s National Optical-Infrared Astronomy Research Laboratory/CTIO/AURA/DELVE, Wikimedia.)

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

YandexGPT, через интерфейс под названием “Алиса”, сообщило, в частности, следующее: “число делится на 2 и на 11, а значит, делится и на 3”. Конечно, это всего лишь автоподстановщик-синонимайзер, но вокруг более развитого варианта, – ChatGPT, – тем не менее, накручивают целое “научное направление” по защите от угроз “сверхразумного” ИИ.

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

Вот так представляется бот, собирающий веб-страницы для разновидностей ChatGPT: “Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; GPTBot/1.0; +https://openai.com/gptbot)”. В августе бот почему-то особенно активен на dxdt.ru, где, собственно, и был мной замечен в логах.

Всегда ли требуется знать значение секретного ключа, чтобы провести ту или иную атаку на систему аутентификации с подменой стороны? Вовсе нет.

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

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

В канале Бориса Трушина попался скриншот вопроса на некотором телевизионном шоу: “Площади каких двух фигур ни при каких размерах не могут быть в точности равны?”; варианты ответов: “A) круга и квадрата; B) треугольника и ромба; C) трапеции и параллелограмма; D) прямоугольника и пятиугольника”. Вроде, это уже достаточно старая задача. С одной стороны, очевидно, что верного ответа среди вариантов нет, с другой стороны, не менее очевидно, что же имели в виду составители сценария и какой ответ назначен правильным: такое вот преломление “квадратуры круга”, видимо. Ну, а с третьей стороны, если рассматривать равенство площадей в смысле равносоставленности и снять некоторые подразумеваемые ограничения, то и вообще может возникнуть задача, известная как “Квадратура круга Тарского”, вместе с дополнительными трудностями в определении “верного ответа” через бесконечные процессы.

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.