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

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

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

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

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

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

Этот уровень приложений, как ни странно, очень технологичен. Но речь тут вовсе не про “используй фреймворк “Имярек”, чтобы лучше адаптировать агентов типа John Doe”. Нет. “Фреймворк и агенты” – это технологии, но не технологичность. Технологичность скрывается за процессом контроля над способом применения технологий. Если на примере инфраструктуры УЦ: сейчас кругом только и слышно, что про ACME и его использование – это про протокол автоматического заказа и получения TLS-сертификатов. Но реально ли речь всегда идёт о протоколе? Оказывается, нет. ACME – весьма заумный и развесистый протокол. Мало кто читал спецификацию, мало кто его понимает. Оказывается, что в большинстве случаев использовать хотят не протокол, а некий готовый продукт, популярную утилиту или библиотеку на основе ACME. Например, хотят не ACME, а чтобы работали certbot или acme.sh, а также и какой-нибудь ещё фреймворк. Вот эта зависимость – и есть технологичность, а не просто технологии.

Да, отдельные TLS-сертификаты для веб-сервера нетрудно выпускать самостоятельно, используя готовую библиотеку или утилиту. Гораздо сложнее сделать УЦ, который должен проверять, что заявленное имя сооотвествует предоставленному открытому ключу. И ещё сложнее сделать такой УЦ не на базе “готовых скриптов”. И тем более непросто реализовать валидацию сертификатов в веб-браузере, чтобы соблюсти все типовые условия. А ведь именно связка “браузер-УЦ” тут и работает в качестве линии приложения блокировок, вовсе не TLS-сертификат.

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

Использование хеш-деревьев в TLS-инфраструктуре веба, в TLS-сертификатах, обусловлено переходом на постквантовые криптосистемы цифровой подписи. Тоже хороший пример. Возможно, что в некоторый момент ведущие разработчики браузеров скажут, что браузеры больше не считают стойкими и надёжными сертификаты, выпущенные без постквантовой криптосистемы, а соответствующие веб-сайты – будут отображаться “как небезопасные”. Сложно ли такое представить? Конечно нет. Это вполне логично – устаревшие технологии в какой-то момент оказываются слабыми, браузер должен их блокировать тоже – какие могут быть возражения? Такое уже несколько раз происходило, и с DSA, и с SHA-1, и с длительностью действия сертификатов, и так далее, и тому подобное.

Ещё раз подчеркну – хитрость в том, что, действительно, устаревшие криптосистемы теряют стойкость, это без всякого сарказма. А вот уже с длительностью действия сертификатов – есть разные точки зрения, как говорится. Но Google в браузере Chrome даже не собирается поддерживать постквантовые криптосистемы подписи сертификатов, кроме как в варианте с хеш-деревьями (MT-сертификаты). Так что токены доступа – станут токенами доступа, и эта роль не зависит от типа носителя.

Нужен ли практический квантовый компьютер для того, чтобы объявить имеющиеся “не-постквантовые” криптосистемы подписи нестойкими? Нет, не нужен. Достаточно описания алгоритма Шора и непрекращающегося потока публикаций из тех же ведущих технологических корпораций о том, что необходимый прогресс на пути к квантовому компьютеру – велик и неуклонен.

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

Пишут (id: 65656, между прочим), что Let’s Encrypt добавили в своё соглашение пользователя пункт о соблюдении санкционного режима США (и других “подходящих” стран). Из исходного документа очевидно, что ограничения распространяются так же просто на “рядовых жителей” (ordinarily resident) подсанкционных территорий. Это не то чтобы совсем “новелла”, но для Let’s Encrypt выглядит неожиданно. Но в соответствующем подпункте, который про жителей, речь пока только о территориях и странах, находящихся под полным “эмбарго” США – comprehensive U.S. sanctions. Занятно, что термин “ordinarily resident” – обозначает всякого, кто фактически проживает на заданной территории, то есть, это очень широкое понятие.

Кроме того, в правила добавлены явные и бесспорные упоминания подсанкционных “компаний и субъектов” – им нельзя сертификаты и нельзя “в их интересах действовать”. Санкции сейчас раздаются очень массово, так что, в принципе, с использованием сертификатов “свободного УЦ” Let’s Encrypt возникают большие трудности. Но не у всех, понятно – ибо сам-то этот УЦ позиционируется как “для всех”: “Encryption for Everybody” – написано на первой странице сайта очень большими буквами, но тут нужно понимать, что и кто именно составляют множество этих body. (Оговорка: на dxdt.blog используется TLS-сертификат от УЦ Let’s Encrypt, поскольку это пока что единственный вариант из “хорошо известных УЦ”, который мне всё ещё доступен; долго ли ещё будет доступен? что отберут раньше – домен или сертификаты? Пока что нет ответа.)

Занятно и то, что многие пересказывают версию, по которой, мол, Let’s Encrypt (LE) тут просто “закрепил в правилах уже действовавшую практику” – нет, это не так: раньше в LE отказывали в выпуске сертификатов для конкретных имён, прямо указанных в конкретных списках, поскольку в США установили специальное исключение из санкционного режима, касавшееся “этих ваших интернетов” – в узких кругах соответствующий юридический “казус” известен как “поправка имени Cisco”. Новое дополнение в правилах LE – позволяет применять расширенные основания для “ковровых” отказов и отзыва сертификатов. Естественно, просто так подобные изменения в правила не вносят. Если бы LE стремились бы сами что-то такое применять, то вписали бы раньше. Но раз вписали сейчас, то, очевидно, с целью прямого применения, потому что были какие-то внутри возражения, сомнения, зацепки. Посмотрим. (Есть небольшой шанс, что откатят, но реально небольшой.)

Тиражируют заявление, что, мол, в корпорации 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.)

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

Очередная декларация – The Leiden Declaration, – на тему проблем “влияния ИИ”, в этот раз – проблем влияния на социальные аспекты теоретической математики. Речь там про “коммерческие системы LLM”, продвигаемые ведущими корпорациями (типа, когда публикуют очередной пресс-релиз, что “GPT решили старую задачу Эрдёша”).

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

В Калифорнии (США) продвигают местный закон (статья в The Register, англ.), который, если его примут, обяжет встроить в процесс подготовки моделей для 3D-печати некий “детектор моделей огнестрельного оружия” – то есть, чтобы автоматически запрещалась печать на 3D-принтере, если пользователь “что-то не то” пробует распечатать. Естественно, речь пока про огнестрельное оружие идёт из-за того, что, мол, можно напечатать условный “призрачный револьвер”. Но логика запрета построена на совсем другом моменте: предлагается вести некий центральный реестр запрещённых к печати моделей; а программное обеспечение (ПО), подготавливающее модель к печати, должно с базой сверяться, получать разрешение на подготовку.

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

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

Кстати, занятно: ещё в 2016 году SpaceX обещали, что не позднее 2018 года доставят тяжёлый аппарат на Марс, в качестве первого шага марсианской программы SpaceX.

Это, конечно, и тогда-то выглядело очень сомнительно (о чём и написано в записке по ссылке). Десять лет прошло с 2016 года, но что-то именно в SpaceX марсианскую программу не развили совсем, аппаратов-роботов от этой корпорации на Марсе нет и сейчас, что уж там говорить про 2018 год. Зато сильно развили в SpaceX военную спутниковую низкоорбитальную группировку – Starshield, – которая работает на базе Starlink. Оно и понятно: от мифического строительства городов на Марсе толку нет, кроме как при использовании в качестве схемы прикрытия.

В СМИ подтверждают (англ., со ссылкой на US Space Force), что SpaceX со Starshield/Starlink официально достался контракт на запуск спутниковой сети обмена данными для военных применений. Естественно, такая сеть работает на низкоорбитальных космических аппаратах. Процитирую прошлогоднюю записку по этой теме:

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

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

В общем, пока латинского текста нет, можно только строить предположения о первых словах: название “Magnifica Humanitas” наводит на очевидные варианты. Естественно, много кто уже догадался попробовать перевести текст “про ИИ” при помощи ИИ; например, с итальянского на латынь – но, понятно, это будет лишь упражнение в развитии постиронии: LLM не слишком хороши в подобных переводах.

В 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” – довольно странное решение.

Процитирую записку из 2013 года:

“Интернет – это группа постапокалиптических технологий, не дождавшихся своего часа”.

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

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

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

Это всё, впрочем, не отменяет постапокалипсиса в истории Интернета. Но, как в цитате выше, эта группа технологий не дождалась своего часа – то есть, не была применена в соответствии с легендой. И уже не будет. Сейчас схемы иные.

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

Поэтому-то шансов на разыгрывание легенды по привычному сценарию – больше нет.

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

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

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