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

В одной из почтовых рассылок 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 – имеет первоочередное значение.

Цитата из моего технического описания TLS:

Весьма полезной практикой является разумное выравнивание стойкости используемых криптосистем. Например, в подавляющем большинстве случаев не имеет смысла использовать RSA-ключ длиной в 4096 бит, если ваш TLS-сервер всё ещё поддерживает SSLv3, а в качестве симметричного шифра применяет DES с 56-битным ключом.

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

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

В TLS 1.3 криптосистема RSA для зашифрования не используется, а процесс получения сеансовых ключей (за некоторыми исключениями) основывается на протоколе Диффи-Хеллмана и состоит из нескольких этапов. Тем не менее, раскрытие сеансовых симметричных ключей и тут приводит к тому, что активный атакующий может подменить трафик, выступив вместо одной из сторон после того, как соединение установлено.

Наберём в консоли (в терминале) ping 010.010.010.010 и запустим выполнение – что произойдёт? Результат теперь многим и многим, – далеко не пользователям, а даже системным администраторам, – кажется неожиданным: “пинги” отправляются на один из адресов Google – 8.8.8.8. Проверьте самостоятельно (в экзотических ОС результат может отличаться, но в привычных линуксах, например, – всё вполне корректно, а экзотические ОС ещё предстоит подобрать).

Почему так вышло? Потому что старое системное соглашение, о котором нынче забывают, гласит: если запись октета IP-адреса (здесь – четвёртой версии) начинается с символа нуля и не содержит, следом, буквы, то это запись в восьмеричной системе! (Относится, конечно, не только к ping и не только к IP-адресам.) 10 в восьмеричной системе – это восемь, так что: 8.8.8.8. Неплохо взглянуть и на другие варианты: ping 010.8.010.8, например. А попытка вызвать ping 010.080.010.010 приведёт, скорее всего, к сообщению о том, что адрес для имени обнаружить не удалось (или Name or service not known – в типичном случае).

А оговорка насчёт буквы в предыдущем параграфе, конечно, это для 0x08, например. Но такая запись мало кого вводит в заблуждение.

В ТЦИ запущен сервис просмотра данных российских логов Certificate Transparency. На сервере используется TLS-сертификат, выпущенный ЦС ТЦИ. Соответствующий корневой сертификат ECDSA можно взять на сайте ЦС (SHA-1: 4E877AC027A63D8514C0B4CBFA0F6F58F6C17696).

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

(Это, собственно, версия известного сервиса crt.sh, но с поддержкой только российских логов – в crt.sh они не учитываются автоматически.) Самое простое применение – поиск (пре)сертификатов TLS по доменному имени (см. скриншот для livejournal.com ниже).