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

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

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

Итак, квантовая атака позволила прочитать пароль из записанной сессии. Однако, если сессия не была записана, то паролю ничего нового не угрожает: в БД этому паролю соответсвует стойкое значение хеш-функции, эффективно обратить которое квантовый компьютер не позволяет.

Другое дело – аутентификация/авторизация “по ключам”, то есть, если у пользователя какой-нибудь доступ “без пароля”, на основе электронной подписи (RSA или ECDSA), но при этом на стороне сервера сохраняется открытый ключ, как он есть (не отпечаток, полученный через хеш-функцию), то квантовый компьютер позволит раскрыть пользовательский секрет уже по значению открытого ключа из БД сервера. Даже не нужно записывать TLS-трафик. Хранение на сервере непосредственно открытых ключей – является вполне себе типовым методом.

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

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

Обсуждали тут, что, мол, для LLM, одинаковые буквы – оказываются разными, потому что это, например, “английская A” и “русская А”. Речь (звуковая) первична, а текстовая запись речи вторична, пусть именно возможность такой записи и создаёт цивилизацию. Так что в фонетическом письме важны звуки, а звуков LLM в тексте, понятно, не наблюдают. Но не нужно делать поспешный вывод о том, что использование омоглифических свойств компьютерного кодирования текста позволяет прямо и легко “дезинформировать” современные LLM, легко разбить тексты по тематикам, сохранив “одинаковость” чтения человеком. Понятно, что для человека, который именно что читает, а не обрабатывает байты с битами кодировок Unicode, нет разницы между “Apple” и “Аpple”. Но и для современных LLM-систем, для которых разница есть, это всё равно так не работает – они уже слишком сложны.

Пример. На скриншоте (ChatGPT-5.5, здесь и далее – режим Thinking/High) обработка фразы, записанной на английском языке, но с использованием большого количества омоглифов – кириллических букв (“а”, “е”, “о”, “р”).

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

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

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

Компьютерное кодирование, приводящее к описанным выше эффектам, приводящее к тому, что “Apple” и “Аpple” становятся разными словами, оно не про начертание. Ни в самом Unicode, ни в ASCII – начертаний нет. Начертания складываются вокруг. Однако при интерпретации букв человеком можно вообще прочитать целое слово не на том языке, который задумывался, лишь бы уже возникшие начертания оказались подходящими. Отличный пример – слово “реникса”. Цитата из недавней записки про рениксу на dxdt.blog:

Cлово “реникса” – это из пьесы Чехова, где оно возникает в анекдоте про неверное прочтение слова “чепуха”, записанного курсивом. И действительно: кириллическая строчная “ч”, рукописным курсивом, выглядит как курсивная же латинская “r”. Unicode, к сожалению, воспроизвести не позволяет. Хоть соответствующий символ там и имеется – Mathematical Script Small R, – но вот в шрифтах он, обычно, выглядит как “правая” “рукописная” r: 𝓇.

Действительно, если спросить у современной мощной LLM, отличаются ли слова “Apple” и “Аpple”, то она скажет, что отличаются. Но только потому, что использованы разные коды для обозначения буквы “A”. Коды не делают слово разным. Слово не поменялось, а роли букв не возникают из свойств Unicode. Если, конечно, это всё не происходит внутри LLM. Так, ChatGPT считает, что слова отличаются, потому что в записи использованы “латинская буква A” и “кириллическая буква А”. Но так не бывает. Да, коды у букв разные, однако это, буквально, одна и та же буква, во всех смыслах.

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

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

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

Что ж, ChatGPT вполне себе справляется – см. скриншот (в итальянской фразе не требуется знак вопроса, но это неважные детали).

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

Я переписывал исходную фразу разными способами, в том числе, не типовыми, используя различные буквы иврита для передачи звуков “английского”, но ChatGPT всё равно разгадывает. Надо заметить, что система справляется и с аналогичным текстом, представленным в виде изображения. Язык ответа, кстати, выбирается по общему контексту: если использовать простой аккаунт без истории, то ответ будет на иврите, как ни странно, но всё равно полностью верный и по теме, в том числе, с переводом итальянской фразы и на русский, и на иврит.

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

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

Всё из-за кодирования, и букв, которые не буквы для компьютера.

Что такое “буква”? Определить “буквы” довольно сложно. Пусть “буква” – это некий графический символ, графема, входящий в фиксированный список графем (рекурсивное определение). Такому символу может соответствовать звук фонетической записи слова языка. А может и не соответствовать. Очень хорошим подспорьем введению строгих определений тут является роль букв, как графики, в создании различительной способности при чтении записанных графически текстов. Примеры из английского: shake и stake, shake и snake. Здесь в shake буква h, самостоятельно, как бы, не имеет звука, однако является неотъемлемой частью записи фонемы sh. При этом, в snake/stake – замена h на разные буквы позволяет различить слова, а если туда подставить h, то оба слова превратятся в одно. Так что буква даже может быть “немой”, но всё равно остаётся важным различительным символом, который должен быть записан. Другой пример, русский: “полью” и “полю” – удалили букву “ь”, получили другое слово языка.

Всё это и требует разведения принципов компьютерного кодирования по логически разным блокам, даже если буква одна и та же. Более того, можно было бы использовать при записи русских слов букву p (“пи”) из ASCII, пусть буква и стала бы обозначать другой звук. Это, казалось бы, позволяет экономить один байт минимум. Так даже делалось когда-то очень давно. Проблемы начнутся сразу же, как только окажется, что слова “cop” и “сор” – это разные слова, а не то что “Apple” и “Аpple”. То есть, трудности вылезают из структуры более высокого порядка: не буквы разные, но слова. Отголоски этих проблем всё ещё слышны при сравнении текстовых строк в СУБД, например.

Занятно, что тут не работает нормализация Unicode: буквы “a” и “а” – не являются подходящими для нормализации символами, потому что это просто разные коды, а не разные способы представления одного символа комбинированием кодов (тут одна буква, она не “наборная”, но коды букв – различаются – подробности читайте в записке по ссылке).

Так что история с расщеплением токенизации через разное кодирование омоглифов – сильно сложнее, чем может показаться на первый взгляд.

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

Для таких недоверенных сертификатов невозможно проверить статус – отозван или нет. Почему? Потому что проверка статуса требует доверия источнику информации об этом статусе. Обычно, адрес, по которому можно получить ответ о статусе, записан в самом сертификате (точка раздачи CRL или OCSP-респондер). Соответственно, если проверяющая сторона не доверяет подписи на сертификате, то она не доверяет и составу сертификата, и, что важнее, УЦ, который сертификат выпустил. Но самое главное, что, очевидно, просто нет смысла проверять статус сертификата, которому, по другим причинам, нет доверия и так. Отозван или нет – без разницы.

Совсем другая история – достоверно отозванный сертификат. Сам факт того, что проверяющей стороне удалось определить статус сертификата (отозван), означает, что эта сторона смогла построить доверенную цепочку до УЦ, а потом, используя эту цепочку, проверила статус. То есть, всякий ответ о статусе сертификата обязательно должен быть удостоверен УЦ – иначе нет смысла. УЦ подписываются и OCSP-ответы, и CRL. Естественно, недоверенный сертификат тоже может быть “отозванным”, формально, но информация о его статусе не может являться доверенной, так что – она не имеет значения, не влияет на фактический статус сертификата.

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

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

Ещё занятный пример особенностей, связанных со “сверхкороткими” TLS-сертификатами. Я недавно перевёл dxdt.blog на такие сертификаты Let’s Encrypt – они имеют интервал валидности чуть больше шести с половиной суток (если более строго, то 160 часов). То есть, это “шестидневные сертификаты”. Обновляется сертификат автоматом, каждые двое суток – это разумно, потому что, если что-то пошло не так, хотелось бы иметь хотя бы пару дней в запасе, чтобы обнаружить и разобрать это “не так” (но заметьте, кстати, как сильно это всё раздувает логи Certificate Transparency – теперь за тот же период, за который раньше dxdt.blog расходовал максимум два сертификата, выпускается больше сорока сертификатов!).

Теперь вторая часть: на Timeweb недавно запустили простой мониторинг, который, в том числе, может мониторить “окончание действия” сертификата на сервере. Ну, допустим – и вот я включил этот мониторинг для dxdt.blog. В результате: после каждого обновления сертификата этот мониторинг присылает сообщение почтой: “SSL-сертификат истекает через 7 дней”. Как бы, это почти что формально верно (ну, кроме “семь дней” – не семь там дней; а для всего, что связано с прикладной криптографией, понимание сроков действия – очень важно).

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

Такой вот аспект применения “сверхкоротких” сертификатов. Мониторинг тот пришлось отключить.

Сделал специальный сервис для DNS – dns.1d.pw. Не торопитесь кликать – там нет A-записи, это именно что DNS-сервис, но он полезен для отладки и поиска причин возникновения проблем. Смысл вот в чём: если спросить в DNS TXT-запись для dns.1d.pw, то в ответ вернётся информация о том, как виден со стороны авторитативного сервера DNS-резолвер, который выполнил DNS-запрос. Вот простейший пример (здесь и далее используется утилита dig из пакета BIND):

$ dig dns.1d.pw -t TXT +short
"ns: dns-b"
"transport: UDP"
"src: [2a04:e4c0:10::145]:63761"
"target [id]: dns.1d.pw. [34301]"

Спрашивать нужно именно TXT: с A-записью – не получится. Кроме TXT – поддерживается только минимум: SOA и NS.

Ответ состоит из нескольких TXT-записей. Выясним, – пока кратко, – что в них видно (по порядку сверху вниз, как в примере):
внутренне имя авторитативного сервера, который обработал запрос (dns-b);
транспорт (UDP), по которому сервер получил запрос и ответил резолверу (то есть, не вашему клиенту, а именно резолверу);
IP-адрес узла, приславшего запрос, и номер порта ([2a04:e4c0:10::145]:63761); Здесь IPv6-адрес – сервис, естественно, поддерживает IPv6 тоже;
целевое имя, как его было видно в DNS-запросе, и код ID DNS-сообщения (dns.1d.pw. [34301]); дальше я объясню, почему это важно, хотя, казалось бы, имя и так известно.

И это не все параметры, которые присылает данный сервис.

Подобные сервисы существуют, и достаточно давно. Например, есть “очки” от Google: o-o.myaddr.google.com – показывает адрес резолвера и состав ECS, есть “пробник” от Akamai: whoami.ds.akahelp.net, и другие. Понятно, что у этих сервисов – свои ограничения. Например, я разу добавил поддержку DNS over TLS, поскольку данную технологию можно использовать между резолвером и авторитативными серверами (естественно, поддержка авторитативными серверам – редкость, но тем не менее).

Итак, технический смысл затеи: DNS-зона dns.1d.pw делегирована на специально разработанные NS-серверы, которые собирают данные о запросе, упаковывают их в TXT-записи, и отправляют в ответ. Такой способ позволяет информации пройти по цепочке, через резолвер. То есть, при штатной схеме работы, рекурсивный опрос для клиента выполняет рекурсивный резолвер, и именно это резолвер, в конце DNS-поиска, пришлёт запрос на авторитативный сервер. Например, если воспользоваться Google Public DNS, то мы увидим IP-адрес из пула DNS-сервисов Google (пример для 8.8.8.8):

$ dig @8.8.8.8 dns.1d.pw -t TXT +short
"ECS: 185.39.19.0/24/0"
"ns: dns-b"
"src: 74.114.29.150:43267"
"target [id]: dns.1d.Pw. [2909]"
"transport: UDP"

Обратите внимание, здесь добавилась информация о подсети источника запроса – ECS: 185.39.19.0/24/0. Это именно источник того запроса, который поступил в систему Google, а сервис DNS-резолвинга Google пронёс эту адресную информацию до авторитативного сервера. То есть, если вы используете сервис 8.8.8.8, то, – при прочих равных, – авторитативные серверы видят номер вашей подсети (обычно, это подсеть интернет-провайдера). Авторитативные серверы DNS – это не серверы Google, а подсеть видна даже в том случае, если прочий трафик завёрнут в VPN.

Кроме сведений о префиксе ECS, этот второй пример содержит другой адрес источника: 74.114.29.150 – IPv4-адрес резолвера Google. Сервис Google может приходить за DNS-данными и по IPv6, и по IPv4.

Приглядитесь к записи целевого имени – dns.1d.pw: при вызове dig имя записано строчными буквами, но в TXT-записи вернулось dns.1d.Pw (заглавная P). Именно так имя увидел авторитативный сервер. Что это? Это называется “рандомизация регистра символов” – один из дополнительных факторов защиты от спуфинга ответов, который применяет Google. Если воспользоваться аналогичным сервисом Cloudflare (1.1.1.1), то “рандомизации регистра” не случится:

$ dig @1.1.1.1 dns.1d.pw -t TXT +short
"target [id]: dns.1d.pw. [33389]"
"ns: dns-a"
"src: [2400:cb00:78:1024::ac44:b97b]:24308"
"transport: UDP"

Чтобы наблюдать такие эффекты и требуется возврат исходного имени в TXT-ответе. Дело в том, что изменяет имя резолвер, поэтому, без подобных хитростей, на DNS-клиенте резолвера обнаружить изменения нельзя.

Второй фактор защиты от спуфинга тоже можно видеть на распечатке выше: это номер транзакции (id – 33389). Сервер должен ответить с тем же номером, который отправил DNS-клиент в запросе. Третий типовой фактор – номер порта-источника (особенно актуально в UDP). Запросы в DNS отправляются на номер порта 53 (udp, tcp) и 853 (DNS over TLS), а номер порта-источника, соответственно, рандомизируется (должно быть сложно его угадать).

Сервис можно использовать для того, чтобы увидеть собственный внешний IP и параметры собственных DNS-запросов. Для этого нужно выступить в роли резолвера, направив DNS-запрос непосредственно узлу данного сервиса. Имена можно узнать, запросив список NS:

$ dig @8.8.8.8 dns.1d.pw -t NS +short
ns-dns-a.1d.pw.
ns-dns-b.1d.pw.

Спрашиваем напрямую ns-dns-a.1d.pw:

$ dig @ns-dns-a.1d.pw dns.1d.pw -t TXT +short
"target [id]: dns.1d.pw. [31841]"
"ns: dns-a"
"src: 185.39.19.199:26283"
"transport: UDP"

Получили в “src” IP-адрес, с которого отправлен локальный запрос (точнее: тот адрес, который видит внешний сервис – потому что может быть NAT и тому подобные штуки).

Основной транспорт для DNS – это UDP. Однако необходима и поддержка TCP. Сервис dns.1d.pw умеет отвечать по TCP. Да, контролировать протокол, который использует внешний резолвер, так просто не выйдет, но при локальнй подготовке запроса можно выбрать TCP при помощи флага +tcp утилиты dig. Проверяем:

$ dig @ns-dns-a.1d.pw dns.1d.pw -t TXT +short +tcp
"target [id]: dns.1d.pw. [9376]"
"ns: dns-a"
"src: 185.39.19.199:50169"
"transport: TCP"

Теперь указан TCP в качестве транспорта. TLS – не является обязательным. Однако это современная и весьма популярная технология, которая тут тоже поддерживается. Более того, сервис возвращает “расширенную информацию” – данные о версии TLS, о шифронаборах, о выбранном имени узла (SNI). Утилита dig поддерживает TLS (+tls). Проверяем:

$ dig @ns-dns-a.1d.pw dns.1d.pw -t TXT +tls +short
"target [id]: dns.1d.pw. [22366]"
"ns: dns-a"
"src: 185.39.19.199:59527"
"transport: TLS (1.3/X25519MLKEM768/TLS_CHACHA20_POLY1305_SHA256)"
"SNI: ns-dns-a.1d.pw"

Обратите внимание: здесь в записи имени DNS-узла – ns-dns-a.1d.pw – нельзя указывать крайнюю справа точку (которая превратила бы запись в FQDN, и которая для специалистов в DNS является чем-то само собой разумеющимся). Дело в том, что бэкенд сервиса использует реализацию TLS из типовой библиотеки Go. А типовая, “коробочная”, реализация TLS в Go строго не допускает финальные точки в составе хостнейма внутри расширения SNI – TLS-соединение просто не устанавливается. Такое поведение библиотеки, вообще говоря, вопрос весьма дискуссионный, но к теме этой записки он не относится: просто – не указывайте точку в конце, или используйте IP-адрес узла напрямую (возможно, я как-нибудь этот момент переделаю самостоятельно, ну или разработчики Go одумаются).

Вообще, TLS-сертификаты для авторитативных серверов, используемых в данном проекте, я выпустил через Let’s Encrypt, и это сертификаты для IP-адресов (v4/v6), что неплохо подходит для случая TLS на авторитативном DNS-сервере. А раз это сертификаты для IP-адресов, то для хостнеймов они так и так не валидны, но по умолчанию – dig здесь сертификаты и не проверяет на соответствие имён.

В поведение авторитативного сервера заложены и некоторые другие особенности, так что он не полностью соответствует “лучшим практикам” DNS, и это сделано специально. Например, как отмечено выше, в ответ на запрос A-записи – придёт ответ с флагом REFUSED, а это позволяет посмотреть на расширенные статусы DNS-ошибок, если запросить А-запись через сервис Google.

Всё чаще попадаются попытки внедрения IPv6-only (только IPv6) веб-узлов. И всё чаще встречается типовая техническая ошибка, этот процесс сопровождающая: для DNS-имени, указывающего на веб-узел, присутствует только AAAA-запись (то есть, только IPv6-адрес), но при этом все авторитативные серверы имён (NS) соответствующей доменной зоны – имеют только A-записи, только v4-адреса. В некотором роде – это удивительное техническое противоречие, граничащее с “карго-культом”: с v4 – доступ к такому сайту получить невозможно, так как нет адресной записи, но и получить v6-доступ, не воспользовавшись v4, тоже невозможно – потому что необходимо обратиться по v4-адресам NS.

IPv6 – не такой уж плохой протокол: многое там сделано даже логичнее практики v4. Но внедрять его “эксклюзивность” нужно аккуратно. Естественное и правильное решение для NS – добавить для авторитативных серверов IPv6-адреса, обеспечить по ним доступность DNS, а уж потом запускать IPv6-эксклюзивный веб-узел под AAAA-записью. Потому что тогда, при верном выборе зоны, все необходимые прикладные процессы смогут работать по IPv6, который уже заслуженно будет в приоритете (в корневой зоне DNS – IPv6 есть). Конечно, при наличии полной поддержки и v6, и v4 на клиенте – запрашивать нужно сразу и A, и AAAA-запись, отдавая приоритет AAAA при соединении. Но если есть только v4, то возникают дополнительные сложности.

Формально, ничего не запрещает не держать в DNS-зоне A-записи, а держать только AAAA, но раздавать эти AAAA исключительно через четвёртую версию протокола. Однако выглядит такая настройка максимально некрасиво, совсем не так, как IPv6-адреса на NS, и только A-запись – для веб-узла.

Более того, ситуация, когда на клиенте нет полноценного IPv6, а в целевой зоне – нет A-записи, и при этом сведения об отсутствии такой записи можно получить только через v4, вполне может трактоваться клиентом как отсутствие IP-доступа к веб-узлу совсем, вне зависимости от версии IP: нет адресной записи и – всё. И такой сигнал отсутствия даже может кешироваться на клиенте, перекрывая повторный доступ после того, как IPv6 на клиенте включился (конечно, в рамках той же сессии прикладного ПО, но такое – вполне возможно, так как сетевой интерфейс с полноценным v6 мог подняться позже, по команде пользователя). Дело в том, что после включения v6 можно было бы спросить AAAA-запись в DNS, но этому мешает флаг “отсутствует адресная запись”, уже установленны прикладным или системным ПО, который флаг, предположим, является универсальным, то есть, не зависит от версий v4/v6.

(Бывают, кстати, и другие “косые” ситуации: в vk.com, например, IPv6-адреса у авторитативных NS есть, но вот только DNS по ним не отвечает.)

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

И действительно, это, оказывается, не шутка: в исходной публикации присутствует гистограмма, на которой показан прирост количества кода (в строках), в восемь раз (8x). Надо сказать, там же, прямо под гистограммой, сказано, что, мол, показатель этот – количество строк кода, – не идеален, и он “точно преувеличивает реальный рост производительности (инженеров)”, но всё же показатель растёт, а поэтому – используем. Цитата с объяснением причины роста:

В Anthropic, вознаграждение сотрудникам рассчитывается не по количеству строк кода, которые они написали; напротив, участники команды выдают больше кода просто потому, что они используют ИИ-системы, чтобы писать больше кода. (At Anthropic, we don’t reward people for how many lines of code they write; rather, team members are producing more code simply because they’re using AI systems to write more code.)

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

Казалось бы – во всякой распределённой информационной системе, работающей под высокой нагрузкой, резкое увеличение скорости роста кодовой базы – однозначно плохой знак: зачем, для чего весь этот дополнительный код? кто будет его разгребать? Риторические вопросы.

Рассмотрим простой код на языке Python:

digital = list(map(lambda t: t, range(1, 11)))
print (digital)

Программа распечатает массив от 1 до 10. Другой вариант, более разумный, но чуть меньше кода:

digital = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
print (digital)

Тот же результат на печати, но мало строк! Воспользуемся кодо-генератором и сделаем иначе:

# Use bracket comprehension to declare an empty list
digital = []

# Append basic unit at zero index
digital.append(1)
# Create the second number
digital.append(digital[0] + digital[0])
# Create the next number
digital.append(digital[1] + digital[0])
# Create the number four
digital.append(digital[2] + digital[0])
# Create more numbers
digital.append(digital[3] + digital[0])
digital.append(digital[4] + digital[0])
digital.append(digital[5] + digital[0])
digital.append(digital[6] + digital[0])
digital.append(digital[7] + digital[0])
digital.append(digital[8] + digital[0])
# Print it out
print (digital)

Ну вот, результат – вроде бы тот же, однако совсем другое дело в коде: количество строк возросло в несколько раз, выглядит солидно. (Обратите, кстати, внимание, что этот вариант – он ещё и строит начало натурального ряда почти что в аксиоматике ZFC.)

Это, конечно, юмористический пример. Однако исходная публикация – вполне реальная, как ни странно. Так что ИИ-хайп действует. Посмотрим, что дальше.

В Интернете криптография далеко не всегда позволяет уверенно говорить, что IP-узел не был подменён. Даже если речь про аутентификацию по конкретным открытым ключам. Уже неоднократно писал на эту тему, но, похоже, имеет смысл ещё раз повторить некоторые моменты – вдруг кому-то будет полезно.

1.

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

2.

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

3.

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

4.

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

5.

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

В IETF запустили новую версию сайта rfc-editor.org – это сервис для редактирования и публикации RFC. Официальное сообщение об этом залито штампами (наверное, не обошлось без влияния ИИ): “Вместе с профессиональными UX-дизайнерами и специалистами по удобству использования (accessibility) мы переделали сайт на базе современного веб-фреймворка” (Working with professional UX designers and accessibility specialists, we have rebuilt the site in a modern web framework). Так сказать, очередной этап в развитии IETF: cайт требует JavaScript и загружает какие-то массивные JS-библиотеки. То есть, без JavaScript даже в публичной части сайта выводится предупреждение, что будут работать не все функции (в том числе, если просто попробовать почитать RFC через rfc-editor.org).

Сам я довольно широко использую JavaScipt (JS) в вебе со стороны разработки, что уж там: без JS сейчас не очень удобно. Например, общедоступный сервис ТЦИ для анализа настроек интернет-узлов – audit.statdom.ru – содержит здоровенный кусок JS-кода, который необходим для отображения отчётов на веб-странице, и я имею к этой ситуации самое прямое отношение. Но, как нетрудно догадаться, я противник всяких JS-фреймворков – если уж у вас есть JS-код в вебе, то пусть это будет, что назвается, “ванильный JavaScript”, понятный и написанный собственными руками. При этом, например, на основных страницах dxdt.blog – никакого JS-кода не требуется: скрипты хороши там, где без них совсем не обойтись (поэтому на dxdt.blog со скриптами вы встретитесь, если прямо решите залогиниться и использовать веб-интерфейс; но, отмечу, это особенность WordPress, а к разработке CMS WordPress – я никакого отношения не имею).

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

Так что, конечно, без JS сейчас в вебе никуда, но и сообщать о том, что страница вывода RFC в формате HTML может “не работать без JavaScript” – довольно странное решение.

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

Вернёмся, впрочем, к доступности.

Итак, я заметил, что какие-то сервисы через HTTPS недоступны, а они необходимы для нормальной работы веб-интерфейса (там всё управление – через веб). Логичное предположение: так как мой резолвер приходит на авторитативные серверы Google из “иностранной сети”, ему DNS Google отдаёт другие IP-адреса, а именно – адреса, предназначенные для соответствующего региона; и узлы под этими IP-адресами – недоступны из российских сетей. Почему это влияет? Потому что браузером-то я подключаюсь из российской IP-сети. Где именно соответствующий трафик забанен – я уже не стал разбираться: сейчас подобное разбирательство – легко превращается в длительное исследование, так как понять, “что-как-где-почему”, довольно сложно: сети окончательно стали мутными на прикладном уровне. Да, я делал бы ставку на то, что забанено на российском транзите; но, к сожалению, тут нельзя полностью исключать и сторону CDN Google – вообще говоря, агрессивная геобалансировка на стороне крупнейших провайдеров была известна и раньше, иногда, скажем, такая блокировка может быть побочным эффектом маршрутизации для anycast-адресов (отдельная история).

В общем, я просто добавил на сторне своего DNS-резолвера функцию отправки подсети-источника DNS-запроса в ECS, но только для доменов внутри зоны google.com, чтобы авторитативные DNS-серверы на той стороне видели целевой IP-префикс запроса. В Unbound (весьма рекомендую, кстати) избирательная поддержка ECS легко включается. После того, как в запросы добавились ECS – IP-адреса в ответных A-записях стали приходить другие, а сервис Google – тут же заработал из локальной сети. Да, откровенно говоря, не могу исключить, что это совпадение, но посмотрим: в других, – более прозрачных, но аналогичных, – случаях, с которыми я сталкивался, подход с перенастройкой резолвера срабатывал эффективно.

У меня в GitHub тоже есть аккаунт, которым, впрочем, я почти не пользуюсь. Но это не отменяет важности GitHub, конечно. Я под своим там аккаунтом довольно давно опубликовал реализацию шифра “Кузнечик” с оптимизацией на ассемблере Go (гораздо более новая версия, с поддержкой ARM64, есть у меня на сайте, если это вообще кому-то нужно). Кроме того, на GitHub я как-то выложил Runic32 – реализация Base32 на алфавите из англосаксонских рун (“футарк/футорк”, условно говоря). Этот проект является шуточным – потому что как-то зашёл разговор о том, что “TLS-сертификаты отображаются какими-то крючками”: ну, вот, при помощи утилты runic32 можно сертификаты записывать прямо рунами (если есть Unicode).

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

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