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

Ещё занятный пример особенностей, связанных со “сверхкороткими” 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.

Даниэль Стенберг (утилита curl) сообщает, что “страшная-ужасная” система поиска уязвимостей в ПО Mythos нашла в коде утилиты curl “пять” “подтверждённых уязвимостей” (“подтверждённых” – по мнению данного ИИ-LLM), которые, после проверки разработчиками, превратились в одну действительно подтверждённую уязвимость с низким уровнем опасности. Четыре остальных представленных описания – это ложные срабатывания и обнаруженная ошибка, – не уязвимость, – в коде. Результат никак не превосходит уже имеющиеся на стороне разработки curl инструменты.

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

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

Consequently, for the same “key tag” (33834), three different key pairs were generated instead of a single one, of which only the public key of a single pair was stored in the DNSKEY RR, meaning that only about a third of the RRSIG RRs could be validated. (В результате, для одинакового “тега ключа” (33834) были сгенерированы три разных ключевых пары вместо одной, из которых только открытый ключ единственной пары был размещён в DNSKEY-записи, что привело к тому, что только треть из RRSIG-записей могли быть валидированы.)

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

Собственно, в недавней записке об аварии DNSSEC в .DE я поэтому и упомянул конфликты тегов ключей DNSSEC, которые теги используют не по назначению. Цитата:

В DNSSEC выбрана неудачная система тегирования ключей при помощи 16-битных номеров, которые, понятно, то и дело совпадают для разных ключей; данные теги нельзя использовать в качестве индекса при выборе ключей для подписи, об этом написано в RFC, об этом много писал и говорил я, и не только я, но теги всё равно регулярно используют с такой целью; однако насчёт данного случая с DE – не факт, что в этом была проблема.

Оказалось – в этом и была проблема. Что тут ещё сказать? Бывает, конечно: ведь с пониманием сложных процессов – сейчас трудности везде.

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

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

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

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

Хотя – хайп. Хайп не все хотят пропустить.