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

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

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

Оказывается, некоторое время назад в Google добавили занятную функцию в приложение для (так называемой) “двухфакторной аутентификации” (2FA), а именно – возможность восстановления “из облака” в случае потери устройства. Заметьте, что весь смысл “двухфакторной аутентификации” состоит в том, что подключающийся пользователь может доказать, что у него есть доступ к дополнительному секрету, кроме пароля, который могли и украсть. Естественно, этот дополнительный секрет может проявляться как “одноразовые пароли” или какие-нибудь PIN-коды, которые, например, генерируются в зависимости от текущего времени (и от значения секрета, конечно).

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

С этим обновлением мы вводим решение проблемы – делая одноразовые коды более надёжными путём безопасного хранения их в Google-аккаунте пользователя.
(With this update we’re rolling out a solution to this problem, making one time codes more durable by storing them safely in users’ Google Account.)

То есть, наличие потенциальной привязки к аппаратному устройству делало 2FA полезным инструментом, однако Google предлагает передать дополнительный пароль на внешние серверы, в результате чего вторым фактором оказывается Google-аккаунт. Теперь, если пользователям некоторой корпоративной системы предложено использовать Google Authenticator в качестве хранилища второго секрета (распространённый случай), то это означает, что доступ к системе завязан уже даже не на неконтролируемое приложение от третьей стороны, а прямо на аккаунт Google.

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

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

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

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

Предположим, что некоторые интернет-измерения, проводимые с использованием веба, полностью основаны на уникальном имени хоста, которое генерируется под каждый запрос. Это очень удобный способ создания информативного маркера, переходящего между протоколами. Имя нетрудно встроить, например, в адрес источника файла изображения, ссылка на которое входит в состав кода веб-страницы. Почему подходит именно имя хоста? Потому что оно же будет использоваться клиентом и в DNS, и в HTTP. А вот часть URL, соответствующая адресу документа, уже в DNS не ходит. Другими словами: используем в браузере (условный) URL https://123dio.cba.example.net/an-img.gif, где полезные данные кодируются в части 123dio.cba. Строка 123dio.cba.example.net отправится и в DNS, где будет узнана специальным сервером, и в HTTP, а вот an-img.gif – в DNS не попадёт, а поступит только на веб-сервер, отвечающий под 123dio.cba.example.net. Соответственно, насыщение HTTP-запросов полезной информацией, которую мы хотим видеть и в DNS, должно происходить через имена хостов.

Однако возникает неприятная проблема с HTTPS: дело в том, что для установления соединения с браузером сервер под “странным” именем 123dio.cba.example.net должен предъявить TLS-сертификат, валидный для этого имени, но имя-то каждый раз разное, поэтому сертификатов не напасёшься (если их выпускать через тот или иной УЦ, признаваемый браузерами). Использование открытого HTTP тут не рассматриваем – такие условия: хотя бы потому, что страница-носитель загружается по HTTPS. Что можно сделать? А можно, например, совсем отказаться от установления TLS-соединения на стороне сервера и при этом не потерять полезных данных. Нам не требуется реально обрабатывать HTTP-запрос и возвращать файл изображения, нам нужно только зафиксировать на сервере имя хоста, а это имя в HTTPS/TLS передаётся клиентом в начальном сообщении, да ещё и в открытом виде (это как раз и есть SNI TLS). Так что серверный сертификат тут просто не нужен: сервер записывает имя хоста из SNI и – прерывает соединение с тем или иным кодом ошибки TLS.

(Дополнение – 30/04/2023: в комментариях справедливо указывают на wildcard-сертификат для имён вида *.example.net. Однако тут такой сертификат не сработает, поскольку для DNS-части измерений важны кодирующие имена минимум в двух уровнях, то есть, *.*.example.com, а wildcard-сертификат закрывает только один уровень. Несколько уровней – входят в качестве требования в изначальную задачу, оставшуюся здесь за скобками.)

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

Предположим, что вы где-то встретили или обнаружили “подозрительный TLS-сертификат” и хотите получить комментарии специалиста про этот сертификат. Как поступить?

Прежде всего: необходимо сохранить сам файл сертификата непосредственно и полностью. Скриншот окна Windows с информацией “об издателе” и со сроками действия – никак не позволяет что-то содержательное сказать о сертификате: по этим данным даже нельзя судить о том, разные сертификаты вы просматриваете или один и тот же. Сохранить сертификат можно при помощи функции экспорта. К сожалению, реализации этой функции существенно различаются от приложения к приложению. Например, в браузере нужно кликнуть на “замочек в адресной строке” или на вкладку панели веб-разработчика, соответствующую настройкам безопасности сайта, или ещё куда-то, но логика данного действия общая – нужно найти, где сертификат сервера (веб-сайта) экспортируется в файл. Файл может иметь разные форматы (Base64, “двоичный”) и разные расширения в имени (.pem, .cer, .der, .bin, .cert и др.), но это, обычно, не важно – для специалиста это редко является проблемой. Главное – получить сам сертификат полностью в файле. Если функция экспорта позволяет сохранить “цепочку сертификатов” – тем лучше, сохраните цепочку. Основная причина, по которой нужен именно файл, в том, что сертификат содержит значение подписи, а это значение является доказательством того, что сертификат действительно был выпущен и подписан с использованием того или иного ключа. Кроме того – можно удобным способом просматривать все поля сертификата (серийный номер, расширения, ключ и пр.).

Если вам по каким-то причинам удаётся просмотреть только значения конкретных полей сертификата, то, во-первых, нужно сразу отметить, что ценной информации будет очень мало, и, во-вторых, попытаться сохранить серийный номер, отпечаток сертификата (значение хеш-функции для сертификата), имена, – то есть, название УЦ и имя, для которого сертификат выпущен (Issuer, Subject, Subject Alternative Name), – значение ключа (или отпечаток ключа; в сертификате публикуется открытый ключ) и тип криптосистемы, значение подписи с указанием на тип криптосистемы, сроки действия и сведения о цепочке сертификатов (серийные номера, имена, отпечатки), использованной для валидации.

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

На сайте ТЦИ (Технический Центр Интернет) опубликована моя статья о технологии Certificate Transparency (CT) и её роли в современном Интернете. Статья рассказывает не столько о базовых принципах построения CT (они достаточно широко известны), сколько об особенностях реального применения данной технологии – о проблемах, связанных с неверной интерпретацией значения меток в сертификатах, о полноте CT-логов.

Certificate Transparency […] лишь предоставляет инструмент для наблюдения за деятельностью УЦ, но никак не ограничивает эту деятельность на техническом уровне.

Ещё о пресертификатах в Certificate Transparency (CT) и странных “свойствах”, которые возникают вокруг. TLS-сертификаты превращаются в пресертификаты после того, как добавлено специальное расширение Poison. Может показаться, что с этим расширением тоже связана проблема “курицы и яйца”, поскольку нарушать процесс валидации poison-расширение должно потому, что оно помечено как Critical (критическое), но имеет тип, неизвестный валидатору – неизвестные критические типы, согласно рекомендациям, должны приводить к тому, что сертификат считается невалидным (а вот расширения неизвестного типа, которые не помечены как критические, можно игнорировать). Если же валидатор знает тип poison-расширения, то флаг Critical уже не должен препятствовать валидации. Это так, однако проблемы тут нет: в том случае, когда валидатор распознал poison-расширение, он не должен принимать сертификат на правах валидного, так как, грубо говоря, видит, что это пресертификат (ну или можно интерпретировать иначе: наличие poison-расширения означает, что сертификат не должен использоваться так же, как и сертификат без Poison). В общем, всё же появляется неплохой шанс выстроить однозначный процесс валидации.

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

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

Сервис проверки настроек интернет-узлов ТЦИ теперь поддерживает TLS-сертификаты НУЦ и ТЦИ в качестве доверенных корневых сертификатов. То есть, теперь узлы, которые используют серверные сертификаты от этих корней, будут получать баллы рейтинга так же, как и с другими доверенными сертификатами.

Можно ли в вебе на стороне сервера определить, какой именно версии браузер устанавливает TLS-соединение, в самом начале этого соединения? Например, для того, чтобы выбрать сертификат от подходящего УЦ (см. ниже). Хитрость в том, что привычный способ, когда браузер определяется по HTTP-заголовку User-Agent, тут не подходит: на начальном этапе установления соединения никаких HTTP-заголовков ещё нет, а вот серверный сертификат передавать нужно. И речь не про выбор сертификата на основе перечня поддерживаемых криптосистем, как это делается при настройке параллельной работы ГОСТ-алгоритмов и “обычных” алгоритмов в TLS/HTTPS – эта задача как раз решается весьма просто. Вообще, проблема находится на другом уровне: строго говоря, узнавать нужно даже не столько браузер, сколько конкретную библиотеку, реализующую TLS (так, для Firefox это будет NSS), и конкретный профиль данной библиотеки. Вообще, сделать выбор иногда можно на основе анализа состава TLS-сообщений, но так как набор этих сообщений не велик, а сам перечень может изменяться, то и точность не велика. Тем не менее, конкретная разновидность браузеров могла бы сигналить серверу, что именно такой браузер подключается. Это реализуется через дополнение TLS-сообщений, но внедрение потребует доработки TLS-стека как на стороне сервера, так и на стороне браузера.

А вот что касается именно списка поддерживаемых УЦ, то в TLS уже есть встроенный механизм, в версии 1.3 он так и называется – “certificate_authorities”. Это расширение, которое клиент может включить в состав сообщения ClienHello (начальное сообщение TLS-соединения), а сервер может обработать и – выбрать нужный сертификат, в том числе, для одной и той же криптосистемы. Вот только распространённые браузеры данное расширение не поддерживают, а если бы и поддерживали, то туда пришлось бы вписывать слишком много имён УЦ, так как в типичный дистрибутив браузера их входят многие десятки. Так что доработка, как минимум, браузера – всё равно потребуется.

Появилось открытое письмо, призывающее “приостановить эксперименты с большим искусственным интеллектом” (“Pause Giant AI Experiments”) и ввести регулирование, в том числе, “контроль и отслеживание” “мощных вычислительных средств” (“large pools of computational capability”). Занятно, что там в качестве основы шкалы используется GPT-4 – то есть, буквально, предлагается всем немедленно приостановить “обучение” систем, более мощных, чем GPT-4. Приостановить – как минимум, на шесть месяцев; но, как можно предположить по тону и смысловому содержанию письма, более точная интерпретация такая: приостановить до того момента, пока не введут нужные запреты на уровне правительств. Довольно показательный PR-шаг. Особенно, если взглянуть на него в исторической перспективе развития глобальной Сети, которая, несомненно, для разных там Chat GPT – имеет первоочередное значение.